From trac at galois.com Thu Jan 1 23:38:35 2009 From: trac at galois.com (GHC) Date: Thu Jan 1 23:30:26 2009 Subject: [GHC] #2884: Compiled code performance worsens when module names are long enough In-Reply-To: <049.881bd6a7c8430691cda844d87df64824@localhost> References: <049.881bd6a7c8430691cda844d87df64824@localhost> Message-ID: <058.5d4c8e52388bde34f1f6dc70a7fab25d@localhost> #2884: Compiled code performance worsens when module names are long enough -----------------------------------------+---------------------------------- Reporter: jcpetruzza | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by bos): * cc: bos@serpentine.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 2 03:59:08 2009 From: trac at galois.com (GHC) Date: Fri Jan 2 03:51:00 2009 Subject: [GHC] #2906: .hc code generated for Parser.hs is 2MB big Message-ID: <043.64c088340779512ef40025c8e0908a45@localhost> #2906: .hc code generated for Parser.hs is 2MB big -----------------------------+---------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: sparc -----------------------------+---------------------------------------------- When compiling GHC 6.10.1 with GHC 6.8.3 on the SPARC T2, the intermediate C code emitted for Parser.hs is a bit over 2MB (that's megabytes) big. GCC 4.2.1 then takes over 2 hrs to compile this single source file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 2 09:59:31 2009 From: trac at galois.com (GHC) Date: Fri Jan 2 09:51:21 2009 Subject: [GHC] #2670: Record selectors behaving badly wrt optimisation In-Reply-To: <047.05629016d0e3be252c46b232dd152edc@localhost> References: <047.05629016d0e3be252c46b232dd152edc@localhost> Message-ID: <056.6e5a13e7eac2bdd41622311c6758d588@localhost> #2670: Record selectors behaving badly wrt optimisation ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: simonpj => igloo Comment: I've finally fixed this {{{ Fri Jan 2 14:28:51 GMT 2009 simonpj@microsoft.com * Make record selectors into ordinary functions This biggish patch addresses Trac #2670. The main effect is to make record selectors into ordinary functions, whose unfoldings appear in interface files, in contrast to their previous existence as magic "implicit Ids". This means that the usual machinery of optimisation, analysis, and inlining applies to them, which was failing before when the selector was somewhat complicated. (Which it can be when strictness annotations, unboxing annotations, and GADTs are involved.) The change involves the following points * Changes in Var.lhs to the representation of Var. Now a LocalId can have an IdDetails as well as a GlobalId. In particular, the information that an Id is a record selector is kept in the IdDetails. While compiling the current module, the record selector *must* be a LocalId, so that it participates properly in compilation (free variables etc). This led me to change the (hidden) representation of Var, so that there is now only one constructor for Id, not two. * The IdDetails is persisted into interface files, so that an importing module can see which Ids are records selectors. * In TcTyClDecls, we generate the record-selector bindings in renamed, but not typechecked form. In this way, we can get the typechecker to add all the types and so on, which is jolly helpful especially when GADTs or type families are involved. Just like derived instance declarations. This is the big new chunk of 180 lines of code (much of which is commentary). A call to the same function, mkAuxBinds, is needed in TcInstDcls for associated types. * The typechecker therefore has to pin the correct IdDetails on to the record selector, when it typechecks it. There was a neat way to do this, by adding a new sort of signature to HsBinds.Sig, namely IdSig. This contains an Id (with the correct Name, Type, and IdDetails); the type checker uses it as the binder for the final binding. This worked out rather easily. * Record selectors are no longer "implicit ids", which entails changes to IfaceSyn.ifaceDeclSubBndrs HscTypes.implicitTyThings TidyPgm.getImplicitBinds (These three functions must agree.) * MkId.mkRecordSelectorId is deleted entirely, some 300+ lines (incl comments) of very error prone code. Happy days. * A TyCon no longer contains the list of record selectors: algTcSelIds is gone The renamer is unaffected, including the way that import and export of record selectors is handled. Other small things * IfaceSyn.ifaceDeclSubBndrs had a fragile test for whether a data constructor had a wrapper. I've replaced that with an explicit flag in the interface file. More robust I hope. * I renamed isIdVar to isId, which touched a few otherwise-unrelated files. M ./compiler/basicTypes/DataCon.lhs -4 +5 M ./compiler/basicTypes/Id.lhs -72 +45 M ./compiler/basicTypes/IdInfo.lhs -32 +28 M ./compiler/basicTypes/IdInfo.lhs-boot -4 +3 M ./compiler/basicTypes/MkId.lhs -401 +85 M ./compiler/basicTypes/Var.lhs -113 +93 M ./compiler/coreSyn/CoreSyn.lhs -6 +6 M ./compiler/coreSyn/CoreUnfold.lhs -2 +2 M ./compiler/coreSyn/CoreUtils.lhs -5 +5 M ./compiler/coreSyn/MkExternalCore.lhs -1 +1 M ./compiler/coreSyn/PprCore.lhs -5 +7 M ./compiler/ghci/Debugger.hs -3 +2 M ./compiler/hsSyn/HsBinds.lhs -4 +20 M ./compiler/iface/BinIface.hs -17 +28 M ./compiler/iface/BuildTyCl.lhs -21 +20 M ./compiler/iface/IfaceSyn.lhs -25 +38 M ./compiler/iface/LoadIface.lhs -22 +1 M ./compiler/iface/MkIface.lhs -3 +12 M ./compiler/iface/TcIface.lhs -42 +98 M ./compiler/main/HscTypes.lhs -7 +6 M ./compiler/main/InteractiveEval.hs -5 +3 M ./compiler/main/TidyPgm.lhs -28 +20 M ./compiler/prelude/TysWiredIn.lhs -1 M ./compiler/rename/RnBinds.lhs +2 M ./compiler/simplCore/CSE.lhs -1 +1 M ./compiler/simplCore/FloatIn.lhs -1 +1 M ./compiler/simplCore/SetLevels.lhs -9 +9 M ./compiler/simplCore/SimplCore.lhs -1 +1 M ./compiler/stgSyn/CoreToStg.lhs -1 +1 M ./compiler/stranal/DmdAnal.lhs -2 +2 M ./compiler/stranal/WorkWrap.lhs -1 +1 M ./compiler/stranal/WwLib.lhs -4 +4 M ./compiler/typecheck/TcBinds.lhs -6 +9 M ./compiler/typecheck/TcEnv.lhs -5 +2 M ./compiler/typecheck/TcInstDcls.lhs -9 +8 M ./compiler/typecheck/TcRnDriver.lhs -28 +35 M ./compiler/typecheck/TcSplice.lhs -1 +1 M ./compiler/typecheck/TcTyClsDecls.lhs -19 +190 M ./compiler/types/TyCon.lhs -12 +2 M ./compiler/vectorise/VectUtils.hs -2 +2 }}} I think this is too far-reaching to merge to the branch. I'm re-assinging to Ian, in the hope that you can make a test that'll spot the performance change. But if that's too hard, just close it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 2 10:01:25 2009 From: trac at galois.com (GHC) Date: Fri Jan 2 09:53:16 2009 Subject: [GHC] #2884: Compiled code performance worsens when module names are long enough In-Reply-To: <049.881bd6a7c8430691cda844d87df64824@localhost> References: <049.881bd6a7c8430691cda844d87df64824@localhost> Message-ID: <058.c620ee893b729b0364d7f03bc280cdd2@localhost> #2884: Compiled code performance worsens when module names are long enough -----------------------------------------+---------------------------------- Reporter: jcpetruzza | Owner: igloo Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * owner: => igloo Comment: OK I claim I've fixed this: see #2670. Give it a whirl. Reassigning to Ian, just for independent verification; then close. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 2 10:26:32 2009 From: trac at galois.com (GHC) Date: Fri Jan 2 10:18:20 2009 Subject: [GHC] #2756: state hack causes unneeded value to be evaluated In-Reply-To: <044.fd970d5f81038e1e8c0cb54c1d8b0d1b@localhost> References: <044.fd970d5f81038e1e8c0cb54c1d8b0d1b@localhost> Message-ID: <053.ce593b9a4ad2871fef84a5da7f48396e@localhost> #2756: state hack causes unneeded value to be evaluated -------------------------------------------+-------------------------------- Reporter: int-e | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: simplCore/should_run/T2756 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by simonpj): * testcase: => simplCore/should_run/T2756 * owner: => igloo * type: bug => merge Comment: Fixed by {{{ Wed Nov 26 14:34:48 GMT 2008 simonpj@microsoft.com * Fix Trac #2756: CorePrep strictness bug }}} Pls merge. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 2 10:31:27 2009 From: trac at galois.com (GHC) Date: Fri Jan 2 10:23:22 2009 Subject: [GHC] #2902: Example where ghc 6.10.1 fails to optimize recursive instance function calls In-Reply-To: <047.82275b0f80fb63e95aa6dfb32e5bfe1f@localhost> References: <047.82275b0f80fb63e95aa6dfb32e5bfe1f@localhost> Message-ID: <056.2ecac1a26b015a6f6e284198fc738522@localhost> #2902: Example where ghc 6.10.1 fails to optimize recursive instance function calls -----------------------------------------+---------------------------------- Reporter: Syzygies | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: class instance | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | -----------------------------------------+---------------------------------- Changes (by simonpj): * cc: batterseapower@hotmail.com (added) * difficulty: => Unknown Comment: Ha! Excellent example. What is happening is that I'm generating stuff like {{{ union d = let u2 = union d in \x. ... u2 ... }}} If only we had Max's arity analysis, this would generate good code (by inlining u2) but now it doesn't. Max, this is an excellent test case. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 2 14:55:29 2009 From: trac at galois.com (GHC) Date: Fri Jan 2 14:47:53 2009 Subject: [GHC] #2907: generalized newtype deriving not working with polymorphic component Message-ID: <046.6f945c34c168084d94aff5d01ac7c016@localhost> #2907: generalized newtype deriving not working with polymorphic component -----------------------------+---------------------------------------------- Reporter: jeltsch | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I?d like generalized newtype deriving to work also with polymorphic components like in this example: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving, RankNTypes #-} import Control.Monad.Cont newtype PolyContT monad o = PolyContT (forall result. ContT result monad o) deriving (Monad) }}} Would this be possible? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 2 17:03:20 2009 From: trac at galois.com (GHC) Date: Fri Jan 2 16:55:08 2009 Subject: [GHC] #2746: Documentation for Haskell 98 modules is empty In-Reply-To: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> References: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> Message-ID: <056.8b6228c0925a47e74f6d228b9fd0fdd7@localhost> #2746: Documentation for Haskell 98 modules is empty ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by waern): I have fixed this problem in Haddock, so we now link to the docs for each export. However, the links sometimes go to the wrong place due to a bug in GHC where the options specified with OPTIONS_HADDOCK seem to go unnoticed. Currently investigating... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 2 17:39:29 2009 From: trac at galois.com (GHC) Date: Fri Jan 2 17:31:19 2009 Subject: [GHC] #2659: Add sortOn and other *On functions In-Reply-To: <045.d1e80fa0049c474f9074e278f7023d7a@localhost> References: <045.d1e80fa0049c474f9074e278f7023d7a@localhost> Message-ID: <054.f65f37d964e2d353b0714b7e6a79bcc9@localhost> #2659: Add sortOn and other *On functions ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by LouisWasserman): Er. This function is already present in GHC.Exts: http://www.haskell.org/ghc/docs/6.10.1/html/libraries/base/GHC- Exts.html#v%3AsortWith Replying to [ticket:2659 twanvl]: > Almost all uses of {{{sortBy}}} are of the form {{{sortBy (comparing f)}}}, {{{sortBy (compare `on` f)}}} or an equivalent construction. I propose that we add the more convenient function {{{sortOn}}} to Data.List: > {{{ > sortOn :: Ord b => (a -> b) -> [a] -> [a] > }}} > For consistency for the other `By` functions we should also add an `On` equivalent: > {{{ > nubOn :: Eq b => (a -> b) -> [a] -> [a] > deleteOn :: Eq b => (a -> b) -> a -> [a] -> [a] > deleteFirstsOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] > unionOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] > intersectOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] > groupOn :: Eq b => (a -> b) -> [a] -> [[a]] > sortOn :: Ord b => (a -> b) -> [a] -> [a] > insertOn :: Ord b => (a -> b) -> a -> [a] -> [a] > maximumOn :: Ord b => (a -> b) -> [a] -> a > minimumOn :: Ord b => (a -> b) -> [a] -> a > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 2 23:24:46 2009 From: trac at galois.com (GHC) Date: Fri Jan 2 23:16:34 2009 Subject: [GHC] #2908: typo "reqwest" in documentation Message-ID: <047.3ce89554a050f21502c38cf3d1af61be@localhost> #2908: typo "reqwest" in documentation -----------------------------+---------------------------------------------- Reporter: bancroft | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: trivial Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- While reading through the documentation for base-4.0.0.0: Basic libraries, Control Concurrent, http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control- Concurrent.html I noticed a slightly manged "reqwest" in the paragraph, "The System.IO library manages multiplexing in its own way. On Windows systems it uses safe foreign calls to ensure that threads doing I/O operations don't block the whole runtime, whereas on Unix systems all the currently blocked I/O '''''reqwests''''' are managed by a single thread (the IO manager thread) using select." -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 2 23:25:37 2009 From: trac at galois.com (GHC) Date: Fri Jan 2 23:17:24 2009 Subject: [GHC] #2908: typo "reqwest" in documentation In-Reply-To: <047.3ce89554a050f21502c38cf3d1af61be@localhost> References: <047.3ce89554a050f21502c38cf3d1af61be@localhost> Message-ID: <056.9ba3c6f18b899e846f248d9de7996576@localhost> #2908: typo "reqwest" in documentation ------------------------------+--------------------------------------------- Reporter: bancroft | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: Severity: trivial | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by bancroft): * version: 6.10.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 3 01:52:05 2009 From: trac at galois.com (GHC) Date: Sat Jan 3 01:43:51 2009 Subject: [GHC] #2909: long list of names -> linkBCO: >= 64k insns in BCO Message-ID: <045.57b509387c9174e0d5555000f6f92fd8@localhost> #2909: long list of names -> linkBCO: >= 64k insns in BCO -----------------------------+---------------------------------------------- Reporter: jowens | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Doing Project Euler 22. Simple program, gives me: classico 9679$ runghc 22.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): linkBCO: >= 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Attached as 22.hs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 3 03:19:19 2009 From: trac at galois.com (GHC) Date: Sat Jan 3 03:11:07 2009 Subject: [GHC] #2905: require -XGADTs in order to pattern-match GADTs In-Reply-To: <044.e288cc24bdc7d119176c55c76be624e8@localhost> References: <044.e288cc24bdc7d119176c55c76be624e8@localhost> Message-ID: <053.bf3cde36c97b2489833ca7f14a786b3c@localhost> #2905: require -XGADTs in order to pattern-match GADTs -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- Comment (by Dominic): I would vote for requiring the -XGADTs flag if you are using GADTs not merely defining them. Either that or a better suggestion on the error message (although this might be annoying for real "GADT pattern match in non-rigid context" errors). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 3 12:40:08 2009 From: trac at galois.com (GHC) Date: Sat Jan 3 12:31:51 2009 Subject: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked Message-ID: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked -------------------+-------------------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- {{{throwTo}}} can block indefinitely when the target thread has exceptions blocked at thread creation time. The following test program demonstrates this problem. {{{ import Control.Exception import GHC.Conc main = do t1 <- block $ forkIO yield t2 <- forkIO $ killThread t1 threadDelay 1000000 threadStatus t1 >>= print threadStatus t2 >>= print }}} can print (and does fairly reliably for me) {{{ ThreadFinished ThreadBlocked BlockedOnException }}} See also http://www.haskell.org/pipermail/reactive/2009-January/000197.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 3 12:58:39 2009 From: trac at galois.com (GHC) Date: Sat Jan 3 12:51:14 2009 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.a586d6f6c37b027b74ba5201bad064e5@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc -------------------------+-------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by ingmar): * cc: ingmar@exherbo.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 3 17:28:32 2009 From: trac at galois.com (GHC) Date: Sat Jan 3 17:20:16 2009 Subject: [GHC] #2911: Error messages have the wrong qualified names Message-ID: <044.8624986823ff89b4d1097b22bfc58716@localhost> #2911: Error messages have the wrong qualified names -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: minor | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- This module: {{{ module Foo where import Data.ByteString.Lazy (ByteString) import qualified Data.ByteString.Lazy as BS import qualified Data.ByteString.Lazy.Char8 as BSC check :: ByteString -> Bool check bs = BS.empty bs }}} produces this type error: {{{ $ ghci -v0 q.hs q.hs:9:11: Couldn't match expected type `ByteString -> Bool' against inferred type `ByteString' In the expression: BSC.empty bs In the definition of `check': check bs = BSC.empty bs }}} i.e. it claims that the expression is `BSC.empty bs`, whereas the program text says `BS.empty bs`. Similarly, in this module: {{{ module Foo where import Data.ByteString.Lazy (ByteString) import qualified Data.ByteString.Lazy as BS import Data.ByteString.Lazy.Char8 check :: ByteString -> Bool check bs = BS.empty bs }}} the qualifier has disappeared completely in the error message: {{{ $ ghci -v0 q.hs q.hs:9:11: Couldn't match expected type `ByteString -> Bool' against inferred type `ByteString' In the expression: empty bs In the definition of `check': check bs = empty bs Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 3 20:57:25 2009 From: trac at galois.com (GHC) Date: Sat Jan 3 20:49:53 2009 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.809a78bf8bab6fd5201e203a15a122ae@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc -------------------------+-------------------------------------------------- Reporter: maeder | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by benl): * status: new => assigned * owner: => benl Comment: The problem seems to be caused by using a pinned register for gc_thread in rts/sm/GCThread.h. I'm testing a patch for this now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 3 21:46:52 2009 From: trac at galois.com (GHC) Date: Sat Jan 3 21:38:43 2009 Subject: [GHC] #1293: building ghc 6.8.3 hangs on sparc solaris at Language/Haskell/Syntax.hs In-Reply-To: <041.4743f2c5e5b193bbb97979ddc2558baa@localhost> References: <041.4743f2c5e5b193bbb97979ddc2558baa@localhost> Message-ID: <050.6d51a24dacd5dd7b31637c2a86383840@localhost> #1293: building ghc 6.8.3 hangs on sparc solaris at Language/Haskell/Syntax.hs ----------------------------------+----------------------------------------- Reporter: mm | Owner: benl Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: hangs compilation | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | ----------------------------------+----------------------------------------- Changes (by benl): * status: reopened => new * owner: => benl Comment: Current plan is to fix the SPARC native code generator and avoid GCC entirely. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 3 21:48:25 2009 From: trac at galois.com (GHC) Date: Sat Jan 3 21:40:13 2009 Subject: [GHC] #1293: building ghc 6.8.3 hangs on sparc solaris at Language/Haskell/Syntax.hs In-Reply-To: <041.4743f2c5e5b193bbb97979ddc2558baa@localhost> References: <041.4743f2c5e5b193bbb97979ddc2558baa@localhost> Message-ID: <050.b4b954da001c9abec4113c49d0be955e@localhost> #1293: building ghc 6.8.3 hangs on sparc solaris at Language/Haskell/Syntax.hs ----------------------------------+----------------------------------------- Reporter: mm | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: hangs compilation | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | ----------------------------------+----------------------------------------- Changes (by benl): * status: new => assigned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 3 22:21:50 2009 From: trac at galois.com (GHC) Date: Sat Jan 3 22:13:35 2009 Subject: [GHC] #186: Bad sparc Int64 code via NCG with -O In-Reply-To: <045.00b040dbc11af02e0fa7455a84a2a38a@localhost> References: <045.00b040dbc11af02e0fa7455a84a2a38a@localhost> Message-ID: <054.6d17966eab76acd80521cca1bd5a5d0c@localhost> #186: Bad sparc Int64 code via NCG with -O -------------------------------+-------------------------------------------- Reporter: nobody | Owner: benl Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler (NCG) | Version: 6.0.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: sparc | -------------------------------+-------------------------------------------- Changes (by benl): * testcase: => * status: assigned => new * owner: nobody => benl -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 3 22:22:42 2009 From: trac at galois.com (GHC) Date: Sat Jan 3 22:14:27 2009 Subject: [GHC] #186: Bad sparc Int64 code via NCG with -O In-Reply-To: <045.00b040dbc11af02e0fa7455a84a2a38a@localhost> References: <045.00b040dbc11af02e0fa7455a84a2a38a@localhost> Message-ID: <054.38557475fda146378a42e5074de8a9b2@localhost> #186: Bad sparc Int64 code via NCG with -O -------------------------------+-------------------------------------------- Reporter: nobody | Owner: benl Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler (NCG) | Version: 6.0.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: enum02 | Os: Unknown/Multiple Architecture: sparc | -------------------------------+-------------------------------------------- Changes (by benl): * testcase: => enum02 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 07:28:23 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 07:20:09 2009 Subject: [GHC] #2901: GHC crashes with "impossible happened ... RnEnv.lookupImportedName" if using DisambiguateRecordFields and qualifiers In-Reply-To: <050.9405f648f357f40a4eae06c7f56b7f1b@localhost> References: <050.9405f648f357f40a4eae06c7f56b7f1b@localhost> Message-ID: <059.5de2852050aaefce88dc40a8249ef136@localhost> #2901: GHC crashes with "impossible happened ... RnEnv.lookupImportedName" if using DisambiguateRecordFields and qualifiers -----------------------------------------+---------------------------------- Reporter: spookylukey | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rename/should_fail/T2901 | Os: Linux Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 07:28:44 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 07:20:28 2009 Subject: [GHC] #2888: Source file that compiled fine no longer compiles after touching it. In-Reply-To: <045.7d892b7ba37ca77835fa69178fb9751e@localhost> References: <045.7d892b7ba37ca77835fa69178fb9751e@localhost> Message-ID: <054.304cc2f11bea599dfe1c433397ba5abb@localhost> #2888: Source file that compiled fine no longer compiles after touching it. ------------------------------------------------+--------------------------- Reporter: Eelis- | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: indexed-types/should_fail/T2888 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 07:29:04 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 07:20:47 2009 Subject: [GHC] #2756: state hack causes unneeded value to be evaluated In-Reply-To: <044.fd970d5f81038e1e8c0cb54c1d8b0d1b@localhost> References: <044.fd970d5f81038e1e8c0cb54c1d8b0d1b@localhost> Message-ID: <053.b0bf971c19357d1a879563817ce844e8@localhost> #2756: state hack causes unneeded value to be evaluated -------------------------------------------+-------------------------------- Reporter: int-e | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: simplCore/should_run/T2756 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 07:47:34 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 07:39:15 2009 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> Message-ID: <050.36881e92740c479f78cdf40353698a84@localhost> #2721: Newtype deriving doesn't work with type families -------------------------------------------+-------------------------------- Reporter: rl | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2721 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by igloo): * type: merge => feature request * milestone: 6.10.2 => 6.12 branch Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 08:47:33 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 08:39:26 2009 Subject: [GHC] #2851: Improve error message for failed deriving In-Reply-To: <044.53dff063407021fb8c52e3be3626a0f5@localhost> References: <044.53dff063407021fb8c52e3be3626a0f5@localhost> Message-ID: <053.bb3b07d49eee9bb13c99a1ae52c0656d@localhost> #2851: Improve error message for failed deriving -------------------------------------------+-------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2851 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 08:47:33 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 08:39:29 2009 Subject: [GHC] #2856: GeneralizedNewtypeDeriving doesn't work with data families In-Reply-To: <044.b28574462f0debc35277b395a6c8b810@localhost> References: <044.b28574462f0debc35277b395a6c8b810@localhost> Message-ID: <053.5adb664fa62c08ff3b9e55198862c787@localhost> #2856: GeneralizedNewtypeDeriving doesn't work with data families ----------------------------------------------+----------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deriving/should_compile/T2856 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 10:26:19 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 10:18:00 2009 Subject: [GHC] #2898: crash when interpreting In-Reply-To: <045.4b1c4995fd828c01fa73119237ba0b1d@localhost> References: <045.4b1c4995fd828c01fa73119237ba0b1d@localhost> Message-ID: <054.fd5397b04e451d88964141fea0a094bc@localhost> #2898: crash when interpreting -------------------------+-------------------------------------------------- Reporter: nolrai | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 10:36:12 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 10:27:56 2009 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.0faf4254d9c638cc53cbe7e8e54d133f@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * type: merge => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 10:46:32 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 10:38:14 2009 Subject: [GHC] #2908: typo "reqwest" in documentation In-Reply-To: <047.3ce89554a050f21502c38cf3d1af61be@localhost> References: <047.3ce89554a050f21502c38cf3d1af61be@localhost> Message-ID: <056.5ea147fb6ef608f421379341fe678548@localhost> #2908: typo "reqwest" in documentation ---------------------------------+------------------------------------------ Reporter: bancroft | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown Comment: Thanks for the report; I'll fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 10:52:32 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 10:44:21 2009 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.c2601346ee64c785232787f6eff661c2@localhost> #2467: orphan instance warnings are badly behaved ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Replying to [comment:8 simonpj]: > Indeed, your code is legitimate, and that's why warnings are just warnings! > > More concretely, what would you like? A special kind of warning that (uniquely) does not make -Werror abort the compilation? That seems a bit irregular... But perhaps you have something in mind. Perhaps we should have separate control for two different classes of orphan warnings: * those where the class and all the types are in other packages (and thus you may not be able to easily avoid the instance, e.g. if everything is in the base package). * the rest -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 11:16:07 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 11:07:56 2009 Subject: [GHC] #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 In-Reply-To: <042.ed7dbc0df59c928988eada06283bfab4@localhost> References: <042.ed7dbc0df59c928988eada06283bfab4@localhost> Message-ID: <051.0bb37d4670c58db754296cf83f9cc64d@localhost> #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 -------------------------+-------------------------------------------------- Reporter: ozy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've updated the download page to say that Xcode 3.1 is required, and updated Building/MacOSX. I haven't merged the Building wiki pages, but that's orthogonal to this ticket, so I'm closing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 13:12:39 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 13:04:21 2009 Subject: [GHC] #2699: broken pipe errors are too noisy In-Reply-To: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> References: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> Message-ID: <053.95f3dc957a5e9878fd7d41ea167f0db1@localhost> #2699: broken pipe errors are too noisy ---------------------------------+------------------------------------------ Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Looks good, thanks! I've applied all of the bits related to adding `errno` to the `IOError` type. That leaves this bit: {{{ hunk ./GHC/TopHandler.lhs 171 - _ -> do reportError se - exit 1 + _ -> case cast exn of + Just IOError{ ioe_type = ResourceVanished, ioe_errno = Just ioe } + | Errno ioe == ePIPE -> exit 0 + _ -> do reportError se + exit 1 }}} Do we have consensus that silently exiting successfully is the right thing to do if we get a SIGPIPE? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 14:24:21 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 14:16:06 2009 Subject: [GHC] #2857: sync-all ignores --complete In-Reply-To: <045.4730aa92f2a05590e209c59fd9fc86c8@localhost> References: <045.4730aa92f2a05590e209c59fd9fc86c8@localhost> Message-ID: <054.cf75e07b2afd13a9c5e4830b879f6bec@localhost> #2857: sync-all ignores --complete ---------------------------------+------------------------------------------ Reporter: megacz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 14:25:28 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 14:17:11 2009 Subject: [GHC] #2908: typo "reqwest" in documentation In-Reply-To: <047.3ce89554a050f21502c38cf3d1af61be@localhost> References: <047.3ce89554a050f21502c38cf3d1af61be@localhost> Message-ID: <056.0b44f31942e3b8873bdfe275d86143cc@localhost> #2908: typo "reqwest" in documentation ---------------------------------+------------------------------------------ Reporter: bancroft | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and STABLE. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 14:41:01 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 14:32:55 2009 Subject: [GHC] #2759: Data.Generics.ConstrRep isn't general enough In-Reply-To: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> References: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> Message-ID: <053.53ddbadcb03febc84b91af184e47323f@localhost> #2759: Data.Generics.ConstrRep isn't general enough ----------------------------------+----------------------------------------- Reporter: guest | Owner: dreixel Type: bug | Status: assigned Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by igloo): Hmm, it seems inconsistent to have these two: {{{ mkIntConstr :: DataType -> Integer -> Constr mkFloatConstr :: (Real a) => DataType -> a -> Constr }}} Shouldn't it either be {{{ mkIntConstr :: DataType -> Integer -> Constr mkFloatConstr :: DataType -> Rational -> Constr }}} or {{{ mkIntConstr :: (Integral a) => DataType -> a -> Constr mkFloatConstr :: (Real a) => DataType -> a -> Constr }}} ? The `*Float*` names are also confusing, but presumably the plan is to transition away from them? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 15:21:07 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 15:12:52 2009 Subject: [GHC] #2877: crash when printig a list (IO ()) In-Reply-To: <044.0933e1ca77e0ef5175110397abfb4837@localhost> References: <044.0933e1ca77e0ef5175110397abfb4837@localhost> Message-ID: <053.029e36efe55ca7169c491317ca9954d6@localhost> #2877: crash when printig a list (IO ()) -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by igloo): Works for me on x86_64/Linux and x386/Windows, but I don't have x86_64/Windows. (nor was I using ghci from within emacs). Do you have a `.o` or `.hi` file for the module? If so, can you reproduce it after removing them? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 17:16:22 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 17:08:02 2009 Subject: [GHC] #2890: Library docs are missing source links In-Reply-To: <047.5d9f8bb2c0907720ec70f2f23485d487@localhost> References: <047.5d9f8bb2c0907720ec70f2f23485d487@localhost> Message-ID: <056.ceb4b9f10be0edc3c8f6ac007d3eb423@localhost> #2890: Library docs are missing source links ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): I've just pushed a patch that will cause the build to fail unless either !HsColour is found, or it's been explicitly disabled. This should highlight which builders don't have it installed, which I suspect is the reason the !HsColoured docs disappeared. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 17:19:39 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 17:11:21 2009 Subject: [GHC] #2865: Add more tab completions in GHCi for :set and :show In-Reply-To: <050.1d3854c99bbd9f86a838cbf3c9bfc105@localhost> References: <050.1d3854c99bbd9f86a838cbf3c9bfc105@localhost> Message-ID: <059.900931ef2062299dd2e779944936c853@localhost> #2865: Add more tab completions in GHCi for :set and :show ---------------------------------+------------------------------------------ Reporter: salty-horse | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.11 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 17:20:46 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 17:12:27 2009 Subject: [GHC] #2769: Export mapAccumR from Data.Map, Data.IntMap In-Reply-To: <047.6884ccd8725fc9653ca909dcd5164d50@localhost> References: <047.6884ccd8725fc9653ca909dcd5164d50@localhost> Message-ID: <056.f05e54e2edba01691feb8f5b9e81750c@localhost> #2769: Export mapAccumR from Data.Map, Data.IntMap ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: fixed Keywords: containers | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: `export-mapAccumRWithKey.patch` applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 4 17:24:42 2009 From: trac at galois.com (GHC) Date: Sun Jan 4 17:17:31 2009 Subject: [GHC] #1673: Template Haskell support for type families In-Reply-To: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> References: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> Message-ID: <074.13288c90399c57a8511d74ce0b7404e3@localhost> #1673: Template Haskell support for type families -------------------------------------------+-------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.12 branch Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by igloo): * priority: low => high * os: Linux => Unknown/Multiple * architecture: x86 => Unknown/Multiple * milestone: 6.10 branch => 6.12 branch Comment: Lots of interest, so I've raised the priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 03:46:15 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 03:38:28 2009 Subject: [GHC] #2907: generalized newtype deriving not working with polymorphic component In-Reply-To: <046.6f945c34c168084d94aff5d01ac7c016@localhost> References: <046.6f945c34c168084d94aff5d01ac7c016@localhost> Message-ID: <055.513cffa720470ddda8ce1beeb8caff70@localhost> #2907: generalized newtype deriving not working with polymorphic component ---------------------------------+------------------------------------------ Reporter: jeltsch | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: No, sorry, you'll have to write this one by hand! The newtype deriving stuff works when there is an existing instance that is related ''only by a newtype'' to the new instance you want. Thus {{{ newtype N = MkN }}} But there is no instance `Monad (forall result. ContT result monad o)`. One could imagine a further extension to handle this, somehow, but I don't think it'd be easy. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 04:06:12 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 03:58:03 2009 Subject: [GHC] #2759: Data.Generics.ConstrRep isn't general enough In-Reply-To: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> References: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> Message-ID: <053.9751f44f730379588621629b30bceee9@localhost> #2759: Data.Generics.ConstrRep isn't general enough ----------------------------------+----------------------------------------- Reporter: guest | Owner: dreixel Type: bug | Status: assigned Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by dreixel): The problem with {{{ mkFloatConstr :: DataType -> Rational -> Constr }}} is that it breaks existing code which uses 'mkFloatConstr'. I would then prefer to change 'mkIntConstr' to {{{ mkIntConstr :: (Integral a) => DataType -> a -> Constr }}} instead. I agree that the names are not ideal. We could also make them 'mkIntegralConstr' and 'mkRealConstr', deprecating the old ones, I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 04:25:52 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 04:17:32 2009 Subject: [GHC] #2911: Error messages have the wrong qualified names In-Reply-To: <044.8624986823ff89b4d1097b22bfc58716@localhost> References: <044.8624986823ff89b4d1097b22bfc58716@localhost> Message-ID: <053.fdda6057ebb2ec8a9e97f63d0c48dc69@localhost> #2911: Error messages have the wrong qualified names ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): This is a tricky one to fix. In both cases, the error message reports a ''valid'' way of referring to `empty`, just not the way that it was written in the source program. The trouble is that the renamer has replaced the `RdrName` (which is more or less just a string) "BS.empty" by the `Name` `Data.ByteString.Lazy.empty`, which uniquely identifies the thing referred to (regardless of the string used to name it in the source program). That is, the renamer converts `HsExpr RdrName` to `HsExpr Name`. So the type checker doesn't even know exactly how you originally referred to it. It'd be possible to retain the original text in the syntax tree, and perhaps better to do so. That is, make the renamer convert `HsExpr RdrName` to `HsExpr (RdrName,Name)`. This'd add a bit of code, and slow down every compilation, so I'm not convinced it's worth it. Let's see what others think. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 04:39:21 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 04:31:02 2009 Subject: [GHC] #2905: require -XGADTs in order to pattern-match GADTs In-Reply-To: <044.e288cc24bdc7d119176c55c76be624e8@localhost> References: <044.e288cc24bdc7d119176c55c76be624e8@localhost> Message-ID: <053.612add1329771ad0befe2e3486cec2de@localhost> #2905: require -XGADTs in order to pattern-match GADTs -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- Comment (by int-e): I also support requiring {{{-XGADTs}}} for pattern matching against GADT constructors - and I'd include the case where the GADT is really a plain data type or existential, because that makes the behaviour much easier to explain: "You used GADT syntax to define it, you need -XGADTs to pattern match against it." Merely mentioning GADTs in type signatures should work without the extension. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 06:55:35 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 06:47:16 2009 Subject: [GHC] #2659: Add sortOn and other *On functions In-Reply-To: <045.d1e80fa0049c474f9074e278f7023d7a@localhost> References: <045.d1e80fa0049c474f9074e278f7023d7a@localhost> Message-ID: <054.7223d914aead8afaacef3d2be5f393f0@localhost> #2659: Add sortOn and other *On functions ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): A function being in a GHC.* module isn't an argument for it not being put in a standard library, where it is available for any Haskell implementation, and where it is more likely to remain available in future releases. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 06:58:22 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 06:50:03 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.50dadbd03cdd9b15b0678551bb21c7f8@localhost> #789: BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO ------------------------+--------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------+--------------------------------------------------- Changes (by igloo): * summary: BCOs can only have 64k instructions => BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO Comment: See also: #2909 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 06:59:13 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 06:50:52 2009 Subject: [GHC] #2909: long list of names -> linkBCO: >= 64k insns in BCO In-Reply-To: <045.57b509387c9174e0d5555000f6f92fd8@localhost> References: <045.57b509387c9174e0d5555000f6f92fd8@localhost> Message-ID: <054.fc194f143d2366a8bb2d0fe41bc8aef1@localhost> #2909: long list of names -> linkBCO: >= 64k insns in BCO ---------------------------------+------------------------------------------ Reporter: jowens | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | 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 an older bug, #789. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 07:49:23 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 07:41:04 2009 Subject: [GHC] #2912: GHCi bug: bus error when executing some gsl-random core Message-ID: <048.fd42a972a38728467b869822f9f56943@localhost> #2912: GHCi bug: bus error when executing some gsl-random core ----------------------+----------------------------------------------------- Reporter: fdeweerdt | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- When compiling this simple program, the resulting executable runs fine, while running it under ghci causes a crash. It's gsl-random related obviously, but the difference in behaviour between plain ghc and ghci is somewhat odd. {{{ $ cat a.hs import Control.Monad import Control.Monad.MC import Control.Monad.MC.Class import GHC.Word seed = 57 buildRow el l = (sampleSubset el l [1..]) `evalMC` (mt19937 seed) main = do mapM_ putStrLn (map show ((buildRow 2 10) :: [Double])) $ ghc --make a.hs [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... $ ./a 1.0 6.0 $ ghci a.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Ok, modules loaded: Main. Prelude Main> main Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package gsl-random-0.2.3 ... linking ... done. Loading package uvector-0.1.0.3 ... linking ... done. Loading package monte-carlo-0.2 ... linking ... done. zsh: bus error ghci a.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 07:49:47 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 07:41:28 2009 Subject: [GHC] #2912: GHCi bug: bus error when executing some gsl-random code In-Reply-To: <048.fd42a972a38728467b869822f9f56943@localhost> References: <048.fd42a972a38728467b869822f9f56943@localhost> Message-ID: <057.9cb9e9caf5a2cfbbb0b3d329cb645228@localhost> #2912: GHCi bug: bus error when executing some gsl-random code -----------------------+---------------------------------------------------- Reporter: fdeweerdt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -----------------------+---------------------------------------------------- Changes (by fdeweerdt): * summary: GHCi bug: bus error when executing some gsl-random core => GHCi bug: bus error when executing some gsl- random code -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 08:54:49 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 08:46:33 2009 Subject: [GHC] #2422: Unrelated instance foils optimizer In-Reply-To: <048.44d8fab6eafad69dae1f639aff0c37d2@localhost> References: <048.44d8fab6eafad69dae1f639aff0c37d2@localhost> Message-ID: <057.3f0014780901df966565d7ac933f4b56@localhost> #2422: Unrelated instance foils optimizer --------------------------+------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | --------------------------+------------------------------------------------- Comment (by simonpj): Good example! This is indeed what is making #2416 go bad, but it's much easier to see here. I've unraveled what's happening; just recording it here so I don't forget again. These remarks are mainly for me, so they may seem a bit cryptic. From the instance for `(Storable (a:.a:.v))` we get something like {{{ Rec { $f3 = \d. MkStorable ...(pbo d)... pbo = \d. let pbo1 = peekByteOff ($f3 d) in \p q r. blah end Rec } }}} where `peekByteOff` is the method selector from the `Storable` class. (See `Note [How instance declarations are translated]` in `TcInstDcls` for the overall game plan.) Then the simplifier inlines `$f3`, thereby breaking the recursion, to give {{{ pbo = \d. let ...d... in \p q r. blah $f3 = \d. MkStorable ...(pbo d)... }}} Now, when you add the "unrelated" instance, the specialiser kicks in, and makes a specialised version of both functions: {{{ $spbo = \p q r. blah blah blah $sf3 = MkStorable ...$spbo... }}} We've specialised for a particular dictionary `d`, and that means we can inline the specialised methods into `$spbo`. Alas, that makes `$spbo` big, so now it does not inline into the users of `$sf3`. Before, it did. In effect the unspecialised version looked a lot smaller than the specialised version. But what about the INLINE pragma, you say? Well, it's hard to make it work right. If it attaches to the whole `pbo` we'd get {{{ Rec { $f3 = \d. MkStorable ...(pbo d)... pbo = __inline_me__ (\d. let pbo1 = peekByteOff ($f3 d) in \p q r. blah) end Rec } }}} But (for good reasons) we don't inline inside `__inline_me__`, so we won't get to break the recursive loop with `$f3`, which is terrible. GHC 6.10 currently pins the pragma on the body thus: {{{ Rec { $f3 = \d. MkStorable ...(pbo d)... pbo = \d. let pbo1 = peekByteOff ($f3 d) in __inline_me__ (\p q r. blah) end Rec } }}} but this does not work right either (because eta expansion loses that `__inline_me__`). I think the new inlining mechanism will help a lot, but I need to get it installed first. Stay tuned. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 08:56:01 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 08:47:40 2009 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.3ee82102b56097ff29a27d6cb0dbd1bc@localhost> #2416: Optimization defeated by merging module into main -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonpj): Indeed #2422 is a much more tractable example. No point in looking at #2416 further until #2422 is dealt with. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 13:13:04 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 13:04:43 2009 Subject: [GHC] #2911: Error messages have the wrong qualified names In-Reply-To: <044.8624986823ff89b4d1097b22bfc58716@localhost> References: <044.8624986823ff89b4d1097b22bfc58716@localhost> Message-ID: <053.c73553711d3d63ce9f0f681e9ac9e452@localhost> #2911: Error messages have the wrong qualified names ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by claus): don't know whether this helps, but there was a similar problem when implementing the extended `:browse!` in GHCi (see `compiler/ghci/InteractiveUI.hs`, `browseModule`), and I settled for the compromise of listing the names and possible import routes separately. So in the output of `ghc -e ':browse! *Foo'` for the second example, one finds {{{ .. -- imported via Data.ByteString.Lazy.Char8, BS .. empty :: ByteString .. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 17:47:30 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 17:39:12 2009 Subject: [GHC] #2746: Documentation for Haskell 98 modules is empty In-Reply-To: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> References: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> Message-ID: <056.cf09de0849270d0e17bd1d4855a0ea1e@localhost> #2746: Documentation for Haskell 98 modules is empty ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): HEAD now has: {{{ Fri Jan 2 21:38:27 GMT 2009 David Waern * Show re-exported names from external packages again This fixes GHC ticket 2746. In order to also link to the exported subordinate names of a declaration, we need to re-introduce the sub map in the .haddock files. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 5 18:21:47 2009 From: trac at galois.com (GHC) Date: Mon Jan 5 18:13:26 2009 Subject: [GHC] #2746: Documentation for Haskell 98 modules is empty In-Reply-To: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> References: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> Message-ID: <056.aa6c6ebf3600981e08f7f79dc3078b99@localhost> #2746: Documentation for Haskell 98 modules is empty ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): CTypes is still without docs, as reported here: http://www.haskell.org/pipermail/glasgow-haskell- users/2008-December/016374.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 05:22:11 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 05:13:47 2009 Subject: [GHC] #2558: re-throwing an asynchronous exception throws it synchronously In-Reply-To: <047.339350d6751eeb20e19b24c52175ed9b@localhost> References: <047.339350d6751eeb20e19b24c52175ed9b@localhost> Message-ID: <056.38ba6d50491dfb2e7729cc12d13e995f@localhost> #2558: re-throwing an asynchronous exception throws it synchronously ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | 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): So if an exception handler (for an asynchronous exception) divides by zero, that would be an asynchronous exception, right? Is that what we want? As an alternative, should we actually be throwing {{{ data SomeExceptionSync = SomeExceptionSync Bool -- synchronous? SomeException }}} with `catch` etc ignoring the `Bool`, but `bracket` etc handling it appropriately? This would also mean that tail-calling out of an exception handler would work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 05:51:40 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 05:43:17 2009 Subject: [GHC] #2558: re-throwing an asynchronous exception throws it synchronously In-Reply-To: <047.339350d6751eeb20e19b24c52175ed9b@localhost> References: <047.339350d6751eeb20e19b24c52175ed9b@localhost> Message-ID: <056.c69ccffeba0e4e9eaa308115e5f65247@localhost> #2558: re-throwing an asynchronous exception throws it synchronously ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | 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 int-e): My first instinct would be to pass a flag to exception handlers (changing the type of the {{{catch#}}} primitive, and the stack frame creation in {{{RaiseAsync.c}}} and {{{Exception.cmm}}} accordingly) to sort out at their leisure. Igloo's idea is similar in that would also pass a flag along with the exception, although the flag is set at a different point. I'm not sure which is easier to accomplish. It's already possible to use such a flag: {{{ throwAsync :: Exception e => e -> IO () throwAsync e = do target <- myThreadId throwTo target e throwSyncOrAsync :: Exception e => Bool -> e -> IO () throwSyncOrAsync async = if async then throwAsync else throwIO }}} If such a flag is added, I'd also like to have a variant of {{{catch}}} that gets to see it in {{{Control.Exception}}}, say, {{{ catchSyncOrAsync :: Exception e => IO a -> (Bool -> e -> IO a) -> IO a }}} and possibly {{{catchSync}}} and {{{catchAsync}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 06:21:06 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 06:12:43 2009 Subject: [GHC] #2558: re-throwing an asynchronous exception throws it synchronously In-Reply-To: <047.339350d6751eeb20e19b24c52175ed9b@localhost> References: <047.339350d6751eeb20e19b24c52175ed9b@localhost> Message-ID: <056.c3045bedc4869b08b67b1e656300e172@localhost> #2558: re-throwing an asynchronous exception throws it synchronously ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | 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 simonpj): See also [http://www.haskell.org/pipermail/glasgow-haskell- users/2008-December/016392.html this email thread] which, I believe, boiled down to the same issue. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 06:51:23 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 06:43:00 2009 Subject: [GHC] #2699: broken pipe errors are too noisy In-Reply-To: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> References: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> Message-ID: <053.c09c02852aef67209563209826a65c82@localhost> #2699: broken pipe errors are too noisy ---------------------------------+------------------------------------------ Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:5 igloo]: > Do we have consensus that silently exiting successfully is the right thing to do if we get a SIGPIPE? Perhaps we should only exit silenty if the EPIPE was received for `stdin` or `stdout`? One problem we had with the silent `SIGPIPE` was that it happened for closed sockets, which confused people regularly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 07:01:45 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 06:53:21 2009 Subject: [GHC] #2558: re-throwing an asynchronous exception throws it synchronously In-Reply-To: <047.339350d6751eeb20e19b24c52175ed9b@localhost> References: <047.339350d6751eeb20e19b24c52175ed9b@localhost> Message-ID: <056.cf7c92fbcd559f391d0a7dc5fcc54660@localhost> #2558: re-throwing an asynchronous exception throws it synchronously ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | 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 simonmar): Replying to [comment:4 igloo]: > So if an exception handler (for an asynchronous exception) divides by zero, that would be an asynchronous exception, right? Is that what we want? Yes, I believe that's what we want. If the exception handler throws a divide-by-zero, and it did so as a result of an asynchronous exception (say `ThreadKilled`), then we don't want to update any thunks with the divide-by-zero exception, we want to revert them as for an asynchronous exception. > As an alternative, should we actually be throwing > {{{ > data SomeExceptionSync = SomeExceptionSync Bool -- synchronous? > SomeException > }}} > with `catch` etc ignoring the `Bool`, but `bracket` etc handling it appropriately? This would also mean that tail-calling out of an exception handler would work. Tail-calling out of an exception handler also has the problem that it leaves the thread in the blocked (i.e. `Control.Exception.block`ed) state. IMO we should be using and recommending `try` rather than `catch` for handling exceptions as per the description in this bug. I haven't put any more thought into the suggestions in this thread yet... will do later. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 07:03:56 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 06:55:31 2009 Subject: [GHC] #2558: re-throwing an asynchronous exception throws it synchronously In-Reply-To: <047.339350d6751eeb20e19b24c52175ed9b@localhost> References: <047.339350d6751eeb20e19b24c52175ed9b@localhost> Message-ID: <056.0a3c0b5f030ff635067db145b27cb8f9@localhost> #2558: re-throwing an asynchronous exception throws it synchronously ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | 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 simonmar): Replying to [comment:5 int-e]: > My first instinct would be to pass a flag to exception handlers (changing the type of the {{{catch#}}} primitive, and the stack frame creation in {{{RaiseAsync.c}}} and {{{Exception.cmm}}} accordingly) to sort out at their leisure. Igloo's idea is similar in that would also pass a flag along with the exception, although the flag is set at a different point. I'm not sure which is easier to accomplish. > > It's already possible to use such a flag: > {{{ > throwAsync :: Exception e => e -> IO () > throwAsync e = do > target <- myThreadId > throwTo target e > > throwSyncOrAsync :: Exception e => Bool -> e -> IO () > throwSyncOrAsync async = if async then throwAsync else throwIO > }}} Good point - and so a partial workaround for this bug is to always throw asynchronous exceptions like `ThreadKilled` using `throwAsync`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 07:45:17 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 07:36:54 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.a0d212027a8415f6d61b06defca0d030@localhost> #2881: Basic Fibonacci function using Word causes ghci to panic. - 6.10.1 -------------------------------------+-------------------------------------- Reporter: axman6 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: panic Word fibonacci | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------------+-------------------------------------- Comment (by simonmar): There's no good reason for this not to work, but it's not a 1-line fix. I'll try to get around to it sometime. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 07:45:44 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 07:37:21 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.d59b36783a9815696da721f7b3169d8d@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.10 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 | -------------------------------------+-------------------------------------- Changes (by simonmar): * priority: normal => low * difficulty: Unknown => Easy (1 hr) * component: Compiler => GHCi * architecture: x86 => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 07:48:01 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 07:39:44 2009 Subject: [GHC] #2904: Broken pipe when quitting "ghc --show-iface file.hi | less" In-Reply-To: <047.1dde102b30eaac69c74e2b5b730d160f@localhost> References: <047.1dde102b30eaac69c74e2b5b730d160f@localhost> Message-ID: <056.f768f2f1f523ac725e67bd2294027b16@localhost> #2904: Broken pipe when quitting "ghc --show-iface file.hi | less" ---------------------------------+------------------------------------------ Reporter: Syzygies | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: trivial | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: See #2699 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 07:51:07 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 07:42:43 2009 Subject: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked In-Reply-To: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> References: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> Message-ID: <053.c0d0f7a646351b9a5041cd62428b6fa7@localhost> #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked ---------------------------------+------------------------------------------ Reporter: int-e | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Easy (1 hr) * os: Linux => Unknown/Multiple * architecture: x86 => Unknown/Multiple * milestone: => 6.10.2 Comment: Good bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 07:56:45 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 07:48:24 2009 Subject: [GHC] #2912: GHCi bug: bus error when executing some gsl-random code In-Reply-To: <048.fd42a972a38728467b869822f9f56943@localhost> References: <048.fd42a972a38728467b869822f9f56943@localhost> Message-ID: <057.7e8f2f84d30d8ea9cdb9fd8a6a3c20fd@localhost> #2912: GHCi bug: bus error when executing some gsl-random code -------------------------------+-------------------------------------------- Reporter: fdeweerdt | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Comment: Bus errors are pretty serious. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 08:01:03 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 07:52:40 2009 Subject: [GHC] #2911: Error messages have the wrong qualified names In-Reply-To: <044.8624986823ff89b4d1097b22bfc58716@localhost> References: <044.8624986823ff89b4d1097b22bfc58716@localhost> Message-ID: <053.744b5c6044774e05fd78ef3e96451482@localhost> #2911: Error messages have the wrong qualified names ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => low * milestone: => 6.12 branch Comment: An alternative way to fix it would be to quote the program source text verbatim. We have a supposedly-accurate source span for the error message, so it would be possible to extract the actual program text from the source file and display that. Not that I think it's worthwhile spending a lot of time to get this right, mind you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 09:12:49 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 09:04:25 2009 Subject: [GHC] #2913: OldException's catch etc should treat new Exception types as DynException's Message-ID: <044.32b88c5c6278c8a1dcec6524f5b05c54@localhost> #2913: OldException's catch etc should treat new Exception types as DynException's -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- `OldException`'s catch etc should treat new `Exception` types as `DynException`'s. Currently new style exceptions are just not caught, which is a bug. It also means that cleaning up with functions like `finally` doesn't work properly. Additionally, functions like `bracket`, `onException`, `finally` which don't actually exposed the exception type could just use the new functions directly, rather than reimplementing them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 09:29:56 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 09:21:35 2009 Subject: [GHC] #2914: RecordWildCards doesn't work with associated datatypes inside class instances Message-ID: <045.003431a2c8a375b9d493daaeb2179785@localhost> #2914: RecordWildCards doesn't work with associated datatypes inside class instances -----------------------------+---------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It seems like record wildcards (the ".." notation) don't work in the following scenario. I tried with a standalone associated datatype and it works fine. Tested with 6.10.1 and 6.11.20090103. {{{ {-# LANGUAGE TypeFamilies, RecordWildCards #-} module AssocWildCards where class FooClass a where data FooType a instance FooClass Int where data FooType Int = FooInt { fooIntVal :: Int } fooInt :: Int -> FooType Int fooInt fooIntVal = FooInt{..} fromFooInt :: FooType Int -> Int fromFooInt FooInt{..} = fooIntVal }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 09:48:47 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 09:40:30 2009 Subject: [GHC] #2913: OldException's catch etc should treat new Exception types as DynException's In-Reply-To: <044.32b88c5c6278c8a1dcec6524f5b05c54@localhost> References: <044.32b88c5c6278c8a1dcec6524f5b05c54@localhost> Message-ID: <053.fa8522ee715f319d4086e1ccf0d0fac7@localhost> #2913: OldException's catch etc should treat new Exception types as DynException's ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by StephenBlackheath): Output of 'exceptions.hs' test case on GHC 6.10.1: blackh@amentet:~/src/metabarter$ ghc -o exceptions exceptions.hs --make [1 of 1] Compiling Main ( exceptions.hs, exceptions.o ) Linking exceptions ... blackh@amentet:~/src/metabarter$ ./exceptions exceptions: ThrowHandsUpInTheAirException "oh no!" blackh@amentet:~/src/metabarter$ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 10:41:32 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 10:33:09 2009 Subject: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked In-Reply-To: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> References: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> Message-ID: <053.89ecb59d8452588f75ebaae0357c7933@localhost> #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked ---------------------------------+------------------------------------------ Reporter: int-e | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Tue Jan 6 15:32:54 GMT 2009 Simon Marlow * wake up the blocked exception queue on ThreadFinished; fixes #2910 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 11:51:58 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 11:43:34 2009 Subject: [GHC] #2915: Arity is smaller than need be Message-ID: <046.a17f452375c6b159ed122bce785e3f8a@localhost> #2915: Arity is smaller than need be ---------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ Consider {{{ h x = let f = case x of { True -> t1; False -> t2 } in (f,f) }}} where `t1` and `t2` have arity 1. You'd think that `f` should have arity 1, but it doesn't. (Reason: `exprArity`, used in `Simplify.addNonRecWithUnf`, doesn't look through the case.) Fix this as part of the upcoming arity cleanup. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 13:01:36 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 12:53:55 2009 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.394f82c874389125944b375bb60ff67c@localhost> #1346: bootstrap from HC files ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 14:15:03 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 14:06:40 2009 Subject: [GHC] #2558: re-throwing an asynchronous exception throws it synchronously In-Reply-To: <047.339350d6751eeb20e19b24c52175ed9b@localhost> References: <047.339350d6751eeb20e19b24c52175ed9b@localhost> Message-ID: <056.667cfbd836c7a10a11dbe8ec18afa268@localhost> #2558: re-throwing an asynchronous exception throws it synchronously ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | 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 | ---------------------------------+------------------------------------------ Changes (by guest): * cc: id@isaac.cedarswampstudios.org (added) Comment: Replying to [comment:5 int-e]: > throwAsync :: Exception e => e -> IO () > throwAsync e = do > target <- myThreadId > throwTo target e nitpick: what if throwAsync is called when in blocked mode? does it need to do `unblock (throwTo target e)` in order for the self-exception to arrive? (or maybe the RTS already side-steps this deadlock?) -Isaac Dupree -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 14:22:18 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 14:14:35 2009 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.96d329800cc1366b1864923aff4a4968@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc -------------------------+-------------------------------------------------- Reporter: maeder | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Comment (by maeder): With your patch I was able to create a working stage2 compiler. A minimal binary-dist without extra-libs is under http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/solaris/ghcs/ghc-6.10.1 -sparc-sun-solaris2.tar.bz2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 14:25:24 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 14:17:00 2009 Subject: [GHC] #2911: Error messages have the wrong qualified names In-Reply-To: <044.8624986823ff89b4d1097b22bfc58716@localhost> References: <044.8624986823ff89b4d1097b22bfc58716@localhost> Message-ID: <053.4a798696996a23d8a708ed59dccc5e3d@localhost> #2911: Error messages have the wrong qualified names ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: id@isaac.cedarswampstudios.org (added) Comment: I vote for caring more about source-correct error messages! I thought, if it makes compilation slower, maybe we can add a compiler flag to turn it on and off -- but I doubt that would actually work to preserve the fast case :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 14:40:32 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 14:32:07 2009 Subject: [GHC] #2916: Adding "-auto-all" when using "-O2 -prof" causes "<>" Message-ID: <049.104e5ce0692c10d94ee0be86a698b1ee@localhost> #2916: Adding "-auto-all" when using "-O2 -prof" causes "<>" --------------------------+------------------------------------------------- Reporter: BenMoseley | Owner: Type: bug | Status: new Priority: normal | Component: Profiling Version: 6.10.1 | Severity: normal Keywords: loop auto-all | Testcase: Os: Windows | Architecture: x86 --------------------------+------------------------------------------------- The program below works fine (and outputs "ZeroPmt") when compiled with "-O2 -prof -fno-cse", but when you add in "-auto-all" it causes "<>". There are many ways to workaround the problem, uncommenting pretty much any of the commented-out lines avoids the issue, but my impression is that adding "-auto-all" shouldn't cause this. This is with stock 6.10.1. "-dcore-lint" has no effect. {{{ -- -- Compile with : ghc -O2 -prof -auto-all -fno-cse --make ~/loop.hs -- -- ...and it breaks, outputting <> -- ...compile without "-auto-all" and you get ZeroPmt -- import Data.IORef import qualified Data.Map as Map import System.IO import System.IO.Unsafe import System.Mem.StableName main :: IO () main = do -- putStrLn $ show $ unHC $ mkHC ZeroPmt -- Works OK putStrLn $ show $ unHC $ mkHC $ unHC $ mkHC ZeroPmt data Expr = Add | ZeroPmt deriving (Ord, Eq, Show) data ExprHC = ExprHC { unStableName :: !(StableName Expr), unHC :: !Expr} deriving (Eq) -- {-# NOINLINE mkHC #-} -- Works OK -- mkHC e = hashConser e -- Works OK mkHC = hashConser {-# NOINLINE hashConser #-} hashConser :: Expr -> ExprHC hashConser e = deepSeq e (unsafePerformIO $ mkHC' e) -- hashConser e = seq (e == e) (unsafePerformIO $ mkHC' e) where refTbl = unsafePerformIO $ newIORef Map.empty mkHC' e = do tbl <- readIORef refTbl case Map.lookup e tbl of Just ehc -> return ehc Nothing -> do sn <- makeStableName e let ehc = ExprHC sn e writeIORef refTbl $ Map.insert e ehc tbl return ehc deepSeq :: Eq e => e -> x -> x deepSeq e x = seq (e == e) x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 14:59:06 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 14:50:42 2009 Subject: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked In-Reply-To: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> References: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> Message-ID: <053.f8a95c3a5977fab53f67c26c41467d0c@localhost> #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked ---------------------------------+------------------------------------------ Reporter: int-e | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by int-e): As the patches I just attached suggest, this race is not completely fixed. (I'm pretty certain - Conal's TestRace program locks up without the first patch, but works fine so far with it. I also have a modified version that logs thread creation and throwTo and shows the program lock up with all threads finished except the main thread, which is blocked on an exception.) The second patch contains changes unrelated to this bug which I'm not 100% certain about - but they felt necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 15:16:58 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 15:08:41 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment Message-ID: <044.ae4012da6404813e981e2064d26c5c85@localhost> #2917: alloca and allocaArray do not respect alignment -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -----------------------------+---------------------------------------------- When allocating memory with alloca or allocaArray the alignment of the Storable is not respected, alignment seems to be on 8 byte boundary. malloc and mallocArray seem to have the same problem. And because of this functions like withArray etc also break the alignment restriction of the array element. Run this and look at the pointer. {{{ import Foreign.Ptr import Foreign.Storable import Foreign.Marshal.Array import Foreign.Marshal data Foo = Foo instance Storable Foo where sizeOf _ = 8 alignment _ = 256 main = allocaArray 5 $ \ p -> do let _ = p :: Ptr Foo print p q <- mallocArray 5 let _ = q :: Ptr Foo print q }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 15:20:52 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 15:12:33 2009 Subject: [GHC] #2918: Storable alignment for Double is 4 Message-ID: <044.13a85fce6c4d3b10c8f7973ca5cbd3d7@localhost> #2918: Storable alignment for Double is 4 -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -----------------------------+---------------------------------------------- The alignment for Double is 4. This makes little sense, it should be 8. That's the alignment that guarantees best performance, and is also necessary on some architectures. (On x86 a Double can be byte align, so any value from 1 and up works for the alignment, but 8 is the natural one.) {{{ import Foreign.Storable main = print (alignment (0::Double)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 6 22:28:22 2009 From: trac at galois.com (GHC) Date: Tue Jan 6 22:19:55 2009 Subject: [GHC] #2919: ghc panic while compiling Crypto Message-ID: <045.deee858f6ff0d3e43625e8810078b454@localhost> #2919: ghc panic while compiling Crypto -------------------+-------------------------------------------------------- Reporter: wchogg | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- While compiling the Crypto 4.1.0 library from hackage I received the following error [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test /SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug What more information will be useful? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 04:31:46 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 04:30:25 2009 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.bb29f8d814dce137937c9c2cfb96cd04@localhost> #1346: bootstrap from HC files ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by kgardas): * cc: karel.gardas@centrum.cz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 05:20:38 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 05:12:13 2009 Subject: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked In-Reply-To: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> References: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> Message-ID: <053.f20bd6be441d9bfd2617464317897acc@localhost> #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked ---------------------------------+------------------------------------------ Reporter: int-e | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:3 int-e]: > As the patches I just attached suggest, this race is not completely fixed. (I'm pretty certain - Conal's TestRace program locks up without the first patch, but works fine so far with it. I also have a modified version that logs thread creation and throwTo and shows the program lock up with all threads finished except the main thread, which is blocked on an exception.) > > The second patch contains changes unrelated to this bug which I'm not 100% certain about - but they felt necessary. Thanks - it's nice to have someone else looking at this code! In response to your patches: {{{ hunk ./rts/RaiseAsync.c 418 // Unblocking BlockedOnSTM threads requires the TSO to be // locked; see STM.c:unpark_tso(). if (target->why_blocked != BlockedOnSTM) { + unlockTSO(target); goto retry; } if ((target->flags & TSO_BLOCKEX) && }}} well spotted. {{{ hunk ./rts/RaiseAsync.c 440 // thread is blocking exceptions, and block on its // blocked_exception queue. lockTSO(target); + if (target->why_blocked != BlockedOnCCall && + target->why_blocked != BlockedOnCCall_NoUnblockExc) { + unlockTSO(target); + return; + } blockedThrowTo(cap,source,target); *out = target; return THROWTO_BLOCKED; }}} again, well spotted - except that we want `goto retry` rather than `return`. {{{ hunk ./rts/RaiseAsync.c 267 target = target->_link; goto retry; } + // The thread may also have finished in the meantime. + if (target->what_next == ThreadKilled + || target->what_next == ThreadComplete) { + unlockTSO(target); + return THROWTO_SUCCESS; + } blockedThrowTo(cap,source,target); *out = target; return THROWTO_BLOCKED; }}} `lockTSO()` doesn't lock the `what_next` field, only the `blocked_exceptions` field, so I think this change is not necessary. {{{ hunk ./rts/RaiseAsync.c 555 void awakenBlockedExceptionQueue (Capability *cap, StgTSO *tso) { + lockTSO(tso); + // Taking the tso lock before the following check assures that we + // wait for any throwTo that may just be adding a new thread to the + // queue. This is essential, because we may not get another chance + // to wake up that thread. if (tso->blocked_exceptions != END_TSO_QUEUE) { hunk ./rts/RaiseAsync.c 561 - lockTSO(tso); awakenBlockedQueue(cap, tso->blocked_exceptions); tso->blocked_exceptions = END_TSO_QUEUE; hunk ./rts/RaiseAsync.c 563 - unlockTSO(tso); } hunk ./rts/RaiseAsync.c 564 + unlockTSO(tso); } }}} This is not necessary. However, while figuring out why, I did find the real bug. Threads that fall through the cracks and end up on the blocked_exceptions list of a finished or blocked target thread are supposed to be caught by the GC (see comments at line 216 in `MarkWeak.c`). However, this wasn't working in the case when the target thread had finished, because `maybePerformBlockedException()` wasn't handling the `ThreadComplete` or `ThreadKilled` case, so I've fixed that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 07:14:13 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 07:05:47 2009 Subject: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked In-Reply-To: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> References: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> Message-ID: <053.c910cceed61c8e183b28eb94f2f76309@localhost> #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked ---------------------------------+------------------------------------------ Reporter: int-e | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by int-e): Replying to [comment:4 simonmar]: > Thanks - it's nice to have someone else looking at this code! You're welcome. > `lockTSO()` doesn't lock the `what_next` field, only the `blocked_exceptions` field, so I think this change is not necessary. Ah, I see. But I believe that the change still makes sense - see below. > Threads that fall through the cracks and end up on the blocked_exceptions list of a finished or blocked target thread are supposed to be caught by the GC ... And that's the part I missed, although admittedly I'm a bit unhappy about waiting for the next GC. Does the RTS perform a GC when it finds no other work? In any case, there'll be some wait. Now I believe we can prevent this from happening, with those two hunks above. The key idea is that once the {{{what_next}}} field is set to {{{ThreadComplete}}} or {{{ThreadKilled}}}, it will not be modified again. As you wrote in the comment in {{{scheduleHandleThreadFinished}}}, {{{what_next}}} has already been set when {{{awakenBlockedExceptionQueue}}} is called. So the only scenario we have to prevent is that a thread throwing an exception finds its target running, and then adds itself to the target's {{{blocked_exception}}} queue, with the target thread completing and running {{{awakenExceptionQueue}}} inbetween those two steps. This can be accomplished by making {{{awakenExceptionQueue}}} take the TSO lock every time, *and* checking whether the target has finished between taking the TSO lock and calling {{{blockedThrowTo}}} for all calls to {{{blockedThrowTo}}}, unless we can prove that the thread cannot finish in the meantime. My changes only covered the {{{NotBlocked}}} case. I believe that in the {{{Blocked*}}} cases, the thread cannot finish in the meantime (they lock the TSO, directly or indirectly, and then check that the thread is still blocked - which implies that it has not finished), but I'm 100% not certain. To summarize: We would not use the TSO lock to protect the {{{what_next}}} field - we'd use (or abuse?) it to prevent a specific race between {{{blockedThrowTo}}} and {{{awakenExceptionQueue}}}. I think the benefits are clear: We avoid one case of the RTS having to wait for a GC. The cost seems bearable: {{{awakenExceptionQueue}}} is only called when a thread finishes or when it returns from a C call (and in the latter case, we could continue to use the old variant). Both cases aren't exactly fast paths. Then there's a cost in code complexity (the reasoning is fairly tricky) - but that's your judgement call. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 08:26:06 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 08:17:39 2009 Subject: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked In-Reply-To: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> References: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> Message-ID: <053.d47d454174e685ae683c986203e14cd0@localhost> #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked ---------------------------------+------------------------------------------ Reporter: int-e | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Yes, I realise your patch was aimed at closing the race. I was worried about the cost of doing an unconditional `lockTSO` on thread exit, and the complexity of the invariant. However, I haven't been able to measure a difference in performance (yet!) so I'll probably go with your version (but also with my fixes, a little extra robustness won't hurt). The GC runs after 0.3 seconds of non-activity, BTW. This is tunable with the `+RTS -I` flag. Also, while playing with Conal's TestRace program I found two more races, patches to follow. yay! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 09:10:51 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 09:02:57 2009 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> Message-ID: <053.ccf274a2ce1f2d4435593ab004abcc6a@localhost> #1475: Adding imports and exports with Template Haskell ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by Deewiant): * cc: Deewiant (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 09:22:43 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 09:14:16 2009 Subject: [GHC] #1800: Template Haskell support for running functions defined in the same module In-Reply-To: <046.b7ebbbf4b1c0103c70b5120f313233b6@localhost> References: <046.b7ebbbf4b1c0103c70b5120f313233b6@localhost> Message-ID: <055.b5d4d82ac5719eb2ce257603adf04d0d@localhost> #1800: Template Haskell support for running functions defined in the same module ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by Deewiant): * cc: Deewiant (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 10:09:07 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 10:00:40 2009 Subject: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked In-Reply-To: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> References: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> Message-ID: <053.361636c19f9ff0e140efee3844d82927@localhost> #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked ---------------------------------+------------------------------------------ Reporter: int-e | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): More patches to merge: {{{ Wed Jan 7 11:20:26 GMT 2009 Simon Marlow * putMVar and takeMVar: add write_barrier() to fix race with throwTo Wed Jan 7 12:06:52 GMT 2009 Simon Marlow * fix a race where the timer signal could remain turned off, leading to deadlock Wed Jan 7 12:07:34 GMT 2009 Simon Marlow * maybePerformBlockedException() should handle ThreadComplete/ThreadKilled Part of the fix for #2910 Wed Jan 7 12:08:08 GMT 2009 Bertram Felgenhauer * Fix two more locking issues in throwTo() Wed Jan 7 12:11:42 GMT 2009 Simon Marlow * add comment Wed Jan 7 14:05:07 GMT 2009 Simon Marlow * Close the races between throwTo and thread completion Any threads we missed were being caught by the GC (possibly the idle GC if the system was otherwise inactive), but that's not ideal. The fix (from Bertram Felgenhauer) is to use lockTSO to synchronise, imposing an unconditional lockTSO on thread exit. I couldn't measure any performance overhead from doing this, so it seems reasonable. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 11:00:32 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 10:52:21 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.4c38faa3ceae556294a41bd7962b8328@localhost> #2917: alloca and allocaArray do not respect alignment ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 ------------------------------+--------------------------------------------- Comment (by guest): I've added a patch to use the alignment when allocating. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 11:32:58 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 11:24:35 2009 Subject: [GHC] #849: Offer control over branch prediction In-Reply-To: <046.9c1a3dec0191543ee72b98b43c5f5f89@localhost> References: <046.9c1a3dec0191543ee72b98b43c5f5f89@localhost> Message-ID: <055.22ab0b86d11f39252d4dae9dbac32655@localhost> #849: Offer control over branch prediction ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by tibbe): * cc: johan.tibell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 14:23:51 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 14:15:22 2009 Subject: [GHC] #2920: old-time on hackage is incorrectly packaged Message-ID: <043.fc91947b3a4dcf1c67f768ea035c6866@localhost> #2920: old-time on hackage is incorrectly packaged -----------------------------+---------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: libraries (old-time) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- old-time is missing its ./configure script: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/old-time {{{ $ tar xzf old-time-1.0.0.0.tar.gz $ cd old-time-1.0.0.0 $ ls LICENSE Setup.hs System cbits include old-time.cabal }}} It needs: {{{ $ cd ghc/libraries/old-time $ ls LICENSE System aclocal.m4 cbits configure.ac old-time.cabal Setup.hs _darcs autom4te.cache configure include prologue.t }}} i.e. its ./configure script. This leads to cabal install failures, for example -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 16:38:20 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 16:29:53 2009 Subject: [GHC] #2746: Documentation for Haskell 98 modules is empty In-Reply-To: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> References: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> Message-ID: <056.aba371dbc13ee7742d9a642e454e15cf@localhost> #2746: Documentation for Haskell 98 modules is empty ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by waern): Ok, so the problem with links that goes to the wrong place is now fixed with this patch (in the HEAD): {{{ Wed Jan 7 00:34:17 CET 2009 David Waern * Do not process boot modules We should of course not try to produce documentation for boot modules! The reason this has worked in the past is that the output of "real" modules overwrites the output of boot modules later in the process. However, this causes a subtle link environment problem. So let's get rid of this stupid behaviour. We avoid processing boot modules, but we continue to typecheck them. }}} So that was a Haddock bug and not a GHC one. Now Char from haskell98 has links to definitions in Data.Char and GHC.Types. Will tackle CTypes and the likes next. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 7 18:55:07 2009 From: trac at galois.com (GHC) Date: Wed Jan 7 18:46:38 2009 Subject: [GHC] #2921: __GLASGOW_HASKELL__ undefined Message-ID: <044.5d41f7fb4e60b06c4b614bb62c74874c@localhost> #2921: __GLASGOW_HASKELL__ undefined -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- After manually forcing adding HsFFI.h to the search path of hsc2hs -- which is also broken, as reported in another bug -- __GLASGOW_HASKELL__ still seems to be undefined, breaking detections. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 04:56:49 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 04:48:19 2009 Subject: [GHC] #2873: ghc-pkg list/dump --package-conf=missing returns successful error code In-Reply-To: <045.d3448bbf66f00ef8dc9dae0dc42ea1ff@localhost> References: <045.d3448bbf66f00ef8dc9dae0dc42ea1ff@localhost> Message-ID: <054.904c09cb317743a19a6059368e402c31@localhost> #2873: ghc-pkg list/dump --package-conf=missing returns successful error code ---------------------------------+------------------------------------------ Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 05:34:51 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 05:26:22 2009 Subject: [GHC] #2922: GHC panic: Non-exhaustive patterns in function printTarget Message-ID: <047.a2932b4f2dceaa344931475e1143a215@localhost> #2922: GHC panic: Non-exhaustive patterns in function printTarget ---------------------+------------------------------------------------------ Reporter: matthijs | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 ---------------------+------------------------------------------------------ When running ghci or ghc on Translator.hs (given below) and running it, they crash with a panic. {{{ $ ghci --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 $ ghci -package ghc Translator.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package filepath-1.1.0.1 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.1 ... linking ... done. Loading package unix-2.3.1.0 ... linking ... done. Loading package directory-1.0.0.2 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package process-1.0.1.0 ... linking ... done. Loading package Cabal-1.6.0.1 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package editline-0.2.1.0 ... linking ... done. Loading package random-1.0.0.1 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package hpc-0.5.0.2 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package ghc-6.10.1 ... linking ... done. [1 of 1] Compiling Main ( Translator.hs, interpreted ) Ok, modules loaded: Main. *Main> main Loading package ghc-paths-0.1.0.5 ... linking ... done. : panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): Translator.hs:(20,0)-(21,16): Non-exhaustive patterns in function printTarget Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** Exception: ExitFailure 1 *Main> }}} and ghc: {{{ $ ghc -L/usr/local/ghc-6.10.1/lib/ghc-paths-0.1.0.5/ghc-6.10.1 -lHSghc- paths-0.1.0.5 -package ghc Translator.hs $ ./a.out a.out: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): Translator.hs:(20,0)-(21,16): Non-exhaustive patterns in function printTarget Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The file is based on the GHC as a library example and tries to extract some data from a Target, which fails. It can probably be reduced somewhat, but I'm still too much stumbling around to effecitvely do this. The file that's being compiled ("noexist.hs" in the file) need not exist, but results are not any different when it does. Here's Translator.hs: {{{ module Main(main) where import GHC import MonadUtils ( liftIO ) import Outputable ( showSDoc, ppr ) import GHC.Paths ( libdir ) import DynFlags ( defaultDynFlags ) main = do defaultErrorHandler defaultDynFlags $ do runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags dflags target <- guessTarget "noexist.hs" Nothing --liftIO (print (showSDoc (ppr (target)))) liftIO $ printTarget target setTargets [target] load LoadAllTargets printTarget (Target id obj (Just (buf, time))) = print $ show buf }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 05:44:17 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 05:35:46 2009 Subject: [GHC] #2922: GHC panic: Non-exhaustive patterns in function printTarget In-Reply-To: <047.a2932b4f2dceaa344931475e1143a215@localhost> References: <047.a2932b4f2dceaa344931475e1143a215@localhost> Message-ID: <056.06358d70650287980dca67cbe0abc906@localhost> #2922: GHC panic: Non-exhaustive patterns in function printTarget ----------------------+----------------------------------------------------- Reporter: matthijs | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------+----------------------------------------------------- Changes (by matthijs): * status: new => closed * resolution: => invalid Comment: Oh, I think I just found out what this bug is about. It's simply an error in my code, but because it runs inside the Ghc error handler, it says "Report this as a GHC bug" in the output", making me think I found a GHC bug... Closing this bug again, sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 05:46:03 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 05:37:41 2009 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.9039d90047f40cf17083503d7af6d77f@localhost> #1074: -fwarn-unused-imports complains about wrong import ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ganesh): * cc: neil.mitchell.2@credit-suisse.com (removed) * cc: ganesh.sittampalam@credit-suisse.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 06:17:37 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 06:09:07 2009 Subject: [GHC] #2923: Documentation contains (broken) links to /home/ian Message-ID: <047.8599083b3310893fae769d528dbb6224@localhost> #2923: Documentation contains (broken) links to /home/ian -----------------------------+---------------------------------------------- Reporter: matthijs | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The GHC API documentation (and possibly other modules as well) contain broken links. In particular, all links to "!FilePath" on http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html point to http://www.haskell.org/home/ian/6.10.1/ghc-6.10.1/libraries/base/dist/doc/html/base /System-IO.html#t%3AFilePath which is a broken link. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 07:14:04 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 07:05:35 2009 Subject: [GHC] #2924: createDirectory: permission denied Message-ID: <047.7f5e4787e0730bc3878fcff588107d39@localhost> #2924: createDirectory: permission denied ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/directory | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Windows | Architecture: x86 ----------------------------------+----------------------------------------- The following program results in an odd "permission denied" error from `createDirectory` on Windows. It is derived from the `createDirectoryIfMIssing001` test, but doesn't involve calling `createDirectoryIfMissing`, only `createDirectory`. There are two threads, each of which is repeatedly creating a directory and using `removeDirectoryRecursive` to remove it. Test program: {{{ import System.IO import System.Directory import Control.Monad import Control.Concurrent import Control.Exception import System.IO.Error testdir = "foo" main = do cleanup m <- newEmptyMVar forkIO $ do replicateM_ 1000 (do create; cleanup); putMVar m () forkIO $ do replicateM_ 1000 (do create; cleanup); putMVar m () replicateM_ 2 $ takeMVar m cleanup create = tryJust (guard . isAlreadyExistsError) $ createDirectory testdir cleanup = tryJust (guard . isDoesNotExistError) $ removeDirectoryRecursive testdir }}} The result is usually: {{{ test.exe: CreateDirectory: permission denied (Access is denied.) }}} It's not clear (to me at least) why we get this error. Running the program under !ProcMon shows that there is a `CreateFile` call that returns `DELETE PENDING`, but as far as I can tell this doesn't give rise to an `ERROR_DELETE_PENDING` return from `CreateDirectory`, because that would give a different error message. Perhaps somewhere in the bowels of the Win32 API a `DELETE_PENDING` is being turned into a permission denied, or something. This deserves investigation, because I think it might be related to other spurious "permission denied" errors we occasionally see on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 07:15:08 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 07:06:38 2009 Subject: [GHC] #2873: ghc-pkg list/dump --package-conf=missing returns successful error code In-Reply-To: <045.d3448bbf66f00ef8dc9dae0dc42ea1ff@localhost> References: <045.d3448bbf66f00ef8dc9dae0dc42ea1ff@localhost> Message-ID: <054.a3341e1d29643186e77fab6100ecd471@localhost> #2873: ghc-pkg list/dump --package-conf=missing returns successful error code ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Thu Jan 8 09:56:28 GMT 2009 Simon Marlow * Fix #2873: should fail if a package DB desn't exist We allowed non-existence before because the user DB is allowed to not exist, so now we have an explicit exception for that case. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 07:37:01 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 07:28:31 2009 Subject: [GHC] #2925: Linker mmap failure on FreeBSD/x86_64 Message-ID: <047.eaff3ca4aa8bcea6096eb0e3b35eda7f@localhost> #2925: Linker mmap failure on FreeBSD/x86_64 -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: FreeBSD | Architecture: x86_64 (amd64) -----------------------------+---------------------------------------------- We have some experimental fixes in the Linker to work around the lack of `MAP_32BIT` (see #2013, #2063 for background, also #2512), but still FreeBSD is presenting difficulties. See * [http://www.haskell.org/pipermail/glasgow-haskell- users/2008-December/thread.html] * [http://www.haskell.org/pipermail/glasgow-haskell- users/2009-January/016438.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 07:42:34 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 07:34:06 2009 Subject: [GHC] #2914: RecordWildCards doesn't work with associated datatypes inside class instances In-Reply-To: <045.003431a2c8a375b9d493daaeb2179785@localhost> References: <045.003431a2c8a375b9d493daaeb2179785@localhost> Message-ID: <054.cbefc48304afcf3338faf9c752455929@localhost> #2914: RecordWildCards doesn't work with associated datatypes inside class instances ---------------------------------------------+------------------------------ Reporter: ganesh | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rename/should_compiler/T2914 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by simonpj): * testcase: => rename/should_compiler/T2914 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Excellent point, thank you. Fixed by {{{ Thu Jan 8 12:41:18 GMT 2009 simonpj@microsoft.com * Fix Trac #2914: record wild cards and assoicated types M ./compiler/rename/RnSource.lhs -7 +11 }}} Please merge. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 10:41:24 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 10:32:55 2009 Subject: [GHC] #2926: Foreign exported function returns wrong type Message-ID: <044.765c94e2fb1a6e722be183eea512a2d3@localhost> #2926: Foreign exported function returns wrong type -----------------------------+---------------------------------------------- Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I call foo, foreign export ccall foo :: Int -> IO CInt, from C code like this: printf("%d\n", (int)foo((HsInt32)2500)); but when I remove the (int) cast, gcc complains (warnings, not errors) because it thinks that the thing that foo returns is a HsInt32, and not a C int. The type for foo clearly specifies it is a CInt. The bug is that GHC is probably not generating a CInt, but a HsInt32. {{{ {-# LANGUAGE ForeignFunctionInterface #-} -- name this file ExportHaskellToCStruct.hs module ExportHaskellToCStruct(foo) where import Foreign.C import Data.List foreign export ccall foo :: Int -> IO CInt foo = return . genericLength . f f :: Int -> [Int] f 0 = [] f n = n:(f (n-1)) }}} {{{ #include #include "/correctpathto/include/HsFFI.h" /* FIX PATH for your installation */ #define __GLASGOW_HASKELL__ #ifdef __GLASGOW_HASKELL__ #include "ExportHaskellToCStruct_stub.h" #endif #ifdef __GLASGOW_HASKELL__ extern void __stginit_ExportHaskellToCStruct(void); #endif int main(int argc, char *argv[]) { int i; hs_init(&argc, &argv); #ifdef __GLASGOW_HASKELL__ hs_add_root(__stginit_ExportHaskellToCStruct); #endif for (i = 0; i < 5; i++) { printf("%d\n", (int)foo((HsInt32)2500)); } hs_exit(); return 0; } }}} {{{ gcc --version gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 11:38:18 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 11:29:48 2009 Subject: [GHC] #2926: Foreign exported function returns wrong type In-Reply-To: <044.765c94e2fb1a6e722be183eea512a2d3@localhost> References: <044.765c94e2fb1a6e722be183eea512a2d3@localhost> Message-ID: <053.c064c3dcd0b7a26c72b8f194b1d9b89d@localhost> #2926: Foreign exported function returns wrong type ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: I can't reproduce the problem here - gcc compiles the file without complaint, even with `-Wall -Werror`, on both x86 and x86_64. I wouldn't expect this to go wrong, because `HsInt32` is the same type as `int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 11:48:58 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 11:40:28 2009 Subject: [GHC] #2926: Foreign exported function returns wrong type In-Reply-To: <044.765c94e2fb1a6e722be183eea512a2d3@localhost> References: <044.765c94e2fb1a6e722be183eea512a2d3@localhost> Message-ID: <053.3636c1286624b1a0526d7e1e07f0259c@localhost> #2926: Foreign exported function returns wrong type ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => low * milestone: => _|_ Comment: Oh, I see. In fact `HsInt32` happens to be `long` on x86, so gcc warns about its use with the `%d` format in printf, even though on this architecture `long` is the same size as `int`. gcc is complaining about a portability problem, but we know there isn't one. In almost every other way, `HsInt32` is interchangeable with `int`. We could make `HsInt32` the same as `int`, but then the exact same problem would crop up with `CLong`. Sigh. It's a pain to make GHC emit a real `int` here, because GHC doesn't know anything special about the `CInt` type, as far as GHC is concerned it's just a newtype of `Int32` (or whatever). I'm making this bug low prio, because there are easy workarounds and it's hard to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 12:44:37 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 12:36:07 2009 Subject: [GHC] #2558: re-throwing an asynchronous exception throws it synchronously In-Reply-To: <047.339350d6751eeb20e19b24c52175ed9b@localhost> References: <047.339350d6751eeb20e19b24c52175ed9b@localhost> Message-ID: <056.59ff1688348cb40be7374288b35527f1@localhost> #2558: re-throwing an asynchronous exception throws it synchronously ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | 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 int-e): Replying to [comment:9 Isaac]: > nitpick: what if throwAsync is called when in blocked mode? does it need to do `unblock (throwTo target e)` in order for the self-exception to arrive? (or maybe the RTS already side-steps this deadlock?) Currently, the exception gets delivered, even in blocked mode. There's actually a todo in {{{Exception.cmm}}} for that case: {{{ if (target == CurrentTSO) { SAVE_THREAD_STATE(); /* ToDo: what if the current thread is blocking exceptions? */ foreign "C" throwToSingleThreaded(MyCapability() "ptr", target "ptr", exception "ptr")[R1,R2]; }}} I'd say that the current behaviour is sensible: {{{throwTo}}} is a blocking operation. As soon as the thread blocks on itself, it can deliver its own exception. We may just as well skip the step of getting blocked. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 13:06:50 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 12:58:19 2009 Subject: [GHC] #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets Message-ID: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets -----------------------------+---------------------------------------------- Reporter: tphyahoo | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.10.1 | Severity: normal Keywords: ipv6 | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- There is an uncaught exception in the network library which is causing my HAppS demo website http://happstutorial.com to crash every couple of days. This has affected other people using HAppS as well, as described on postings to the HAppS users list. The bug, and workarounds, is described at http://code.google.com/p/happs/issues/detail?id=40 Initially reported patch at http://www.haskell.org/pipermail/libraries/2009-January/011103.html Patch is attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 13:41:15 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 13:32:44 2009 Subject: [GHC] #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets In-Reply-To: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> References: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> Message-ID: <056.d35cf3c9bb00066cd473c1fabcaeb246@localhost> #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets -------------------------------+-------------------------------------------- Reporter: tphyahoo | Owner: bos Type: bug | Status: assigned Priority: normal | Milestone: Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: ipv6 | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by bos): * status: new => assigned * owner: => bos Comment: The bug seems legitimate. Thanks for reporting it. The patch is a bit crufty, so I'll work something cleaner up. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 14:27:07 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 14:18:39 2009 Subject: [GHC] #2746: Documentation for Haskell 98 modules is empty In-Reply-To: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> References: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> Message-ID: <056.84954be5f646d7607ddc9d7351aa66d3@localhost> #2746: Documentation for Haskell 98 modules is empty ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by waern): Module exports now works again, with this patch which is in HEAD: {{{ Thu Jan 8 19:03:36 CET 2009 David Waern * Export modules also when coming from external packages }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 14:29:40 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 14:21:10 2009 Subject: [GHC] #2699: broken pipe errors are too noisy In-Reply-To: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> References: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> Message-ID: <053.4efae1ab95dd3ed25af3c00ebbc0c663@localhost> #2699: broken pipe errors are too noisy ---------------------------------+------------------------------------------ Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by int-e): Replying to [comment:6 simonmar]: > Perhaps we should only exit silenty if the EPIPE was received for `stdin` or `stdout`? One problem we had with the silent `SIGPIPE` was that it happened for closed sockets, which confused people regularly. Sounds reasonable to me. It's only stdout that matters - only writing to "broken" pipes results in EPIPE. Reading results in a normal EOF. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 15:43:09 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 15:34:41 2009 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.2110be4507272f9883f49c821f7be588@localhost> #2337: Data.Array documentation utterly broken ---------------------------------+------------------------------------------ Reporter: japple | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by waern): Re-exported names now appear in the documentation for Data.Array (#2746 fixed). However, there are no links to the original module GHC.Arr since it is hidden (in the Haddock sense of the word). So while waiting for Haddock to fully document re-exports from other packages, we could perhaps un-hide this module or export the declarations from another non-hidden module in base. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 8 17:55:46 2009 From: trac at galois.com (GHC) Date: Thu Jan 8 17:47:15 2009 Subject: [GHC] #2928: internal error: schedule: invalid what_next field Message-ID: <043.39f3b89944b613f8705736dd851197b1@localhost> #2928: internal error: schedule: invalid what_next field -------------------+-------------------------------------------------------- Reporter: gsan | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- Test.hs: {{{ import Control.Monad main = forever $ print $ sum [1 .. 100000] }}} {{{ $ ghc --make Test.hs && ./Test [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... 5000050000 5000050000 5000050000 5000050000 5000050000 5000050000 Test: internal error: schedule: invalid what_next field (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} This only happens when the program is compiled without optimization or -threaded. The number of iterations (~50) before the error changes slightly and seems not to be affected by -H RTS option. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 04:02:36 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 03:54:06 2009 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.9765c4f3c6d936cac3c5e7f19fc98c51@localhost> #2337: Data.Array documentation utterly broken ---------------------------------+------------------------------------------ Reporter: japple | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:21 waern]: > Re-exported names now appear in the documentation for Data.Array (#2746 fixed). However, there are no links to the original module GHC.Arr since it is hidden (in the Haddock sense of the word). So while waiting for Haddock to fully document re-exports from other packages, we could perhaps un-hide this module or export the declarations from another non-hidden module in base. `GHC.Arr` is not hidden in the GHC 6.10 branch, as a workaround for exactly this. Maybe we should un-hide it in the HEAD too, with a comment to explain why, to avoid future confusion. BTW David - thanks for all your work on fixing Haddock recently, it's much appreciated! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 05:39:55 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 05:31:32 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.76aef9d66c8452b08e72045a99a4fae5@localhost> #2917: alloca and allocaArray do not respect alignment -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Thanks for the patch. As it stands, this will waste memory when the required alignment is <= 8 bytes, since `allocaBytes` and `mallocBytes` both always return 8-byte aligned memory. Could you modify the patch to take that into account? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 07:50:45 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 07:42:13 2009 Subject: [GHC] #2928: internal error: schedule: invalid what_next field In-Reply-To: <043.39f3b89944b613f8705736dd851197b1@localhost> References: <043.39f3b89944b613f8705736dd851197b1@localhost> Message-ID: <052.609d7360def28c6117a1eeacd5e0ed1f@localhost> #2928: internal error: schedule: invalid what_next field -------------------------------+-------------------------------------------- Reporter: gsan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: minor | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Fixed in 6.10.2: see #2818 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 08:15:56 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 08:07:21 2009 Subject: [GHC] #2929: INFINITY used in .hc files without -std=c99 Message-ID: <045.9c2069ffa5b68c9fb1e9f0987d2d791e@localhost> #2929: INFINITY used in .hc files without -std=c99 --------------------+------------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: 1861 Os: Solaris | Architecture: sparc --------------------+------------------------------------------------------- The C macro `INFINITY` is apparently defined by the C99 standard. On Solaris they take a strict interpretation of this and only define it conditionally: {{{ #if defined(_STDC_C99) || _XOPEN_SOURCE - 0 >= 600 || defined(__C99FEATURES__) }}} ghc does not use `gcc -std=c99` but perhaps it should? This bug is triggered by test 1861 (See #1861). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 10:12:10 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 10:03:37 2009 Subject: [GHC] #2930: System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch Message-ID: <044.0a1fdac704adf497121070f9c08f89a0@localhost> #2930: System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch -------------------+-------------------------------------------------------- Reporter: wferi | Owner: Type: bug | Status: new Priority: normal | Component: libraries (old-time) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- `formatCalendarTime` references strftime(3), and `man strftime` says that `%s` is "the number of seconds since the Epoch, that is, since 1970-01-01 00:00:00 UTC." However, under GHC 6.8.2 it is restricted to the 00-59 range, as the following demonstrates. `epoch.hs` is the following: {{{ import System.Time main = putStrLn $ formatCalendarTime undefined "%Y-%m-%d %T (%s)" (toUTCTime $ TOD 62 0) }}} And now: {{{ $ runghc epoch.hs 1970-01-01 00:01:02 (02) $ date --utc -d @62 +"%Y-%m-%d %T (%s)" 1970-01-01 00:01:02 (62) }}} I think ''GNU date'' is right, ''System.Time'' is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 11:49:15 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 11:40:41 2009 Subject: [GHC] #2931: Template Haskell: Quoting single letter identifier leads to a parse error at end of input. Message-ID: <044.8efc30367993250a8b68353fa140f283@localhost> #2931: Template Haskell: Quoting single letter identifier leads to a parse error at end of input. -----------------------------+---------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- To reproduce the bug with ghci: {{{ Prelude> :set -XTemplateHaskell Prelude> let a = 1 Prelude> :t 'a :1:1: lexical error in string/character literal at character 'a' }}} As a module, the following source code works if the last line has no newline: {{{ {-# LANGUAGE TemplateHaskell #-} a = 1 b = 'a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 12:25:41 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 12:17:07 2009 Subject: [GHC] #2932: Control.Arrow.Quantum, new version which compiles with GHC 6.10 Message-ID: <057.91f30f9546a04a42c2984d4cca4c2160@localhost> #2932: Control.Arrow.Quantum, new version which compiles with GHC 6.10 -------------------------------+-------------------------------------------- Reporter: dave@daveboden.com | Owner: Type: task | Status: new Priority: normal | Component: libraries (other) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The enclosed file contains a version of Quantum.hs with minor changes as per the instructions here: http://www.haskell.org/haskellwiki/Upgrading_packages#Arrow_instances The file now compiles with GHC 6.10. This page shows the errors that version 0.0.4 is experiencing under 6.10: http://hackage.haskell.org/packages/archive/quantum- arrow/0.0.4/logs/failure/ghc-6.10 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 14:43:02 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 14:34:27 2009 Subject: [GHC] #2933: LDFLAGS ignored by build system Message-ID: <045.854117476da424db3736910ffba011f0@localhost> #2933: LDFLAGS ignored by build system --------------------+------------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Solaris | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- I have required libs installed in `/opt/csw/lib` which is not on the ordinary system linker path. This includes things like `libgmp` etc. That means that to link ghc I want to pass `-R/opt/csw/lib` so that at runtime I do not need to set `LD_LIBRARY_PATH`. The `./configure --help` mentions `LDFLAGS` however this is ignored. When building gcc the equivalent makes everything work out fine. It would be nice if this were supported. Note also that `--with-gmp-includes` and `--with-gmp-libraries` are only half helpful. They add -L and -I options during the build only. That lets ghc link stuff using gmp. There are still two problems however: * Running such programs does not work if the gmp lib dir is not on the standard runtime linker path (which is quite likely given that it was not on the standard compile-time linker path). * It does not cause the final built ghc to automatically use -L/path/to/gmp/lib. Again I think if it's using `-L/path/to/gmp/lib` it should also use `-R/path/to/gmp/lib` or it'll link but not run. Some people claim that -R is evil. If we think it is evil and we choose not to use it for `--with-gmp-includes` and `--with-gmp-libraries` then those two become less than useful and it becomes more important to support `LD_OPTIONS`/`LDFLAGS` properly so that distros like the Solaris CSW can use it. For example, see http://www.opencsw.org/standards/pkg-walkthrough which recommends: {{{ export LD_OPTIONS='-R/opt/csw/lib/$ISALIST -R/opt/csw/lib -L/opt/csw/lib' }}} Note: the workaround is to modify the driver script of the bootstrapping ghc and add `-optl-R/the/extra/lib` and then do the same for the script template that will get used by the stage1/2 inplace and final ghc, or to temporarily use LD_LIBRARY_PATH and modify the final ghc driver script during/after install. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 16:28:37 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 16:20:03 2009 Subject: [GHC] #2932: Control.Arrow.Quantum, new version which compiles with GHC 6.10 In-Reply-To: <057.91f30f9546a04a42c2984d4cca4c2160@localhost> References: <057.91f30f9546a04a42c2984d4cca4c2160@localhost> Message-ID: <066.5a1fd0fe4c74cd99a07dbcb44c3d912f@localhost> #2932: Control.Arrow.Quantum, new version which compiles with GHC 6.10 --------------------------------+------------------------------------------- Reporter: dave@daveboden.com | Owner: luqui Type: task | Status: assigned Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------+------------------------------------------- Changes (by luqui): * status: new => assigned * owner: => luqui -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 16:41:29 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 16:32:55 2009 Subject: [GHC] #2932: Control.Arrow.Quantum, new version which compiles with GHC 6.10 In-Reply-To: <057.91f30f9546a04a42c2984d4cca4c2160@localhost> References: <057.91f30f9546a04a42c2984d4cca4c2160@localhost> Message-ID: <066.593ffa6c56406cd223eb02c36a91bd24@localhost> #2932: Control.Arrow.Quantum, new version which compiles with GHC 6.10 --------------------------------+------------------------------------------- Reporter: dave@daveboden.com | Owner: luqui Type: task | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------+------------------------------------------- Changes (by luqui): * status: assigned => closed * resolution: => fixed Comment: Fixed, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 17:31:26 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 17:22:51 2009 Subject: [GHC] #2934: occasional apparent crashes in GC when memory consumption rises Message-ID: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> #2934: occasional apparent crashes in GC when memory consumption rises ------------------------------+--------------------------------------------- Reporter: anish | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: normal Keywords: garbage collector | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Hi, I have a program that seems to run into occasional garbage collection-related core dumps. The problem typically only occurs after the program has been running for a while and is consuming a large amount of memory (5 - 16GB). The large memory consumption is expected because the program analyzes very large traces from verilog simulation and needs to maintain IntMaps with hundreds of thousands of entries. Is this a bug that I should report?I am afraid that my employer will not allow me to share my source code. I do have a stack trace, below. This was obtained using ghc 6.10.1, RTS -N2 on an x86-64 RHEL 4 machine. Is there something I can do trace the problem or avoid it? Thanks. PS: This is my first Haskell program and one of the most complicated I ever wrote, in any language. Using Haskell has been (mostly :-)) a joy. (gdb) where #0 0x0000000000612f40 in slowIsHeapAlloced () #1 0x000000000060f868 in evacuate () #2 0x0000000000618d12 in scavenge_block () #3 0x0000000000617c8d in scavenge_loop () #4 0x0000000000610b25 in scavenge_until_all_done () #5 0x0000000000610d02 in gc_thread_entry () #6 0x000000000064859d in start_thread (arg=) at pthread_create.c:297 #7 0x000000000069e739 in clone () #8 0x0000000000000000 in ?? () -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 9 17:42:54 2009 From: trac at galois.com (GHC) Date: Fri Jan 9 17:34:20 2009 Subject: [GHC] #2935: "A lazy (~) pattern cannot bind existential type variables" happens for non-existential GADTs Message-ID: <045.215c443d95e2564f615189dbc3981975@localhost> #2935: "A lazy (~) pattern cannot bind existential type variables" happens for non-existential GADTs -----------------------------+---------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This program: {{{ {-# LANGUAGE GADTs #-} module Foo where data Foo a where Foo :: a -> Foo (a, Int) foo :: Foo (a, Int) -> a foo ~(Foo a) = a }}} causes this error: {{{ Foo.hs:8:4: A lazy (~) pattern cannot bind existential type variables `a' is a rigid type variable bound by the constructor `Foo' at Foo.hs:8:6 In the pattern: ~(Foo a) In the definition of `foo': foo ~(Foo a) = a }}} This doesn't seem like an existential, as there aren't any type variables in the arguments to Foo that aren't in the result type. If easy it would be nice if the restriction were relaxed to allow for this case, otherwise I think the error message should be improved. Tested with ghc 6.10.1.20081209 and ghc 6.11.20090107. -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Sat Jan 10 00:33:09 2009 From: conal at conal.net (Conal Elliott) Date: Sat Jan 10 00:24:33 2009 Subject: Build difficulties with HEAD Message-ID: I grabbed the snapshot ghc-6.11.20090109, with extra-libs. After "./configure", "make" aborts with "ghc-pkg: /home/conal/downloads/ghc-6.11.20090109/ghc/inplace-datadir/package.conf: openFile: does not exist (No such file or directory)", wile registering haddock-2.5.0 . Did I miss something? There is no inplace-datadir there. Is there a fix? I was also unable to build from the HEAD darcs repo. after "sh boot", and "./configure", "make" aborts with "installPackage: You need to re-run the 'configure' command. The version of Cabal being used has changed (was Cabal-1.6.0.1, now Cabal-1.7.0)." in build.stage.1. Ideas? - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20090109/4ed093eb/attachment.htm From trac at galois.com Sat Jan 10 00:36:31 2009 From: trac at galois.com (GHC) Date: Sat Jan 10 00:27:55 2009 Subject: [GHC] #2936: System.IO.Error needs to be imported unconditionally Message-ID: <044.99c35a4c8efbffdbebdc4f42d12f0d2d@localhost> #2936: System.IO.Error needs to be imported unconditionally -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The recent patch "Avoid using IOError internals" placed import of System.IO.Error in files Network/BSD.hsc and Network/Socket.hsc within a preprocessor conditional block, in the way that only GHC imports System.IO.Error. This causes errors when Hugs processes these files. Suggested: unconditionally import System.IO.Error in these modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 10 00:50:36 2009 From: trac at galois.com (GHC) Date: Sat Jan 10 00:42:01 2009 Subject: [GHC] #2937: source file that compiled fine fails to recompile after touching it (yes, another one) Message-ID: <047.dbb1a127d7dcdc429c0bd3cde852bbdb@localhost> #2937: source file that compiled fine fails to recompile after touching it (yes, another one) -----------------------------+---------------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I'm using the development snapshot `ghc-6.11.20090107` and ran into a bug very similar to #2888, but I think it is different because I could not reproduce that bug in my version. The setup is very similar: File `A.hs` contains {{{ {-# LANGUAGE TypeFamilies #-} module A where class Foo a where data Bar a :: * -> * }}} and file `B.hs` contains {{{ {-# LANGUAGE TypeFamilies #-} module B where import A instance Foo Int where data Bar Int x where Baz :: Bar Int String }}} Then: {{{ rwbarton@functor:/tmp/a$ ghc --make B [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) rwbarton@functor:/tmp/a$ touch B.hs rwbarton@functor:/tmp/a$ ghc --make B [2 of 2] Compiling B ( B.hs, B.o ) B.hs:8:2: Arguments that do not correspond to a class parameter must be variables Instead of a variable, found Int In the associated type instance for `Bar' In the instance declaration for `Foo Int' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ross at soi.city.ac.uk Sat Jan 10 06:47:15 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Sat Jan 10 06:38:40 2009 Subject: Build difficulties with HEAD In-Reply-To: References: Message-ID: <20090110114715.GA5787@soi.city.ac.uk> On Fri, Jan 09, 2009 at 09:33:09PM -0800, Conal Elliott wrote: > I was also unable to build from the HEAD darcs repo. after "sh boot", and "./ > configure", "make" aborts with "installPackage: You need to re-run the > 'configure' command. The version of Cabal being used has changed (was > Cabal-1.6.0.1, now Cabal-1.7.0)." in build.stage.1. I just had the same problem building the 6.10.1 source distribution on a system with GHC 6.8.2 and Cabal 1.7.0. This happens in ghc-prim. From trac at galois.com Sat Jan 10 08:23:49 2009 From: trac at galois.com (GHC) Date: Sat Jan 10 08:15:14 2009 Subject: [GHC] #2938: excessive use of stack space with longer source lists Message-ID: <041.198e2d5de285fbe401fe2b394a6ebb28@localhost> #2938: excessive use of stack space with longer source lists -------------------+-------------------------------------------------------- Reporter: rk | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: blocker Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- ghc does not handle long lists in a good way at the moment compiling the attached file take to much stack space ... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 10 09:01:08 2009 From: trac at galois.com (GHC) Date: Sat Jan 10 08:52:38 2009 Subject: [GHC] #2584: Pretty printing of types with HsDocTy goes wrong In-Reply-To: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> References: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> Message-ID: <060.435fe06d9211e06b4489a2188343424a@localhost> #2584: Pretty printing of types with HsDocTy goes wrong ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: waern Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by waern): * status: assigned => closed * resolution: => fixed Comment: I don't want remove the pretty printing of {{{HsDocTy}}} since it is used by the test suite, to test that parsing works correctly. So I've fixed the pretty printing so that the comments are handled as if they were postfix type operators. Your example now becomes: {{{ ([a] -> [b]) -> [a] -> [b] }}} This is the patch (in HEAD): {{{ Fri Jan 9 20:17:13 CET 2009 David Waern * Fix Trac #2584: Pretty printing of types with HsDocTy }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 10 11:23:33 2009 From: trac at galois.com (GHC) Date: Sat Jan 10 11:14:56 2009 Subject: [GHC] #2936: System.IO.Error needs to be imported unconditionally In-Reply-To: <044.99c35a4c8efbffdbebdc4f42d12f0d2d@localhost> References: <044.99c35a4c8efbffdbebdc4f42d12f0d2d@localhost> Message-ID: <053.7bbb4ef4eab083198361f95e616609d8@localhost> #2936: System.IO.Error needs to be imported unconditionally -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by golubovsky): This bug was submitted by golubovsky (was logged on as guest by accident). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 10 13:13:11 2009 From: trac at galois.com (GHC) Date: Sat Jan 10 13:04:35 2009 Subject: [GHC] #2739: GHC API crashes on template haskell splices In-Reply-To: <044.3bac7d34665c04ceca674c8a12436d56@localhost> References: <044.3bac7d34665c04ceca674c8a12436d56@localhost> Message-ID: <053.7e1fc80705d9fb6c8e4dde82f744d520@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: nominolo Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by waern): I tried to fix this issue in Haddock, by using {{{needsTemplateHaskell}}} from the GHC API, and checking this right after doing the {{{depanal}}}, and then setting the target to {{{HscC}}} before going ahead with typechecking. This works. However, since {{{HscC}}} is a bit heavy, I also tried {{{HscInterpreted}}}. But then another Haddock test fail, namely {{{TypeFamilies.hs}}}: {{{ {-# LANGUAGE TypeFamilies #-} module TypeFamilies where -- | Type family G type family G a :: * -- | A class with an associated type class A a where -- | An associated type data B a :: * -> * -- | A method f :: B a Int -- | Doc for family type family F a -- | Doc for G Int type instance G Int = Bool type instance G Float = Int instance A Int where data B Int x = Con x f = Con 3 g = Con 5 }}} The error message is: {{{ During interactive linking, GHCi couldn't find the following symbol: g This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs@haskell.org }}} Is this an orthogonal TypeFamilies bug I've stumbled upon? If {{{HscIntepreted}}} would work, I was thinking we could use it instead of {{{HscC}}} and eventually try to find some way to work around the problem exemplified by unboxed tuples (stuff for which {{{HscInterpreted}}} doesn't help). Or perhaps a more fine-grained check could be provided by the GHC API to check exactly which modules need to use which flag. In that case, using {{{HscC}}} may not be so bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 10 13:14:52 2009 From: trac at galois.com (GHC) Date: Sat Jan 10 13:06:19 2009 Subject: [GHC] #2739: GHC API crashes on template haskell splices In-Reply-To: <044.3bac7d34665c04ceca674c8a12436d56@localhost> References: <044.3bac7d34665c04ceca674c8a12436d56@localhost> Message-ID: <053.454cc1bdfac108ef1bf0328975c9f872@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: nominolo Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by waern): * cc: david.waern@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 10 15:11:35 2009 From: trac at galois.com (GHC) Date: Sat Jan 10 15:03:01 2009 Subject: [GHC] #2939: Example in library doco for Control.Exception.handle is no longer supported in GHC 6.10 Message-ID: <041.e04e0170350b212eed6fdb779e4b100d@localhost> #2939: Example in library doco for Control.Exception.handle is no longer supported in GHC 6.10 -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The library documentation for {{{Control.Exception}}} includes an example that does not compile in GHC 6.10: {{{ Prelude Control.Exception System> do handle (\e -> exitWith (ExitFailure 1)) $ undefined :1:3: Ambiguous type variable `e' in the constraint: `Exception e' arising from a use of `handle' at :1:3-41 Probable fix: add a type signature that fixes these type variable(s) Prelude Control.Exception System> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From igloo at earth.li Sun Jan 11 08:27:22 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 11 08:18:42 2009 Subject: Build difficulties with HEAD In-Reply-To: <20090110114715.GA5787@soi.city.ac.uk> References: <20090110114715.GA5787@soi.city.ac.uk> Message-ID: <20090111132722.GA26366@matrix.chaos.earth.li> On Sat, Jan 10, 2009 at 11:47:15AM +0000, Ross Paterson wrote: > On Fri, Jan 09, 2009 at 09:33:09PM -0800, Conal Elliott wrote: > > I was also unable to build from the HEAD darcs repo. after "sh boot", and "./ > > configure", "make" aborts with "installPackage: You need to re-run the > > 'configure' command. The version of Cabal being used has changed (was > > Cabal-1.6.0.1, now Cabal-1.7.0)." in build.stage.1. > > I just had the same problem building the 6.10.1 source distribution on > a system with GHC 6.8.2 and Cabal 1.7.0. This happens in ghc-prim. The ghc-prim problem was fixed by: [We need to tell cabal-bin which version of Cabal to use Ian Lynagh **20081203123208 Otherwise, if the bootstrapping compiler has a newer version, we get a mismatch between the version used to compile ghc-prim's Setup.hs and the version that installPackage uses. after 6.10.1 was released. Thanks Ian From igloo at earth.li Sun Jan 11 10:11:24 2009 From: igloo at earth.li (Ian Lynagh) Date: Sun Jan 11 10:02:45 2009 Subject: Build difficulties with HEAD In-Reply-To: References: Message-ID: <20090111151124.GA3773@matrix.chaos.earth.li> On Fri, Jan 09, 2009 at 09:33:09PM -0800, Conal Elliott wrote: > I grabbed the snapshot ghc-6.11.20090109, with extra-libs. After > "./configure", "make" aborts with "ghc-pkg: > /home/conal/downloads/ghc-6.11.20090109/ghc/inplace-datadir/package.conf: > openFile: does not exist (No such file or directory)", wile registering > haddock-2.5.0 . Did I miss something? There is no inplace-datadir there. > Is there a fix? I've just pushed a patch to fix this one: hunk ./Makefile 36 -INPLACE_PKG_CONF = $(FPTOOLS_TOP_ABS)/ghc/inplace-datadir/package.conf +INPLACE_PKG_CONF = $(INPLACE_DATA_DIR)/package.conf in utils/haddock. Thanks Ian From trac at galois.com Sun Jan 11 10:40:25 2009 From: trac at galois.com (GHC) Date: Sun Jan 11 10:31:50 2009 Subject: [GHC] #2873: ghc-pkg list/dump --package-conf=missing returns successful error code In-Reply-To: <045.d3448bbf66f00ef8dc9dae0dc42ea1ff@localhost> References: <045.d3448bbf66f00ef8dc9dae0dc42ea1ff@localhost> Message-ID: <054.81c33c2e93953b9d4dc83d13cd685261@localhost> #2873: ghc-pkg list/dump --package-conf=missing returns successful error code ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | 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: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 11 10:52:24 2009 From: trac at galois.com (GHC) Date: Sun Jan 11 10:43:45 2009 Subject: [GHC] #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked In-Reply-To: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> References: <044.ecfc5eca3f0107ce76b97002b8d185be@localhost> Message-ID: <053.a3b275975269db0aab2fcc41db79df5b@localhost> #2910: throwTo can block indefinitely when target thread finishes with exceptions blocked ---------------------------------+------------------------------------------ Reporter: int-e | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: All 7 merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 11 10:53:16 2009 From: trac at galois.com (GHC) Date: Sun Jan 11 10:44:39 2009 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.b754a727f29e359809cbcf38cdd03c89@localhost> #2002: problems with very large (list) literals ---------------------------------------------+------------------------------ Reporter: Isaac Dupree | Owner: simonmar Type: compile-time performance bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------+------------------------------ Comment (by igloo): Applied to HEAD and 6.10: {{{ Fri Dec 19 03:22:11 PST 2008 Simon Marlow * bump GHC's max stack size to 512M To accomodate compiling very long static lists (#2002) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 11 10:54:40 2009 From: trac at galois.com (GHC) Date: Sun Jan 11 10:45:59 2009 Subject: [GHC] #2925: Linker mmap failure on FreeBSD/x86_64 In-Reply-To: <047.eaff3ca4aa8bcea6096eb0e3b35eda7f@localhost> References: <047.eaff3ca4aa8bcea6096eb0e3b35eda7f@localhost> Message-ID: <056.4a7dcd47d8f3376419236bf739e2faca@localhost> #2925: Linker mmap failure on FreeBSD/x86_64 -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: FreeBSD Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by igloo): In HEAD and 6.10: {{{ Thu Jan 8 07:53:41 PST 2009 Simon Marlow * when calling mmap() with MAP_ANON, the fd argument should be -1 might fix #2925 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Sun Jan 11 12:42:22 2009 From: conal at conal.net (Conal Elliott) Date: Sun Jan 11 12:33:42 2009 Subject: Build difficulties with HEAD In-Reply-To: <20090111151124.GA3773@matrix.chaos.earth.li> References: <20090111151124.GA3773@matrix.chaos.earth.li> Message-ID: Thanks, Ian. That tweak helped. Now "make" succeeds, but "sudo make install" dies, as shown below. - Conal == make install -r; in /home/conal/downloads/ghc-6.11.20090109/libffi ------------------------------------------------------------------------ gcc -E -undef -traditional -P -DINSTALLING \ -DIMPORT_DIR='"/usr/local/lib/ghc-6.11.20090109/imports"' \ -DLIB_DIR='"/usr/local/lib/ghc-6.11.20090109"' \ -DINCLUDE_DIR='"/usr/local/lib/ghc-6.11.20090109/include"' \ -DDATA_DIR='"/usr/local/lib/ghc-6.11.20090109"' \ -DHTML_DIR='"/usr/local/lib/ghc-6.11.20090109/html/libraries/ffi"' \ -DHADDOCK_IFACE='"/usr/local/lib/ghc-6.11.20090109/html/libraries/ffi/ffi.haddock"' \ -I../includes \ -x c -I../includes -Iinclude -DPACKAGE=ffi -DVERSION= -DPKG_LIBDIR='"/usr/local/lib/ghc-6.11.20090109"' -DPKG_DATADIR='"/usr/local/lib/ghc-6.11.20090109"' package.conf.in \ | grep -v '^#pragma GCC' \ | sed -e 's/""//g' -e 's/:[ ]*,/: /g' \ | /home/conal/downloads/ghc-6.11.20090109/utils/ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg --global-conf /usr/local/lib/ghc-6.11.20090109/package.conf update - --force ghc-pkg: /usr/local/lib/ghc-6.11.20090109/package.conf: openFile: does not exist (No such file or directory) On Sun, Jan 11, 2009 at 7:11 AM, Ian Lynagh wrote: > On Fri, Jan 09, 2009 at 09:33:09PM -0800, Conal Elliott wrote: > > I grabbed the snapshot ghc-6.11.20090109, with extra-libs. After > > "./configure", "make" aborts with "ghc-pkg: > > /home/conal/downloads/ghc-6.11.20090109/ghc/inplace-datadir/package.conf: > > openFile: does not exist (No such file or directory)", wile registering > > haddock-2.5.0 . Did I miss something? There is no inplace-datadir > there. > > Is there a fix? > > I've just pushed a patch to fix this one: > > hunk ./Makefile 36 > -INPLACE_PKG_CONF = $(FPTOOLS_TOP_ABS)/ghc/inplace-datadir/package.conf > +INPLACE_PKG_CONF = $(INPLACE_DATA_DIR)/package.conf > > in utils/haddock. > > > Thanks > Ian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20090111/11e3e80d/attachment-0001.htm From trac at galois.com Mon Jan 12 03:43:45 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 03:35:02 2009 Subject: [GHC] #2935: "A lazy (~) pattern cannot bind existential type variables" happens for non-existential GADTs In-Reply-To: <045.215c443d95e2564f615189dbc3981975@localhost> References: <045.215c443d95e2564f615189dbc3981975@localhost> Message-ID: <054.fd4621e920235c52c90b4efbb6a60fd1@localhost> #2935: "A lazy (~) pattern cannot bind existential type variables" happens for non-existential GADTs ---------------------------------+------------------------------------------ Reporter: ganesh | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: The error message is not good, but it's right to reject this program. More precisely, it'd definitely be right to reject this program: {{{ bar :: a -> Foo a -> a bar x ~(Foo _) = fst x }}} Because I could call `bar 3 undefined`, and thereby crash. Now in this case (a) the data type has only one constructor, (b) the type signature for `foo` ensures that every call will match `Foo`'s constraints. So nothing would go wrong. But it's a very special case. And I don't know how to translate it into System F (or more precisely Fc). So it's not easy. So I propose to do nothing except perhaps make the error message mention GADTs too. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 05:40:05 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 05:31:24 2009 Subject: [GHC] #2933: LDFLAGS ignored by build system In-Reply-To: <045.854117476da424db3736910ffba011f0@localhost> References: <045.854117476da424db3736910ffba011f0@localhost> Message-ID: <054.d8507a1544c7b2e80d915ee6050991c8@localhost> #2933: LDFLAGS ignored by build system ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.10 branch Comment: I'm surprised if `--with-gmp-libraries` doesn't work - as far as I can see it should, because we add those directories to the `library-dirs` field of the RTS `package.conf`. Incedentally GMP should really have its own package, which would then be a good place to put these options, along with any -R options you also want to add. If we were to support `LDFLAGS`, where should they be added? We have the option of adding them when linking programs built with 1. the bootstrapping GHC (stage0) 2. stage1 3. stage2 4. the final installed GHC I'm not sure which of these we should be adding `LDFLAGS` to. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 05:41:45 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 05:33:03 2009 Subject: [GHC] #2934: occasional apparent crashes in GC when memory consumption rises In-Reply-To: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> References: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> Message-ID: <053.7e447df859af0167d7abc74f546aa3c0@localhost> #2934: occasional apparent crashes in GC when memory consumption rises ----------------------------------+----------------------------------------- Reporter: anish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: garbage collector | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * difficulty: => Unknown Old description: > Hi, > I have a program that seems to run into occasional garbage > collection-related core dumps. The problem typically only occurs after > the > program has been running for a while and is consuming a large amount of > memory (5 - 16GB). The large memory consumption is expected because the > program analyzes very large traces from verilog simulation and needs to > maintain IntMaps with hundreds of thousands of entries. > > Is this a bug that I should report?I am afraid that my employer will not > allow me to share my source code. I do have a stack trace, below. > This was obtained using ghc 6.10.1, RTS -N2 on an x86-64 RHEL 4 machine. > > Is there something I can do trace the problem or avoid it? > > Thanks. > PS: This is my first Haskell program and one of the most complicated I > ever wrote, in any language. Using Haskell has been (mostly :-)) a joy. > > (gdb) where > #0 0x0000000000612f40 in slowIsHeapAlloced () > > #1 0x000000000060f868 in evacuate () > > #2 0x0000000000618d12 in scavenge_block () > > #3 0x0000000000617c8d in scavenge_loop () > > #4 0x0000000000610b25 in scavenge_until_all_done () > > #5 0x0000000000610d02 in gc_thread_entry () > > #6 0x000000000064859d in start_thread (arg=) > at pthread_create.c:297 > > #7 0x000000000069e739 in clone () > > #8 0x0000000000000000 in ?? () New description: Hi, I have a program that seems to run into occasional garbage collection-related core dumps. The problem typically only occurs after the program has been running for a while and is consuming a large amount of memory (5 - 16GB). The large memory consumption is expected because the program analyzes very large traces from verilog simulation and needs to maintain !IntMaps with hundreds of thousands of entries. Is this a bug that I should report?I am afraid that my employer will not allow me to share my source code. I do have a stack trace, below. This was obtained using ghc 6.10.1, RTS -N2 on an x86-64 RHEL 4 machine. Is there something I can do trace the problem or avoid it? Thanks. PS: This is my first Haskell program and one of the most complicated I ever wrote, in any language. Using Haskell has been (mostly :-)) a joy. {{{ (gdb) where #0 0x0000000000612f40 in slowIsHeapAlloced () #1 0x000000000060f868 in evacuate () #2 0x0000000000618d12 in scavenge_block () #3 0x0000000000617c8d in scavenge_loop () #4 0x0000000000610b25 in scavenge_until_all_done () #5 0x0000000000610d02 in gc_thread_entry () #6 0x000000000064859d in start_thread (arg=) at pthread_create.c:297 #7 0x000000000069e739 in clone () #8 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 05:47:17 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 05:38:34 2009 Subject: [GHC] #2934: HEAP_ALLOCED() is not thread-safe In-Reply-To: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> References: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> Message-ID: <053.653ef1f5add81611606298436a1674b2@localhost> #2934: HEAP_ALLOCED() is not thread-safe ----------------------------------+----------------------------------------- Reporter: anish | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: garbage collector | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | ----------------------------------+----------------------------------------- Changes (by simonmar): * priority: normal => high * owner: => simonmar * summary: occasional apparent crashes in GC when memory consumption rises => HEAP_ALLOCED() is not thread-safe * architecture: Unknown/Multiple => x86_64 (amd64) * milestone: => 6.10.2 Comment: Thanks, I can see where the bug is from your stack trace! The workaround would be to use `+RTS -g0` to turn off the parallel GC. Please let us know if this fixes it for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 05:50:12 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 05:41:29 2009 Subject: [GHC] #2938: excessive use of stack space with longer source lists In-Reply-To: <041.198e2d5de285fbe401fe2b394a6ebb28@localhost> References: <041.198e2d5de285fbe401fe2b394a6ebb28@localhost> Message-ID: <050.6c0a7ead77d2418159e79145d10b8d08@localhost> #2938: excessive use of stack space with longer source lists -------------------------------+-------------------------------------------- Reporter: rk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: See #2002: we concluded that it was reasonable for GHC to use linear stack space when compiling deeply nested structures, and we have increased GHC's default maximum stack size. The workaround for now is to do this yourself with `+RTS -K512m`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 07:07:10 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 06:58:28 2009 Subject: [GHC] #2940: Do CSE after CorePrep Message-ID: <046.ba154de3cf0c400fb0723e1948282304@localhost> #2940: Do CSE after CorePrep ---------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ Common sub-expression analysis is deliberately conservative, but it's really ''too'' conservative: we are missing obvious opportunities. Consider {{{ {-# OPTIONS_GHC -XBangPatterns -XMagicHash #-} module Foo where import GHC.Base -- CorePrep evaluates (reverse xs) twice f xs = let !v1 = reverse (reverse xs) !v2 = filter id (reverse xs) in (v1, v2) -- Even CSE inside CorePrep would not get this right; -- the strict evaluation of (reverse xs) doesn't scope -- over the non-strict version g xs = reverse (reverse xs) ++ filter id (reverse xs) -- Duplicate evaluation of (x +# 1#) h :: Int# -> ( Int, Int ) h x = ( I# (x +# 1#), I# ((x +# 1#) *# 2#) ) }}} If you compile this you'll see that there are obvious missed CSE opportunities in `f`, `g` and `h`; but they only show up after `CorePrep`. I guess the right thing is to CSE after `CorePrep`, but then CSE would have to maintain the `CorePrep` invariants, which isn't trivial. Something to think about. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 07:24:19 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 07:15:37 2009 Subject: [GHC] #2833: internal error: throwTo: unrecognised why_blocked value In-Reply-To: <044.241eea212892e1f7fdf89a6a715bfb1f@localhost> References: <044.241eea212892e1f7fdf89a6a715bfb1f@localhost> Message-ID: <053.34db12f4b053291f737b97e7866990dc@localhost> #2833: internal error: throwTo: unrecognised why_blocked value ---------------------------------+------------------------------------------ Reporter: lilac | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high Comment: We should test whether this one has been fixed by the recent batch of `throwTo` fixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 07:27:15 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 07:18:38 2009 Subject: [GHC] #2913: OldException's catch etc should treat new Exception types as DynException's In-Reply-To: <044.32b88c5c6278c8a1dcec6524f5b05c54@localhost> References: <044.32b88c5c6278c8a1dcec6524f5b05c54@localhost> Message-ID: <053.fdd38f10dd48b4000c888a6379be8a36@localhost> #2913: OldException's catch etc should treat new Exception types as DynException's ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 08:39:05 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 08:30:40 2009 Subject: [GHC] #2912: GHCi bug: bus error when executing some gsl-random code In-Reply-To: <048.fd42a972a38728467b869822f9f56943@localhost> References: <048.fd42a972a38728467b869822f9f56943@localhost> Message-ID: <057.792578229c0982009da86f7cfd809621@localhost> #2912: GHCi bug: bus error when executing some gsl-random code -------------------------------+-------------------------------------------- Reporter: fdeweerdt | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * cc: patperry@stanford.edu (added) * resolution: => duplicate Comment: This is another instance of #781. The problem is caused by this reference in the `gsl-random` package: {{{ foreign import ccall unsafe "gsl/gsl_rng.h &gsl_rng_mt19937" p_gsl_rng_mt19937 :: Ptr (Ptr ()) }}} The GHCi linker on x86_64 can't handle references to static data in shared libraries, because we only have a 32-bit field and we need a 64-bit offset. One way to workaround it is to use `-fPIC` when compiling gsl-random (I tested this, it works). However, `-fPIC` is still quite experimental, so I hesitate to recommend this as a fix. Another way to do it would be to have a C function that returns the address of `gsl_rng_mt19937`, and compile this with `-fPIC`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 08:47:43 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 08:39:01 2009 Subject: [GHC] #2933: LDFLAGS ignored by build system In-Reply-To: <045.854117476da424db3736910ffba011f0@localhost> References: <045.854117476da424db3736910ffba011f0@localhost> Message-ID: <054.1226b78d0eb6a6060cfc8543c6949bdf@localhost> #2933: LDFLAGS ignored by build system ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:1 simonmar]: > I'm surprised if `--with-gmp-libraries` doesn't work - as far as I can see it should, because we add those directories to the `library-dirs` field of the RTS `package.conf`. Incedentally GMP should really have its own package, which would then be a good place to put these options, along with any -R options you also want to add. Yes. It adds it to `include-dirs` and `library-dirs`. Those translate into -I and -L, but for shared libs we also need -R if the dir is not on the standard runtime linker path. Similarly, `-R` is not used when linking stage2 so stage2 still does not work without `LD_LIBRARY_PATH`. As for `LDFLAGS`, I'd advocate improving `--with-gmp-libraries` first. It is probably enough in most cases. So the suggestion is that `--with-gmp-libraries` should add `ld-options: -R${GMP_LIB_DIR}` as well. And it should be used for linking stage2. I know some people think -R/-rpath is evil, though I'm never sure quite why. If a library is not on the standard lib path then surely we need both -L and -R? So the `LDFLAGS` is just a backup plan in case people come and tell us that -R is evil and should not be used by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 17:16:20 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 17:07:35 2009 Subject: [GHC] #2941: HsBase.h includes termios.h which prevents us including curses.h on solaris Message-ID: <045.171341cbaca14bf35d3ced6b736251d9@localhost> #2941: HsBase.h includes termios.h which prevents us including curses.h on solaris --------------------+------------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: normal Keywords: | Testcase: Os: Solaris | Architecture: sparc --------------------+------------------------------------------------------- Every .hc file includes `HsBase.h` from the base package. Unfortunately on Solaris something that this header defines or includes makes `curses.h` invalid. {{{ #include "HsBase.h" #include #include int main () { return 0; } }}} Gives us: {{{ GHCDIR=/opt/ghc/lib/ghc-6.8.3 gcc -c foo.c -I${GHCDIR}/include -I${GHCDIR}/lib/base-3.0.2.0/include In file included from foo.c:5: /usr/include/term.h:1060: error: field ?Ottyb? has incomplete type /usr/include/term.h:1061: error: field ?Nttyb? has incomplete type }}} whereas if we omit `#include "HsBase.h"` from `foo.c` then it compiles fine. If we narrow this down a bit we find that it's because we cannot compile this file: {{{ #include #include #include int main () { return 0; } }}} That is, if we include termios.h before curses.h The reason is that `curses.h` has: {{{ #ifndef VINTR #include #endif /* VINTR */ typedef struct termio SGTTY; typedef struct termios SGTTYS; }}} and `termios.h` defines VINTR, however it is `termio.h` that defines `struct termio`. Hence the `SGTTY` typedef is undefined, or incomplete in C parlance. If we instead do: {{{ #include #include #include int main () { return 0; } }}} Then it compiles fine. Indeed if we edit the .hc file that originally tickled this bug to put the includes in the other order then it all works fine. The nearest reports elsewhere on the net that I've found are: http://www.nabble.com/Can't-build-pl-5.6.63-td20943886.html http://www.nabble.com/minor-build-issue-with-5.6.61-on- Solaris-10-6-06-td19698590.html This bug prevents the terminfo package from building on Solaris. In turn that blocks haskeline and ghci-haskeline. So it's a blocker for ghc adopting haskeline on Solaris at the moment. That blocker may go away if we get -fasm working and drop support for -fvia-C. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 18:29:08 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 18:20:24 2009 Subject: [GHC] #2942: witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case-sensitive file system Message-ID: <050.2d88d56a844b36381f7e789271b08f2d@localhost> #2942: witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case- sensitive file system ------------------------+--------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: powerpc ------------------------+--------------------------------------------------- The {{{make install}}} of the binary distribution http://www.haskell.org/ghc/dist/6.10.1/witten/ghc-6.10.1-powerpc-apple- darwin.tar.bz2 (see http://www.haskell.org/ghc/download_ghc_6_10_1.html) for PPC Max OS X 10.5 (Leopard) fails on a case-sensitive file system with this error message: {{{ make -C haddock install /Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1-powerpc- apple-darwin/ghc-6.10.1/dist/utils/installPackage/install- inplace/bin/installPackage install \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1-powerpc- apple-darwin/ghc-6.10.1/dist/utils/ghc-pkg/dist-install/build/ghc-pkg/ghc- pkg' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1/package.conf' \ '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/bin' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1' '' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1' \ '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/share/doc/ghc' '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/share/doc/ghc' '' \ --distpref dist-install \ --enable-shell-wrappers Installing library in /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/lib/ghc-6.10.1/haddock-2.3.0 Installing executable(s) in /Volumes/tn18_HD_1/Users/thorkilnaur/tn/install/ghc-6.10.1/bin installPackage: dist-install/build/haddock/haddock: copyFile: does not exist (No such file or directory) make[2]: *** [install] Error 1 make[1]: *** [install.haddock] Error 2 make: *** [install] Error 2 }}} As a work-around, I created the following symbolic link: {{{ thorkil-naurs-mac- mini:/Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1 -powerpc-apple-darwin/ghc-6.10.1/dist thorkilnaur$ ls -l utils/haddock /dist-install/build/haddock lrwxr-xr-x 1 thorkilnaur 501 7 Jan 12 23:31 utils/haddock/dist- install/build/haddock -> Haddock thorkil-naurs-mac- mini:/Volumes/tn18_HD_1/Users/thorkilnaur/tn/GHC/witten_ghc-6.10.1 -powerpc-apple-darwin/ghc-6.10.1/dist thorkilnaur$ }}} With this link, the {{{make install}}} succeeds. Thanks and best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 18:39:12 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 18:30:28 2009 Subject: [GHC] #2943: Socket related IO cannot be be interrupted on Windows Message-ID: <049.2b628271ed720c2ee352804d23fc025a@localhost> #2943: Socket related IO cannot be be interrupted on Windows -----------------------+---------------------------------------------------- Reporter: h.holtmann | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 -----------------------+---------------------------------------------------- While playing with socket communication, I noticed that socket IO cannot be interrupted or killed. The attached program simply hangs, irregardless whether is was complied using the -threaded flag or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 12 20:40:06 2009 From: trac at galois.com (GHC) Date: Mon Jan 12 20:31:22 2009 Subject: [GHC] #2941: HsBase.h includes termios.h which prevents us including curses.h on solaris In-Reply-To: <045.171341cbaca14bf35d3ced6b736251d9@localhost> References: <045.171341cbaca14bf35d3ced6b736251d9@localhost> Message-ID: <054.89ff50812d87131e78cc3d8a59ff9d0f@localhost> #2941: HsBase.h includes termios.h which prevents us including curses.h on solaris ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: sparc ----------------------------+----------------------------------------------- Changes (by judahj): * cc: judahj (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 05:27:00 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 05:18:14 2009 Subject: [GHC] #2941: HsBase.h includes termios.h which prevents us including curses.h on solaris In-Reply-To: <045.171341cbaca14bf35d3ced6b736251d9@localhost> References: <045.171341cbaca14bf35d3ced6b736251d9@localhost> Message-ID: <054.90fa4738cb1ef4ea023f379100b24cba@localhost> #2941: HsBase.h includes termios.h which prevents us including curses.h on solaris -------------------------------+-------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Fixed in 6.10.1, because we don't `#include` anything in `.hc` files. I ''knew'' it was a good idea to do that! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 06:49:48 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 06:41:10 2009 Subject: [GHC] #1897: Ambiguous types and rejected type signatures In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.83f3bdbfb31905ce334bcfd25066c861@localhost> #1897: Ambiguous types and rejected type signatures ----------------------------------------+----------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by simonpj): * cc: andres@cs.uu.nl (added) Comment: Here is yet another example, this time from Andres Loeh: {{{ {-# LANGUAGE TypeFamilies, EmptyDataDecls, RankNTypes #-} module Foo where data X (a :: *) type family Y (a :: *) -- This works (datatype). i1 :: (forall a. X a) -> X Bool i1 x = x -- This works too (type family and extra arg). i2 :: (forall a. a -> Y a) -> Y Bool i2 x = x True -- This doesn't work (type family). i3 :: (forall a. Y a) -> Y Bool i3 x = x }}} The definition `i3` is currently rejected, because we can't determine that `Y alpha ~ Y Bool`, where `alpha` is an otherwise unconstrained unification variable, that comes from instantiating the occurrence of `x`. Choosing `alpha := Bool` will solve this, and in this case any solution will do; it's a bit like resolving an ambiguous type variable. It's tricky in general, though. Suppose we had two constraints `(X alpha ~ X Bool)` and `(Y alpha ~ Y Char)`. Now we can't solve it so easily! Worse, suppose we had an instance declaration {{{ type instance Y Bool = Char }}} Should we still resolve `alpha := Bool`? Would the answer change if there was a ''second'' instance? {{{ type instance Y Int = Char }}} Arguably, searching for all possible solutions is not terribly good. It's not at all obvious what the Right Thing is. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 08:20:16 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 08:11:31 2009 Subject: [GHC] #2944: Mutually recursive equality constraints Message-ID: <060.51642b5b9daf07feaf7d5262417a8b88@localhost> #2944: Mutually recursive equality constraints ----------------------------------+----------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------------------+----------------------------------------- Given this piece of code: {{{ {-# LANGUAGE TypeFamilies #-} class C a where type T a :: * f1 :: T a ~ () => a f1 = f2 f2 :: T a ~ () => a f2 = f1 }}} GHC complains: {{{ Couldn't match expected type `T a ~ ()' against inferred type `T a1 ~ ()' When matching the contexts of the signatures for f1 :: forall a. (T a ~ ()) => a f2 :: forall a. (T a ~ ()) => a The signature contexts in a mutually recursive group should all be identical When generalising the type(s) for f1, f2 }}} Is this a bug? Enabling RelaxedPolyRec fixes the problem. Should TypeFamilies?just like GADTs?imply RelaxedPolyRec? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 09:36:58 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 09:28:12 2009 Subject: [GHC] #2945: trace history should not be context/resume specific but global Message-ID: <046.a1eed06b62edc58c92c0397ae05d5c35@localhost> #2945: trace history should not be context/resume specific but global -----------------------------+---------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Currently trace history is stored in "Resume" context. I'm not aware of any good reason for this but it results in problems during debugging. The point is that one cannot extend currently active trace history using ":trace " while stopped at breakpoint. The nested trace history is extended instead. But the nested history is freed when the ":trace " command finishes so there is no access to the trace data. This makes it hard to investigate why the output of the trace command looks the way it was printed: it is not possible to investigate values of variables which contributed to the value. A discussion about the reasons for global trace history is here: http://www.haskell.org/pipermail/glasgow-haskell- users/2009-January/016436.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 09:53:03 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 09:44:19 2009 Subject: [GHC] #2945: trace history should not be context/resume specific but global In-Reply-To: <046.a1eed06b62edc58c92c0397ae05d5c35@localhost> References: <046.a1eed06b62edc58c92c0397ae05d5c35@localhost> Message-ID: <055.f65ddfca3640def6af9fa520cd2c10d4@localhost> #2945: trace history should not be context/resume specific but global ------------------------------+--------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by phercek): By global, I meant the same place where top level bindings are (so the trace history would get removed when modules are reloaded). May be the resume context should keep the mumber of hisotry records contributed from the current resume context, so that they can be purged when ":abandon" is issued. I do not have strong opinion about this since I almost never use ":abandon". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 09:59:56 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 09:51:10 2009 Subject: [GHC] #2739: GHC API crashes on template haskell splices In-Reply-To: <044.3bac7d34665c04ceca674c8a12436d56@localhost> References: <044.3bac7d34665c04ceca674c8a12436d56@localhost> Message-ID: <053.861b0e801b562f46f795f1bab35cdcfa@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: nominolo Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Maybe you have stumbled on a type-families bug. But I can't tell unless I can reproduce it. Can you make it happen with GHCi? If not, how can I reproduce it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 10:36:30 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 10:27:44 2009 Subject: [GHC] #2937: source file that compiled fine fails to recompile after touching it (yes, another one) In-Reply-To: <047.dbb1a127d7dcdc429c0bd3cde852bbdb@localhost> References: <047.dbb1a127d7dcdc429c0bd3cde852bbdb@localhost> Message-ID: <056.fbf4a3799746f783444ba7d8d7b09b9b@localhost> #2937: source file that compiled fine fails to recompile after touching it (yes, another one) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => igloo * difficulty: => Unknown * type: bug => merge Comment: Excellent bug thank you. Fixed by {{{ Tue Jan 13 15:32:17 GMT 2009 simonpj@microsoft.com * Fix Trac #2937: deserialising assoicated type definitions }}} Please merge to branch. And Ian: could you make a test for this? It's not totally straightforward because it really requires the touch (or `-fforce-recomp`) in the middle. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 11:12:01 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 11:03:14 2009 Subject: [GHC] #2946: tracing should be controled by a global flag (it should not be resume context specific) Message-ID: <046.683eb7b4d5d0c38dcae8da9a304188ed@localhost> #2946: tracing should be controled by a global flag (it should not be resume context specific) -----------------------------+---------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: minor Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Instead of ":trace" and ":trace " command there should be one command ":set trace on/off" and a new command ":debug ". ":set trace" would control a global flag indicating whether tracing should be active or not. If tracing is active then:[[BR]] * ":continue" would behave like current ":trace",[[BR]] * forcing a value using ":force " woudl work like current ":trace " but ignoring breakpoitns,[[BR]] * ":debug " would work like current ":trace ",[[BR]] * and ":main ..." would start Main.main with tracing on from the very beginning.[[BR]] If tracing is not active then ":continue", ":force", ":main" would behave like they do now and ":debug " would be the same as current "". Reasoning: I believe people use tracing to get access to variables which are not free in the selected scope but which contributed to values in the selected scope. So if they want variable availability they want tracing on all the time if they care about speed they want tracing off all the time. With this change request accepted they do not need to remember which command to use to continue or to print a forced value. When an is an argument to a ghci command and tracing is on then trace hisotry is extended, if tracing is off then trace history is not extended, if is typed on the ghci command line directly then tracing is never extended. This change is not that important for manual ussage but it helps to simplify custom defined ghci comamnds/scripts (which e.g. will not need to take care whether to use ":continue" or ":trace" based on a global flag). This would also allow to start tracing from the very beggining of ":main" instead of setting a break at Main.main with a script set to ":trace" and then running ":main ...". Related discussion is here: http://www.haskell.org/pipermail/glasgow- haskell-users/2009-January/016436.html I do not know about other usage patterns for which the current state of tracing UI is better. If you do know then vote against this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 12:05:12 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 11:56:29 2009 Subject: [GHC] #2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669 In-Reply-To: <053.ce70667c924b83874db7013d3e3aa9b8@localhost> References: <053.ce70667c924b83874db7013d3e3aa9b8@localhost> Message-ID: <062.5397f5b6d63ff0275c75ec479558c0da@localhost> #2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669 --------------------------------------------------+------------------------- Reporter: batterseapower | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: simplCore/should_compile/simpl014 | Os: MacOS X Architecture: Unknown/Multiple | --------------------------------------------------+------------------------- Changes (by simonpj): * owner: => igloo Comment: I believe this is fixed by {{{ Tue Jan 13 16:49:53 GMT 2009 simonpj@microsoft.com * Rewrite CorePrep and improve eta expansion }}} Do not merge to the 6.10 branch (at least not yet); it's a bit radical. Ian: can you check you agree this is now ok, and close. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 12:13:17 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 12:04:29 2009 Subject: [GHC] #2935: "A lazy (~) pattern cannot bind existential type variables" happens for non-existential GADTs In-Reply-To: <045.215c443d95e2564f615189dbc3981975@localhost> References: <045.215c443d95e2564f615189dbc3981975@localhost> Message-ID: <054.9e500032754e2faaee3b19d2eb21b7c4@localhost> #2935: "A lazy (~) pattern cannot bind existential type variables" happens for non-existential GADTs ---------------------------------+------------------------------------------ Reporter: ganesh | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Changed error message {{{ Tue Jan 13 16:40:20 GMT 2009 simonpj@microsoft.com * Improve error messages slightly }}} The change is this {{{ hunk ./compiler/typecheck/TcPat.lhs 981 - text "I can't handle pattern bindings for existentially- quantified constructors.", + text "I can't handle pattern bindings for existential or GADT data constructors.", hunk ./compiler/typecheck/TcPat.lhs 1033 - hang (ptext (sLit "A lazy (~) pattern cannot bind existential type variables")) + hang (ptext (sLit "A lazy (~) pattern cannot match existential or GADT data constructors")) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 12:14:31 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 12:05:44 2009 Subject: [GHC] #2931: Template Haskell: Quoting single letter identifier leads to a parse error at end of input. In-Reply-To: <044.8efc30367993250a8b68353fa140f283@localhost> References: <044.8efc30367993250a8b68353fa140f283@localhost> Message-ID: <053.ccd3fee3bce6fe3bf20b8df2f6bb6cc0@localhost> #2931: Template Haskell: Quoting single letter identifier leads to a parse error at end of input. ----------------------------------+----------------------------------------- Reporter: int-e | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: th/T2931 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonpj): * testcase: => th/T2931 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Good point. Fixed by {{{ Tue Jan 13 17:09:48 GMT 2009 simonpj@microsoft.com * Fix Trac #2931 }}} Please merge to stable branch. Test added. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 12:16:24 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 12:07:37 2009 Subject: [GHC] #2944: Mutually recursive equality constraints In-Reply-To: <060.51642b5b9daf07feaf7d5262417a8b88@localhost> References: <060.51642b5b9daf07feaf7d5262417a8b88@localhost> Message-ID: <069.126014776da82a645e5bfdbe69a7d217@localhost> #2944: Mutually recursive equality constraints ----------------------------------------+----------------------------------- Reporter: MartijnVanSteenbergen | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by simonpj): * owner: => igloo * difficulty: => Unknown * type: bug => merge Comment: I agree: {{{ Tue Jan 13 16:27:16 GMT 2009 simonpj@microsoft.com * Make -XTypeFamilies imply -XRelaxedPolyRec (Trac #2944) }}} It's moot whether we should merge this, but on balance, yes. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 12:20:10 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 12:11:24 2009 Subject: [GHC] #2944: Mutually recursive equality constraints In-Reply-To: <060.51642b5b9daf07feaf7d5262417a8b88@localhost> References: <060.51642b5b9daf07feaf7d5262417a8b88@localhost> Message-ID: <069.e4ea175ba2f92141bb0b5898f326ecb9@localhost> #2944: Mutually recursive equality constraints ---------------------------------------------------+------------------------ Reporter: MartijnVanSteenbergen | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: indexed-types/should_compile/T2944 | Os: MacOS X Architecture: x86 | ---------------------------------------------------+------------------------ Changes (by simonpj): * testcase: => indexed-types/should_compile/T2944 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 12:31:40 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 12:22:56 2009 Subject: [GHC] #2552: SCC annotation behavior differs between toplevel and non-toplevel In-Reply-To: <044.15a1341c91a98c8a8d7587f72c101e1e@localhost> References: <044.15a1341c91a98c8a8d7587f72c101e1e@localhost> Message-ID: <053.f3ba3ac02e5cded507635122a23a80cd@localhost> #2552: SCC annotation behavior differs between toplevel and non-toplevel ------------------------------+--------------------------------------------- Reporter: Rauli | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: scc profiling | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------------+--------------------------------------------- Changes (by BenMoseley): * cc: ben@moseley.name (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 16:46:24 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 16:37:38 2009 Subject: [GHC] #2947: infix precedence of backtick functions defined in ghci is not reported by :info Message-ID: <048.ac55607c7d8b9643c6c08e90e9bdf49b@localhost> #2947: infix precedence of backtick functions defined in ghci is not reported by :info -----------------------------+---------------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- excerpt from ghci: {{{ Prelude> let infixr 9 `f` ; f = (+) let infixr 9 `f` ; f = (+) Prelude> 5 * 3 `f` 4 35 Prelude> :info f f :: Integer -> Integer -> Integer -- Defined at :1:19 Prelude> :info `f` f :: Integer -> Integer -> Integer -- Defined at :1:19 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 16:48:35 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 16:39:48 2009 Subject: [GHC] #2947: infix precedence of backtick functions defined in ghci is not reported by :info In-Reply-To: <048.ac55607c7d8b9643c6c08e90e9bdf49b@localhost> References: <048.ac55607c7d8b9643c6c08e90e9bdf49b@localhost> Message-ID: <057.ed77272561438a65b5b4e564a36e7d39@localhost> #2947: infix precedence of backtick functions defined in ghci is not reported by :info ------------------------------+--------------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by EyalLotem): In fact, the bug is more severe, the infix declaration in ghci is not used at all: {{{ Prelude> let infixr 0 `f` ; f = (*) let infixr 0 `f` ; f = (*) Prelude> 5 `f` 3 + 4 19 Prelude> :info `f` f :: Integer -> Integer -> Integer -- Defined at :1:19 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 16:48:46 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 16:40:00 2009 Subject: [GHC] #2947: infix precedence of backtick functions defined in ghci is not reported by :info In-Reply-To: <048.ac55607c7d8b9643c6c08e90e9bdf49b@localhost> References: <048.ac55607c7d8b9643c6c08e90e9bdf49b@localhost> Message-ID: <057.eac3127a91d524152e47191aea6eeb39@localhost> #2947: infix precedence of backtick functions defined in ghci is not reported by :info ------------------------------+--------------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by EyalLotem): * severity: minor => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 22:09:41 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 22:00:57 2009 Subject: [GHC] #2948: the type of System.Posix.Process.executeFile is not general enough Message-ID: <041.840bb1e0b75e4a904018a7c8da87800f@localhost> #2948: the type of System.Posix.Process.executeFile is not general enough -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: libraries/unix Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Because {{{System.Posix.Process.executeFile}}} does not return, its return type should be {{{IO a}}}, not {{{IO ()}}}. This change would make it possible to use {{{System.Posix.Process.executeFile}}} in a context that expects {{{IO Int}}} or {{{IO ProcessStatus}}}, for example. I may well have assigned this bug to the wrong library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 13 22:47:04 2009 From: trac at galois.com (GHC) Date: Tue Jan 13 22:38:21 2009 Subject: [GHC] #2919: ghc panic while compiling Crypto In-Reply-To: <045.deee858f6ff0d3e43625e8810078b454@localhost> References: <045.deee858f6ff0d3e43625e8810078b454@localhost> Message-ID: <054.3d41aabb33e6a2043326c1f4b66f41e1@localhost> #2919: ghc panic while compiling Crypto ----------------------+----------------------------------------------------- Reporter: wchogg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by StephenBlackheath): Workaround: cabal install Crypto --disable-optimization -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 05:14:14 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 05:05:24 2009 Subject: [GHC] #2822: Arity expansion not working right In-Reply-To: <046.15a4d7e08c29ef55ed5596df1606d405@localhost> References: <046.15a4d7e08c29ef55ed5596df1606d405@localhost> Message-ID: <055.483e0a05ccf1ce1eef2a0882a8bd9bab@localhost> #2822: Arity expansion not working right -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by batterseapower): This is happening because at the time we compile GHC.Handle, the Prelude module has not yet been compiled. This means that Prelude.catch is pesimistically assumed to have an arity of 0, so openFile can only have an arity as large as the number of leading lambdas it has - i.e. 2. I don't think there is a clean solution for this without whole-program compilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 05:32:49 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 05:24:01 2009 Subject: [GHC] #2947: infix precedence of backtick functions defined in ghci is not reported by :info In-Reply-To: <048.ac55607c7d8b9643c6c08e90e9bdf49b@localhost> References: <048.ac55607c7d8b9643c6c08e90e9bdf49b@localhost> Message-ID: <057.73188d6f14e2dc3c208849cd7fd2ef48@localhost> #2947: infix precedence of backtick functions defined in ghci is not reported by :info ---------------------------------+------------------------------------------ Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Good point. Based on a quick look at the code, it looks as if we simply ignore fixities in `let`-bound definitions in GHCi. Fixing this would not be too hard; it's just a question of adding a `FixityEnv` to `InteractiveContext` and plumbing it around. Volunteers? Let's also see if anyone else cares. (An alternative would be simply to warn that the fixity is ignored.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 07:47:47 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 07:39:00 2009 Subject: [GHC] #2948: the type of System.Posix.Process.executeFile is not general enough In-Reply-To: <041.840bb1e0b75e4a904018a7c8da87800f@localhost> References: <041.840bb1e0b75e4a904018a7c8da87800f@localhost> Message-ID: <050.f9aa55bd41b0281a35c29d1dba15ffd6@localhost> #2948: the type of System.Posix.Process.executeFile is not general enough ---------------------------------+------------------------------------------ Reporter: nr | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown Comment: easy one - I'll do this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 07:53:19 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 07:44:29 2009 Subject: [GHC] #2699: broken pipe errors are too noisy In-Reply-To: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> References: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> Message-ID: <053.38881f79fe18dce0be144a5ec1fdbcb4@localhost> #2699: broken pipe errors are too noisy ---------------------------------+------------------------------------------ Reporter: int-e | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 09:46:17 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 09:37:28 2009 Subject: [GHC] #2699: broken pipe errors are too noisy In-Reply-To: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> References: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> Message-ID: <053.c2bc999a6d3fe3947c36f0bfebb3824d@localhost> #2699: broken pipe errors are too noisy ---------------------------------+------------------------------------------ Reporter: int-e | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Fixed: {{{ Wed Jan 14 13:46:12 GMT 2009 Simon Marlow * #2699: exit silently for EPIPE on stdout }}} I presume we aren't merging this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 09:46:23 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 09:37:34 2009 Subject: [GHC] #2949: ghci suddenly won't start Message-ID: <044.adacb64fb251885d51e98c63b57e2c71@localhost> #2949: ghci suddenly won't start -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I've no clue what is wrong or what I have changed, but when I tried to fire up GHCI today, I got the below message. I've tried removing .ghci and .ghc to no avail. The compiler is the default shipped by Ubuntu. % ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help ghc-6.8.2: internal error: evacuate(static): strange closure type 0 (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort ghci -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 09:57:06 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 09:48:23 2009 Subject: [GHC] #2584: Pretty printing of types with HsDocTy goes wrong In-Reply-To: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> References: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> Message-ID: <060.0c947c01f59e70aec9c28ff28b477cde@localhost> #2584: Pretty printing of types with HsDocTy goes wrong ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: waern Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Merged to 6.10 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 09:58:14 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 09:49:26 2009 Subject: [GHC] #2948: the type of System.Posix.Process.executeFile is not general enough In-Reply-To: <041.840bb1e0b75e4a904018a7c8da87800f@localhost> References: <041.840bb1e0b75e4a904018a7c8da87800f@localhost> Message-ID: <050.d9c41a345f65ae0232849bab8469fadf@localhost> #2948: the type of System.Posix.Process.executeFile is not general enough ---------------------------------+------------------------------------------ Reporter: nr | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/unix | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 10:00:06 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 09:51:19 2009 Subject: [GHC] #2262: Build failure of HEAD from 2008-05-04 on OS X 10.4.11 In-Reply-To: <047.3f0e3b88d9818643a9caa58f0fc62bf1@localhost> References: <047.3f0e3b88d9818643a9caa58f0fc62bf1@localhost> Message-ID: <056.2dc40e2c64cc2cb55f83c82eeae5663a@localhost> #2262: Build failure of HEAD from 2008-05-04 on OS X 10.4.11 -------------------------+-------------------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by igloo): {{{ Tue Dec 16 04:47:06 PST 2008 Simon Marlow * Workaround for #2262, from Barney Stratford }}} applied to HEAD and 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 10:36:20 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 10:27:32 2009 Subject: [GHC] #2950: show breakpoint numbers of breakpoints which were ignored during :force Message-ID: <046.8fc12104263edfe21a0114a0a4deb184@localhost> #2950: show breakpoint numbers of breakpoints which were ignored during :force -----------------------------+---------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: trivial Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Extend message "*** Ignoring breakpoint" (which is printed during :force evalutation) so that it contains basic information about the breakpoint ignored. Add at least the breakpoint number. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 10:41:55 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 10:33:05 2009 Subject: [GHC] #2822: Arity expansion not working right In-Reply-To: <046.15a4d7e08c29ef55ed5596df1606d405@localhost> References: <046.15a4d7e08c29ef55ed5596df1606d405@localhost> Message-ID: <055.a0373134c50330a4341dcc7052d85054@localhost> #2822: Arity expansion not working right -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: igloo Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * owner: => igloo Comment: Ian: Max is right. Prelude does export `catch`, and there is a `Prelude .hs-boot`. But maybe that isn't needed any more, with the new exception story. After all, `catch` now seems to be defined in `Control.Exception.Base`, and all `Prelude` does is say {{{ catch = Control.Exception.Base.catch }}} which is not clever, because it pulls the defn of `catch` '''higher''' in the module graph. * Can you see if this particular module loop can be broken? * More generally, do you have a description of the intended module structure of `base`? Something like this: [wiki:ModuleDependencies]. It's very hard to unravel by just looking at the code. I'll assign this to you to look at! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 11:31:34 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 11:22:45 2009 Subject: [GHC] #2445: better error message needed for missing package files In-Reply-To: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> References: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> Message-ID: <054.eca19e7ea297317317f7886181ca9bf1@localhost> #2445: better error message needed for missing package files ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * milestone: 6.10 branch => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 12:22:15 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 12:13:29 2009 Subject: [GHC] #2316: Add Applicative instances for all MTL Monads In-Reply-To: <047.6c77bc0cfe5b195806e995b0a81d8474@localhost> References: <047.6c77bc0cfe5b195806e995b0a81d8474@localhost> Message-ID: <056.d64254ce4e543be02ec4246ac967518d@localhost> #2316: Add Applicative instances for all MTL Monads ----------------------------------+----------------------------------------- Reporter: sjanssen | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by basvandijk): * cc: v.dijk.bas@gmail.com (added) Comment: Here are the relevant discussions at libraries@haskell.org: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9140 http://thread.gmane.org/gmane.comp.lang.haskell.libraries/10432 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 14 17:03:50 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 17:01:22 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform Message-ID: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> #2951: Add support for amd64-solaris2 platform ----------------------------+----------------------------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Solaris | Architecture: x86_64 (amd64) ----------------------------+----------------------------------------------- Hello, it would be nice if GHC build correctly detects if it's running on amd64 platform or plain old i386 platform. The problem is that current config.guess returns in both cases i386-pc-solaris2.* string. Certainly there is a possibility to use `isainfo -n` to test for application supported instruction set, see: {{{ karel@silence:~/vcs/ghc$ ./config.guess i386-pc-solaris2.11 karel@silence:~/vcs/ghc$ isainfo -n amd64 karel@silence:~/vcs/ghc$ }}} I'm just not sure if hacking configure.ac's code below {{{ i[[3456]]86-*-solaris2*) HostPlatform=i386-unknown-solaris2 # hack again TargetPlatform=i386-unknown-solaris2 BuildPlatform=i386-unknown-solaris2 HostPlatform_CPP='i386_unknown_solaris2' HostArch_CPP='i386' HostVendor_CPP='unknown' HostOS_CPP='solaris2' ;; }}} and changing HostArch_CPP from 'i386' to 'x86_64' would be enough for the change. -- Ticket URL: GHC The Glasgow Haskell Compiler From igloo at earth.li Wed Jan 14 17:29:35 2009 From: igloo at earth.li (Ian Lynagh) Date: Wed Jan 14 17:20:45 2009 Subject: Build difficulties with HEAD In-Reply-To: References: <20090111151124.GA3773@matrix.chaos.earth.li> Message-ID: <20090114222935.GA20479@matrix.chaos.earth.li> On Sun, Jan 11, 2009 at 09:42:22AM -0800, Conal Elliott wrote: > Thanks, Ian. That tweak helped. Now "make" succeeds, but "sudo make > install" dies, as shown below. - Conal > > /home/conal/downloads/ghc-6.11.20090109/utils/ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg > --global-conf /usr/local/lib/ghc-6.11.20090109/package.conf update - --force > ghc-pkg: /usr/local/lib/ghc-6.11.20090109/package.conf: openFile: does not > exist (No such file or directory) Now fixed. Thanks Ian From trac at galois.com Wed Jan 14 23:22:04 2009 From: trac at galois.com (GHC) Date: Wed Jan 14 23:13:13 2009 Subject: [GHC] #2934: HEAP_ALLOCED() is not thread-safe In-Reply-To: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> References: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> Message-ID: <053.253a361d4a2ff0fd5dd57f68aaa357d9@localhost> #2934: HEAP_ALLOCED() is not thread-safe ----------------------------------+----------------------------------------- Reporter: anish | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: garbage collector | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | ----------------------------------+----------------------------------------- Comment (by anish): I am thrilled that the stack trace helped. I missed the emails generated by your comments, I will just try the workaround. I assume you meant `+RTS -g1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 01:18:49 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 01:10:00 2009 Subject: [GHC] #1632: Test.HUnit documentation In-Reply-To: <044.8fcf7017003a72ffad0b6da6c98b6015@localhost> References: <044.8fcf7017003a72ffad0b6da6c98b6015@localhost> Message-ID: <053.49a158115923672e9ab483097ea6db20@localhost> #1632: Test.HUnit documentation ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: proposal | Status: reopened Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by RichardG): * status: closed => reopened * version: 6.6.1 => 6.10.1 * resolution: fixed => Comment: Reopenening ticket; documentation didn't make it into library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 04:33:50 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 04:24:59 2009 Subject: [GHC] #2822: Arity expansion not working right In-Reply-To: <046.15a4d7e08c29ef55ed5596df1606d405@localhost> References: <046.15a4d7e08c29ef55ed5596df1606d405@localhost> Message-ID: <055.be93fbb8eef7edf13cd5e5798812414e@localhost> #2822: Arity expansion not working right -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: igloo Type: run-time performance bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ * Move some catch definitions around to avoid an import loop As suggested by simonpj in trac #2822. M ./Prelude.hs -27 +1 R ./Prelude.hs-boot M ./System/IO/Error.hs -2 +27 }}} Thanks, Ian. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 04:34:12 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 04:25:25 2009 Subject: [GHC] #1632: Test.HUnit documentation In-Reply-To: <044.8fcf7017003a72ffad0b6da6c98b6015@localhost> References: <044.8fcf7017003a72ffad0b6da6c98b6015@localhost> Message-ID: <053.54d79fcb52e0b0550b45e74d1bdfa2b4@localhost> #1632: Test.HUnit documentation ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by RichardG): * status: reopened => closed * resolution: => fixed Comment: `FIX-1632-Test.HUnit-documentation.patch` adds documentation to the `Test.HUnit` library. In addition to API documentation, it includes a quick overview of how to use the library (the original patch was rejected because it did not have this). The version was also bumped from 1.2.0.3 to 1.2.0.4. It has been tested with GHC 6.10.1 on Mac OS X 10.5 (Intel), Ubuntu Linux 8.10, and Windows Vista. There is a small issue with it: `runghc Setup.hs test` does not work on Windows; the test files need to be invoked manually. Another bug will be opened to deal with this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 06:40:46 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 06:31:56 2009 Subject: [GHC] #2699: broken pipe errors are too noisy In-Reply-To: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> References: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> Message-ID: <053.52576c7d1164a62bbb3800822fc25503@localhost> #2699: broken pipe errors are too noisy ---------------------------------+------------------------------------------ Reporter: int-e | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by int-e): Replying to [comment:9 simonmar]: > I presume we aren't merging this? That's fine with me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 07:25:53 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 07:17:01 2009 Subject: [GHC] #2445: better error message needed for missing package files In-Reply-To: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> References: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> Message-ID: <054.7e4d31cd4678607d4db2533d850e8d42@localhost> #2445: better error message needed for missing package files ---------------------------------+------------------------------------------ Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 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 Thu Jan 15 07:37:19 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 07:28:28 2009 Subject: [GHC] #2699: broken pipe errors are too noisy In-Reply-To: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> References: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> Message-ID: <053.f2836003959233860902ad9ae6d4589d@localhost> #2699: broken pipe errors are too noisy ---------------------------------+------------------------------------------ Reporter: int-e | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 09:11:05 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 09:02:19 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.8011aef7f8cee84aa804f4ed23b9dd41@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): Although it looks, from the source, like the IO part of `Data.Typeable` should be able to be split off from the `Typeable` classes etc, this is sadly not the case. Right down at the bottom of the module hierarchy we have {{{ error s = throw (ErrorCall s) }}} which needs `ErrorCall` to have a `Typeable` instance. Although in the source this is just `deriving Typeable`, the generated code calls `mkTyCon`, which calls `mkTyConKey`, which does IO (hidden by `unsafePerformIO`). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 11:11:55 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 11:03:03 2009 Subject: [GHC] #2445: better error message needed for missing package files In-Reply-To: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> References: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> Message-ID: <054.002692fe51c00ede76876179ed1ddf50@localhost> #2445: better error message needed for missing package files ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Done: {{{ Thu Jan 15 04:25:24 PST 2009 Simon Marlow * More useful error message when a package .hi file cannot be found: Thu Jan 15 04:21:43 PST 2009 Simon Marlow * soup-up "ghc-pkg check" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 11:17:21 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 11:08:27 2009 Subject: [GHC] #2934: HEAP_ALLOCED() is not thread-safe In-Reply-To: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> References: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> Message-ID: <053.f9ad65d990da8ee59dbeba97df4846da@localhost> #2934: HEAP_ALLOCED() is not thread-safe ----------------------------------+----------------------------------------- Reporter: anish | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: garbage collector | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | ----------------------------------+----------------------------------------- Comment (by anish): I confirm that using `+RTS -g1` avoids the crash. Thanks for looking into this. I will look forward to 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 11:51:03 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 11:42:11 2009 Subject: [GHC] #2644: type of IntMap.intersection[WithKey] is incorrect In-Reply-To: <048.cdf8c7c801b2eb701f7311923129020e@localhost> References: <048.cdf8c7c801b2eb701f7311923129020e@localhost> Message-ID: <057.7d4489170446562d7e72d218017a5b94@localhost> #2644: type of IntMap.intersection[WithKey] is incorrect ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: containers | 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 Thu Jan 15 11:55:34 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 11:46:41 2009 Subject: [GHC] #2643: Optimized IntMap / IntSet construction from sorted input In-Reply-To: <048.5a067deefc3b5a1c5d97037f58a7321f@localhost> References: <048.5a067deefc3b5a1c5d97037f58a7321f@localhost> Message-ID: <057.460bb35a58c4915627d0d7826baaae52@localhost> #2643: Optimized IntMap / IntSet construction from sorted input ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: containers | 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 Thu Jan 15 11:57:01 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 11:48:07 2009 Subject: [GHC] #2645: fix type, performance of IntMap(Set).findMin(Max) In-Reply-To: <048.8a9f13834a53ec09c2896007b23bea4f@localhost> References: <048.8a9f13834a53ec09c2896007b23bea4f@localhost> Message-ID: <057.ae52b586d2f940af33452a97b90c7a1c@localhost> #2645: fix type, performance of IntMap(Set).findMin(Max) ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: containers | 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 Thu Jan 15 18:22:34 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 18:13:43 2009 Subject: [GHC] #2739: GHC API crashes on template haskell splices In-Reply-To: <044.3bac7d34665c04ceca674c8a12436d56@localhost> References: <044.3bac7d34665c04ceca674c8a12436d56@localhost> Message-ID: <053.cf4644590d9718f97ae2066851c418a4@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: nominolo Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by waern): Replying to [comment:6 simonpj]: > Maybe you have stumbled on a type-families bug. But I can't tell unless I can reproduce it. Can you make it happen with GHCi? If not, how can I reproduce it? > > Simon I tried to reproduce it by loading the (above) TypeFamilies module in GHCi, but that didn't do it. I'll see if I can come up with a test case using the GHC API later. Regarding the original problem, I discovered that it is still present when using the 6.10.2 branch of GHC. I think the reason may be the lack of this patch: {{{ Fri Nov 28 17:44:12 CET 2008 Thomas Schilling * Let 'loadModule' generate proper code depending on the 'hscTarget'. With this change it should be possible to perform something similar to 'load' by traversing the module graph in dependency order and calling '{parse,typecheck,load}Module' on each. Of course, if you want smart recompilation checking you should still use 'load'. }}} Thomas has agreed to try to back-port this fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 18:30:09 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 18:21:15 2009 Subject: [GHC] #2952: ghci fails to start from start menu on windows 7 Message-ID: <044.ff62699b4016eeac0215e90934c5496e@localhost> #2952: ghci fails to start from start menu on windows 7 --------------------+------------------------------------------------------- Reporter: larsv | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- In Windows 7 (6.1.7000) when starting ghci from the start menu, using Run or running a .hs file, the following message appears in a message box: {{{ --------------------------- ghc.exe - Application Error --------------------------- The application failed to initialize properly (0xc0000142). Click OK to terminate the application. --------------------------- OK --------------------------- }}} Launching ghci from a cmd prompt works as intended. Both 6.10.1 and 6.11.20090107 fails in the same manner. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 18:40:44 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 18:31:50 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable Message-ID: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> #2953: deriving Functor, Foldable, Traversable -----------------------------+---------------------------------------------- Reporter: twanvl | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It is possible to derive instance of Functor, Foldable and Traversable, as outlined in [http://www.mail-archive.com/haskell- prime@haskell.org/msg02116.html]. I would request that support for this be added to GHC, also in the hopes that these derivings can become part of the standard in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 15 18:41:30 2009 From: trac at galois.com (GHC) Date: Thu Jan 15 18:32:47 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.6b99ea93a1be03f9ebb75ec4ee05d71e@localhost> #2953: deriving Functor, Foldable, Traversable ------------------------------+--------------------------------------------- Reporter: twanvl | Owner: twanvl Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by twanvl): * owner: => twanvl -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 00:58:53 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 00:49:59 2009 Subject: [GHC] #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix Message-ID: <044.33b296bee16ac04eb53e73148864ea5b@localhost> #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The documentation says {{{ [...] On Unix systems, terminateProcess sends the process the SIGKILL signal. [...]}}} but in cbits/runProcess.c we have {{{ int terminateProcess (ProcHandle handle) { return (kill(handle, SIGTERM) == 0); } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 01:53:43 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 01:44:49 2009 Subject: [GHC] #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix In-Reply-To: <044.33b296bee16ac04eb53e73148864ea5b@localhost> References: <044.33b296bee16ac04eb53e73148864ea5b@localhost> Message-ID: <053.2a7537c30d4697f98555c38bd87a9d01@localhost> #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by guest): I realized it might not be clear, but if the wrong side here is the documentation i think we need a "killProcess" which uses SIGKILL. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 04:35:17 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 04:26:27 2009 Subject: [GHC] #2949: ghci suddenly won't start In-Reply-To: <044.adacb64fb251885d51e98c63b57e2c71@localhost> References: <044.adacb64fb251885d51e98c63b57e2c71@localhost> Message-ID: <053.be0c0991c61a08940032ca1c07e3af95@localhost> #2949: ghci suddenly won't start ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: Is it possible that one of the files on your system has become corrupted somehow? Can you try re-installing the ghc package and see if that fixes it? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 04:37:59 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 04:29:11 2009 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.98da22d2e464375c6faedcb3df9b6c43@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD, Xen | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by wolverian): * keywords: OpenBSD => OpenBSD, Xen Comment: I'd like to test this under Xen, but I don't know how to get a working GHC in the first place there. The daily builds seem to be extremely broken at the moment, failing at not finding package.conf. Any hints? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 04:53:38 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 04:51:06 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.09b4d18f654e5605cb104ca693f60d70@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 05:01:05 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 04:52:13 2009 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.eae049f116315eba7c188ef9b73b904b@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD, Xen | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonmar): The builds are working, but the testsuite is rather broken right now. You should be able to build GHC enough to test it, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 05:21:21 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 05:12:26 2009 Subject: [GHC] #2955: Data in $HOME/.ghc is not validated leading to obscure error messages when using ghc Message-ID: <044.401ab1611cc60ca7c435d4d1011de397@localhost> #2955: Data in $HOME/.ghc is not validated leading to obscure error messages when using ghc -------------------+-------------------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- I installed cabal-install-0.6.0 from source, used ghc for a couple of days and then deleted the $HOME/.cabal directory. A couple of days later a whole bunch of stuff was failing to compile with ghc. With a bit of help from the #haskell IRC channel, I tracked this down to the file $HOME/.ghc/i386-linux-6.8.2/package.conf which pointed to the recently deleted $HOME/.cabal directory. The fix would be to validate all data in $HOME/.ghc and if needed provide a decent error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 06:41:14 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 06:32:19 2009 Subject: [GHC] #2956: Template Haskell: cannot splice sections Message-ID: <047.28aa1e0700e775ee72d74177d9f3a1d6@localhost> #2956: Template Haskell: cannot splice sections -----------------------------+---------------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- {{{ {-# LANGUAGE TemplateHaskell #-} works = 1 + 1 worksTH = $( [| 1 + 1 |] ) breaks = (1+) 1 breaksTH = $( [| (1+) 1 |] ) }}} Trying to load the above gives: {{{ arst.hs:7:14: A section must be enclosed in parentheses thus: (1 `GHC.Num.+`) }}} The line it's complaining about is `breaksTH`'s definition. Marking as minor because it's easy to work around by simply not using sections. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 07:22:42 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 07:13:51 2009 Subject: [GHC] #2955: Data in $HOME/.ghc is not validated leading to obscure error messages when using ghc In-Reply-To: <044.401ab1611cc60ca7c435d4d1011de397@localhost> References: <044.401ab1611cc60ca7c435d4d1011de397@localhost> Message-ID: <053.aab8573e80b57af4f182291a4c50d845@localhost> #2955: Data in $HOME/.ghc is not validated leading to obscure error messages when using ghc ----------------------+----------------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Fortunately this has just been fixed. #2445 In future you would get an error message like: {{{ Could not find module `System.Process': There are files missing in the process-1.0.1.1 package. Try running 'ghc-pkg check'. }}} And if you ran `ghc-pkg check` it would report something like: [Note these are just examples and do not match up to the same problem] {{{ $ ghc-pkg check There are problems in package syb-0.1.0.0: dependency foo-4.0.0.0 doesn't exist There are problems in package process-1.0.1.1: file System/Process.hi is missing The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. syb-0.1.0.0 process-1.0.1.1 base-3.0.3.0 Cabal-1.7.0 haskell98-1.0.1.0 haddock-2.4.2 ghc-6.11 }}} Of course in your case, where you deleted all the package files without unregistering any of them, then the list of errors reported by `ghc-pkg check` would be a good deal longer. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 07:29:48 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 07:20:54 2009 Subject: [GHC] #2952: ghci fails to start from start menu on windows 7 In-Reply-To: <044.ff62699b4016eeac0215e90934c5496e@localhost> References: <044.ff62699b4016eeac0215e90934c5496e@localhost> Message-ID: <053.bf67e15a64a2ee1c1df39d456e17c34f@localhost> #2952: ghci fails to start from start menu on windows 7 ---------------------+------------------------------------------------------ Reporter: larsv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------+------------------------------------------------------ Comment (by duncan): Since Windows 7 is in beta it seems appropriate to report the bug to Microsoft. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 10:16:27 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 10:13:53 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.89b60c863eda93b672d8c92e53dd2c10@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by simonmar): * milestone: => 6.12 branch Comment: I updated `config.guess`, so the platform will now be recognised. There's still a lot to do to support this platform, though. {{{ Fri Jan 16 09:53:11 GMT 2009 Simon Marlow * Update config.guess, config.sub and install.sh from automake-1.10.2 In particular, config.guess should now know about x86_64-pc-solaris2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 10:47:28 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 10:38:50 2009 Subject: [GHC] #1548: printf bugs In-Reply-To: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> References: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> Message-ID: <060.8ffae3c81e3503cfb91809ac775e38a5@localhost> #1548: printf bugs ---------------------------------+------------------------------------------ Reporter: l.mai@web.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch 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 => Comment: unassigning myself. Lennart - is this a bug, or can we close it? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 10:54:00 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 10:45:05 2009 Subject: [GHC] #2131: concprog001(threaded2) occasional failures. In-Reply-To: <047.345a9b027d64df32bf7e2ae1b9475eb0@localhost> References: <047.345a9b027d64df32bf7e2ae1b9475eb0@localhost> Message-ID: <056.586a4942325e8c3ffcbe216dc5537913@localhost> #2131: concprog001(threaded2) occasional failures. ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Rocket Science Testcase: concprog001 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: We've had no more concprog002 failures since the recent round of throwTo fixes (#2910), so I'm optimistically assuming this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 11:00:05 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 10:57:29 2009 Subject: [GHC] #2957: GHC head build fails on non-GNU system assuming `patch' command is GNU patch Message-ID: <046.69b0f585273150506f0caa1d5b147736@localhost> #2957: GHC head build fails on non-GNU system assuming `patch' command is GNU patch --------------------+------------------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Solaris | Architecture: x86_64 (amd64) --------------------+------------------------------------------------------- Hello, GHC head build fails on non-GNU system using `patch' command in libffi/Makefile while assuming this is GNU patch at the same time. This is at least my assumption since Solaris' patch complains about wrong format, while GNU patch runs happily. Obvious fix to this issue is attached. Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 11:18:10 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 11:09:14 2009 Subject: [GHC] #2958: ghc-pkg describe is lying Message-ID: <044.023b948739e8319ec2c8f330e0539713@localhost> #2958: ghc-pkg describe is lying -------------------+-------------------------------------------------------- Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- If I do 'ghc-pkg describe attoparsec' the last line will say the following: haddock-html: /usr/local/share/doc/attoparsec-0.5.1/html But that directory doesn't actually exist! The only thing that's in the attoparsec-0.5.1 directory is a LICENSE file. I realize that this might depend on that ghc-pkg was given faulty information in the first place but I'm reporting it here anyway. The package was installed using cabal install version 0.6.1 with version 1.6.0.1 of the Cabal library. BTW. I wasn't sure what component to assign this but to. There doesn't seem to be a natural component for errors in ghc-pkg. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 11:12:54 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 11:10:25 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.b31d805fd7c577d85593ffdd927c10a6@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by maeder): will I get a problem when I want to create a 32bit binary-dist on our 64bit machine? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 11:41:57 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 11:39:26 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.bb70b1fb361e0031eed80f8a31d73bb2@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by kgardas): BTW: with the patch provided by Simon, current GHC head is completely broken on amd64/solaris: karel@silence:~/vcs/ghc$ ./configure checking for GHC version date... sed: Missing newline at end of file standard input. inferred 6.11.20090116 checking build system type... x86_64-pc-solaris2.11 checking host system type... x86_64-pc-solaris2.11 checking target system type... x86_64-pc-solaris2.11 Unrecognised platform: x86_64-pc-solaris2.11 karel@silence:~/vcs/ghc$ the fix is obvious, hack configure.ac to make x86_64-pc-solaris equal to i386-pc-solaris. If nobody steps in, I'll provide such change shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 11:59:21 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 11:56:45 2009 Subject: [GHC] #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) Message-ID: <046.4436609d3a414ddff94df71de1efe346@localhost> #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) -----------------------------+---------------------------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Hello, it would really be nice to see LambdaVM[1] merged in. I'm afraid that with GHC quickly evolving we might end with LambdaVM drifting away to the nearly unmergeable state. It would be a pity definitely, since IMHO there is a lot of work presented in this Haskel->JVM implementation. Thanks for considering it! Karel [1]: http://www.cs.rit.edu/~bja8464/lambdavm/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 13:53:48 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 13:44:51 2009 Subject: [GHC] #2810: Debugger: change context to the module containing the current breakpoint In-Reply-To: <047.b89e274abc5219595c46be09d48a0b6b@localhost> References: <047.b89e274abc5219595c46be09d48a0b6b@localhost> Message-ID: <056.a4b208bc0d835a692bb20a2839635563@localhost> #2810: Debugger: change context to the module containing the current breakpoint ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by phercek): * cc: phercek@gmail.com (added) Comment: I was asked by mnislaih to create separate ticket for what looks exactly like this. If you did not mean something special then this is the same as the earlier created ticket #2803 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 14:11:55 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 14:03:11 2009 Subject: [GHC] #2960: Add instance Data.Traversable for Data.IntMap Message-ID: <047.ad713d40a6f1b4b691c2eb21a7e2047b@localhost> #2960: Add instance Data.Traversable for Data.IntMap -----------------------------+---------------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.10.1 | Severity: major Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- `Data.IntMap` doesn't have a `Data.Traversable.Traversable` instance like `Data.Map`. This seems to be simply an oversight. Attached is a patch rectifying this, which uses [http://www.haskell.org/pipermail/haskell- cafe/2008-September/047187.html Ross Paterson's instance]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 14:43:52 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 14:34:57 2009 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.765a7c73ccad0489cb9265ef935c3e33@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * status: reopened => new * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 14:46:24 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 14:37:27 2009 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> Message-ID: <050.61caf257df8164833b22a19e35c5d824@localhost> #2721: Newtype deriving doesn't work with type families -------------------------------------------+-------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2721 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 14:51:44 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 14:42:47 2009 Subject: [GHC] #1377: GHCi debugger tasks In-Reply-To: <047.b3e158073b17fc81d3d320da105cad09@localhost> References: <047.b3e158073b17fc81d3d320da105cad09@localhost> Message-ID: <056.97289dab0d51eefa094dafd303eb6761@localhost> #1377: GHCi debugger tasks ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by phercek): * cc: phercek@gmail.com (added) Comment: Some ideas: * ''Some kind of step over or next...''[[BR]] Isn't :steplocal or :stepmodule it? Looks like already done. * ''We can disable a breakpoint with...''[[BR]] A breakpoint which has a code attached to it should not print anything not printed by the attached code. Well, except the command prompt printed if the attached code does not issue :continue. This would be handy. I asked for it also in my comment to #2737. If this is not done then custom implementation of features like conditional breakpoint or breakpoint setup solely to monitor value changes (an alternative to printf debugging) spit out a lot of garbage. The garbage can be suppressed but that suppresses also the legitimate program output. If you implement this then implementing flag for disabling breakpoints (a point later on) is not needed. * ''if a :force results in a breakpoint...''[[BR]] :force hitting a breakpoint should either print more information about the breakpoint or it should not print anything at all. The current situation is the worst one (it does something in the middle :) ). See also #2950. Anyway, I like the fact that :force does not stop at breakpoints. This ticket #2946 is related to :force too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 15:26:01 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 15:17:05 2009 Subject: [GHC] #2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669 In-Reply-To: <053.ce70667c924b83874db7013d3e3aa9b8@localhost> References: <053.ce70667c924b83874db7013d3e3aa9b8@localhost> Message-ID: <062.29b671642dd33dc8b4e77d5fb24b36c0@localhost> #2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669 --------------------------------------------------+------------------------- Reporter: batterseapower | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: simplCore/should_compile/simpl014 | Os: MacOS X Architecture: Unknown/Multiple | --------------------------------------------------+------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Confirmed: `simpl014` now passes with `./validate --slow`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 15:33:07 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 15:24:16 2009 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.c506fc826cea8154d0f712d59f6829c7@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD, Xen | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 18:41:01 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 18:32:06 2009 Subject: [GHC] #2961: Incorrect FFI code generated with -O Message-ID: <047.94e145e737e8c361ae873a27f61ac99c@localhost> #2961: Incorrect FFI code generated with -O ---------------------+------------------------------------------------------ Reporter: sjanssen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---------------------+------------------------------------------------------ GHC 6.10.1 seems to generate incorrect code for createWindow in X11-1.4.3 on x86_64 when optimizations are on. {{{ $ ghc-6.10.1 -fforce-recomp --make simple.hs -O0 -o simple $ ghc-6.10.1 -fforce-recomp --make simple.hs -O -o simple_optimized }}} When built with no optimizations, the program succeeds: {{{ $ ./simple (33554433,Display 0x0000000001192dd0,Screen 0x0000000001193a40,194) }}} When built with optimizations, the X server sends an error about an invalid parameter to a XCreateWindow call: {{{ $ ./simple_optimized (33554433,Display 0x0000000000b91dd0,Screen 0x0000000000b92a40,194) X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 7 Current serial number in output stream: 8 }}} We set a breakpoint at XCreateWindow to check the arguments passed, note that depth takes the correct value in the non-optimized version: {{{ $ gdb simple (gdb) break XCreateWindow (gdb) run ... Breakpoint 1, XCreateWindow (dpy=0x172bde0, parent=194, x=0, y=0, width=100, height=100, borderWidth=0, depth=24, class=1, visual=0x17333d0, valuemask=512, attributes=0x7f920a77e040) at ../../src/Window.c:115 115 ../../src/Window.c: No such file or directory. in ../../src/Window.c }}} The optimized version has "depth=38044640", which is total nonsense. The value seems to change from run to run. {{{ $ gdb simple_optimized (gdb) break XCreateWindow (gdb) run ... Breakpoint 1, XCreateWindow (dpy=0x2440df0, parent=194, x=0, y=0, width=100, height=100, borderWidth=0, depth=38044640, class=1, visual=0x24483e0, valuemask=512, attributes=0x7f84f577e040) at ../../src/Window.c:115 115 ../../src/Window.c: No such file or directory. in ../../src/Window.c }}} We discovered this bug in xmonad (http://xmonad.org/bugs/226), and have temporarily worked around it by using Cabal's --disable-optimization flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 18:47:40 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 18:38:49 2009 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.026c960671e7076a1052b190ff9c782a@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD, Xen | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by wolverian): Replying to [comment:18 simonmar]: > The builds are working, but the testsuite is rather broken right now. You should be able to build GHC enough to test it, though. I'm hitting this problem while building the current git head: ... (last succesfullly compiled file:) /home/wolverian/ghc/ghc/stage1-inplace/ghc -H32m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c Exception.cmm -o Exception.o (then the error:) Apply.cmm:0:1: lexical error This is on Ubuntu 8.10, x86_64, no virtualisation (phew!). I'm building with the default options. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 19:17:36 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 19:08:39 2009 Subject: [GHC] #2643: Optimized IntMap / IntSet construction from sorted input In-Reply-To: <048.5a067deefc3b5a1c5d97037f58a7321f@localhost> References: <048.5a067deefc3b5a1c5d97037f58a7321f@localhost> Message-ID: <057.4aec1413d88c31237f0b764f4faa928c@localhost> #2643: Optimized IntMap / IntSet construction from sorted input ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: containers | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 19:17:38 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 19:08:44 2009 Subject: [GHC] #2644: type of IntMap.intersection[WithKey] is incorrect In-Reply-To: <048.cdf8c7c801b2eb701f7311923129020e@localhost> References: <048.cdf8c7c801b2eb701f7311923129020e@localhost> Message-ID: <057.29dcc0970e15c53e865458322630e48d@localhost> #2644: type of IntMap.intersection[WithKey] is incorrect ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: containers | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 19:17:41 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 19:08:48 2009 Subject: [GHC] #2645: fix type, performance of IntMap(Set).findMin(Max) In-Reply-To: <048.8a9f13834a53ec09c2896007b23bea4f@localhost> References: <048.8a9f13834a53ec09c2896007b23bea4f@localhost> Message-ID: <057.654579062f4ad44cc70bd8f007e1fed1@localhost> #2645: fix type, performance of IntMap(Set).findMin(Max) ----------------------------------+----------------------------------------- Reporter: sedillard | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: containers | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 19:20:14 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 19:11:18 2009 Subject: [GHC] #2445: better error message needed for missing package files In-Reply-To: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> References: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> Message-ID: <054.4483b7d7ffae91095cc6918dbf6159ec@localhost> #2445: better error message needed for missing package files ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 16 19:20:34 2009 From: trac at galois.com (GHC) Date: Fri Jan 16 19:11:38 2009 Subject: [GHC] #2931: Template Haskell: Quoting single letter identifier leads to a parse error at end of input. In-Reply-To: <044.8efc30367993250a8b68353fa140f283@localhost> References: <044.8efc30367993250a8b68353fa140f283@localhost> Message-ID: <053.e6fa8b755d021675a9bfa2cd54d90b64@localhost> #2931: Template Haskell: Quoting single letter identifier leads to a parse error at end of input. ----------------------------------+----------------------------------------- Reporter: int-e | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T2931 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 17 04:43:15 2009 From: trac at galois.com (GHC) Date: Sat Jan 17 04:34:16 2009 Subject: [GHC] #2962: Fix space leak in genericLength Message-ID: <050.56d33139a9874005c965ed3f7cb60dae@localhost> #2962: Fix space leak in genericLength -----------------------------+---------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- There is a space leak in {{{genericLength}}}: {{{ $ ghc/stage2-inplace/ghc --interactive GHCi, version 6.11.20090116: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude> :module +List Prelude List> genericLength [1..600000] *** Exception: stack overflow Prelude List> Prelude List> length [1..600000] 600000 Prelude List> }}} The attached patch against the base library provides a fix. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 17 08:18:24 2009 From: trac at galois.com (GHC) Date: Sat Jan 17 08:15:55 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.7c97962083eeb95962a30e057a92582a@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by simonmar): I'm confused. `x86_64-pc-solaris2` is not a platform we currently support. I made the first step towards supporting this platform, namely to update `config.guess` to recognise the platform. Why then do you want to map the platform to `i386-pc-solaris`? Won't that go wrong, because gcc is generating code for x86_64? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 17 11:36:02 2009 From: trac at galois.com (GHC) Date: Sat Jan 17 11:27:05 2009 Subject: [GHC] #2962: Fix space leak in genericLength In-Reply-To: <050.56d33139a9874005c965ed3f7cb60dae@localhost> References: <050.56d33139a9874005c965ed3f7cb60dae@localhost> Message-ID: <059.c245f95feaa5e0b3be002369a2884ac8@localhost> #2962: Fix space leak in genericLength ------------------------------+--------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by NeilMitchell): The patch is incorrect. If the (+) function isn't strict in both arguments then you are too strict. You could always add genericLength', and add specialisation rules for genericLength on Int/Integer/Float/Double, which gets you all the benefits in the common cases but still preserves the semantics. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 17 12:12:03 2009 From: trac at galois.com (GHC) Date: Sat Jan 17 12:03:05 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.a30b59cc1cab6ebb41204195e2c91db9@localhost> #2953: deriving Functor, Foldable, Traversable ------------------------------+--------------------------------------------- Reporter: twanvl | Owner: twanvl Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by twanvl): As a start, I have implemented the deriving for the Functor class only. For some reason the patch is too big to attach, it can be found at [http://twan.home.fmf.nl/files/deriving-functor2.patch.gz]. A patch with testcases is attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 17 12:51:30 2009 From: trac at galois.com (GHC) Date: Sat Jan 17 12:49:00 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.d320a31fe6874337bdc8f5102db11e72@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by kgardas): It is simple, Solaris on amd64 aka x86_64 platform supports two ABI: one 64bit and one 32bit. Till now using older version of config.guess my amd64/solaris box was recognized as i386-solaris and GHC behaves accordingly and builds well (for i386-solaris2). Since your config.guess update, GHC knows it's configured on amd64-solaris and complains about unsupported platform. So my fix is natural fix to make GHC again believe this is i386-solaris as it supports it all the time. Of course it's very easy for anyone interested just to revert this simple patch and hack on real amd64-solaris platform support. Is it more clear now? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 17 13:42:55 2009 From: trac at galois.com (GHC) Date: Sat Jan 17 13:40:27 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.82d52e9f0dd882d9af8023602bbad4da@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by kgardas): I would also like to add my analysis, if you don't have amd64/solaris2 platform at hands. So Solaris supports 2 ABIs, provides gcc 3.4.3 which by default generates 32bit code for i386 ABI. It might be also used to generate 64bit code for amd64 ABI if started with -m64 command-line option. If I'm right, then for GHC build, we do have i386 ABI GHC for Solaris in binary form and so stage1 compiler should also be compiled for i386, but it should be a cross-compiler run on i386 generating code for amd64 ABI. Stage2 compiler should then be amd64 ABI and also in stage2 build and rts build executed gcc should be used with -m64 option to get 64bit binary. Now, the question is just where to hack to make it real. :-) (if I'm right of course) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 17 18:22:08 2009 From: trac at galois.com (GHC) Date: Sat Jan 17 18:13:09 2009 Subject: [GHC] #2250: unpackFamily on Windows fails match In-Reply-To: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> References: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> Message-ID: <053.32d0f75d0149a50122665a3fb61c2b92@localhost> #2250: unpackFamily on Windows fails match ----------------------------------+----------------------------------------- Reporter: larsv | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Moved to http://trac.haskell.org/network/ticket/1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 17 22:19:26 2009 From: trac at galois.com (GHC) Date: Sat Jan 17 22:10:31 2009 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 In-Reply-To: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> References: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> Message-ID: <061.a8239d7b956d674d397c44460bee094c@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: gwern0@gmail.com (added) Comment: Just to chip in: i386 Intrepid Ubuntu, GHC HQ's 6.10 binaries, darcs Crypto. Adding the -freg-graphs option to the sha1test stanza fixed the compilation problem for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 18 10:59:02 2009 From: trac at galois.com (GHC) Date: Sun Jan 18 10:50:00 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.d83fc314b11656b5af98cc3413c3ebe0@localhost> #2953: deriving Functor, Foldable, Traversable ------------------------------+--------------------------------------------- Reporter: twanvl | Owner: twanvl Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by twanvl): Deriving Foldable and Traversable instances is now also possible. The code is very similar, so I abstracted it a bit. The patch is still too large to attach, it can be found at [http://twan.home.fmf.nl/files/deriving-functor3.patch.gz]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 18 10:59:37 2009 From: trac at galois.com (GHC) Date: Sun Jan 18 10:50:35 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.e44fb1dac114c2bab1963a064fc92326@localhost> #2953: deriving Functor, Foldable, Traversable ------------------------------+--------------------------------------------- Reporter: twanvl | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by twanvl): * owner: twanvl => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 18 14:24:01 2009 From: trac at galois.com (GHC) Date: Sun Jan 18 14:15:01 2009 Subject: [GHC] #1377: GHCi debugger tasks In-Reply-To: <047.b3e158073b17fc81d3d320da105cad09@localhost> References: <047.b3e158073b17fc81d3d320da105cad09@localhost> Message-ID: <056.94ca34a6524103558ef2af6138667308@localhost> #1377: GHCi debugger tasks ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by mnislaih): * cc: mnislaih@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 18 14:24:27 2009 From: trac at galois.com (GHC) Date: Sun Jan 18 14:15:25 2009 Subject: [GHC] #2950: show breakpoint numbers of breakpoints which were ignored during :force In-Reply-To: <046.8fc12104263edfe21a0114a0a4deb184@localhost> References: <046.8fc12104263edfe21a0114a0a4deb184@localhost> Message-ID: <055.1d76d3a202eb62e52b8466f4f6a6445d@localhost> #2950: show breakpoint numbers of breakpoints which were ignored during :force ------------------------------+--------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: trivial | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by mnislaih): * cc: mnislaih@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Sun Jan 18 15:53:37 2009 From: conal at conal.net (Conal Elliott) Date: Sun Jan 18 15:44:35 2009 Subject: Build difficulties with HEAD In-Reply-To: <20090114222935.GA20479@matrix.chaos.earth.li> References: <20090111151124.GA3773@matrix.chaos.earth.li> <20090114222935.GA20479@matrix.chaos.earth.li> Message-ID: Worked for me this time. Thanks! On Wed, Jan 14, 2009 at 2:29 PM, Ian Lynagh wrote: > On Sun, Jan 11, 2009 at 09:42:22AM -0800, Conal Elliott wrote: > > Thanks, Ian. That tweak helped. Now "make" succeeds, but "sudo make > > install" dies, as shown below. - Conal > > > > > /home/conal/downloads/ghc-6.11.20090109/utils/ghc-pkg/dist-install/build/ghc-pkg/ghc-pkg > > --global-conf /usr/local/lib/ghc-6.11.20090109/package.conf update - > --force > > ghc-pkg: /usr/local/lib/ghc-6.11.20090109/package.conf: openFile: does > not > > exist (No such file or directory) > > Now fixed. > > > Thanks > Ian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20090118/f8f6dee2/attachment.htm From trac at galois.com Sun Jan 18 16:49:47 2009 From: trac at galois.com (GHC) Date: Sun Jan 18 16:40:45 2009 Subject: [GHC] #2962: Reduce space usage of genericLength for common Num instances In-Reply-To: <050.56d33139a9874005c965ed3f7cb60dae@localhost> References: <050.56d33139a9874005c965ed3f7cb60dae@localhost> Message-ID: <059.73c1d4ae4c08268523c09a0deccaadeb@localhost> #2962: Reduce space usage of genericLength for common Num instances ------------------------------+--------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by thorkilnaur): * owner: => thorkilnaur * summary: Fix space leak in genericLength => Reduce space usage of genericLength for common Num instances Comment: Thank you very much. I will look into this. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 03:17:18 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 03:08:16 2009 Subject: [GHC] #2963: Exception if current path has national symbols Message-ID: <044.20cd1d7dd4607528a617f9d3d52f59f8@localhost> #2963: Exception if current path has national symbols --------------------+------------------------------------------------------- Reporter: Tonal | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- Environment: Windows Vista Home Ru + sp1 ghc 6.10.1 Example for error: {{{ C:\Lang\Projects\nikzam\report\??????>ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> let s = 1 *** Exception: SetCurrentDirectory: does not exist ( 5 C405BAO =09B8 C:070==K9 D09;.) Prelude> :q Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 04:16:20 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 04:08:24 2009 Subject: [GHC] #2759: Data.Generics.ConstrRep isn't general enough In-Reply-To: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> References: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> Message-ID: <053.daaa759c6cb88b384d807890d9f739e7@localhost> #2759: Data.Generics.ConstrRep isn't general enough ----------------------------------+----------------------------------------- Reporter: guest | Owner: dreixel Type: bug | Status: assigned Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by dreixel): Attached a new patch which deprecates mkIntConstr and mkFloatConstr, and introduces mkIntegralConstr and mkRealConstr. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 04:25:35 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 04:16:32 2009 Subject: [GHC] #2875: Correct SYB's representation of Char In-Reply-To: <046.b0f5f032bb0b9756d1b0c1824b96239d@localhost> References: <046.b0f5f032bb0b9756d1b0c1824b96239d@localhost> Message-ID: <055.e46e18139073eae33bf3900b02c85db1@localhost> #2875: Correct SYB's representation of Char ------------------------------+--------------------------------------------- Reporter: dreixel | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by dreixel): * cc: jpm@cs.uu.nl (added) Comment: The discussion period is now over. According to the feedback from Neil, I attached a new patch where '!StringRep' disappears completely instead of being deprecated. The function 'mkStringRep', however, is kept as deprecated (and now uses the new '!CharRep'). The entire discussion is here: http://thread.gmane.org/gmane.comp.lang.haskell.generics/51 The file base-sybChar.new.patch replaces the old base-sybChar.patch. This new patch seems to include my fix for #2759. I don't know if this is a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 06:28:37 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 06:19:35 2009 Subject: [GHC] #2875: Correct SYB's representation of Char In-Reply-To: <046.b0f5f032bb0b9756d1b0c1824b96239d@localhost> References: <046.b0f5f032bb0b9756d1b0c1824b96239d@localhost> Message-ID: <055.6e1d3b3736f6f3d38b863f105f37300c@localhost> #2875: Correct SYB's representation of Char ------------------------------+--------------------------------------------- Reporter: dreixel | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by dreixel): Also added new patches for the compiler and template-haskell repositories, since the old ones generated warnings which caused validate to fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 08:23:22 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 08:14:19 2009 Subject: [GHC] #2964: System.Directory.getCurrentDirectory doesn't work on win32 if the current directory has non-ascii characters in its name Message-ID: <044.6eaf2b0abf33443a64d1d6f7b535c905@localhost> #2964: System.Directory.getCurrentDirectory doesn't work on win32 if the current directory has non-ascii characters in its name --------------------+------------------------------------------------------- Reporter: kirby | Owner: Type: bug | Status: new Priority: normal | Component: libraries/directory Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- If you create a path with an international character in it (accented letters are not enough, but russian characters or the euro symbol "?" is), and you try to call getCurrentDirectory from there (e.g. with ghci), it raises an exception: {{{ Prelude System.Directory> getCurrentDirectory *** Exception: SetCurrentDirectory: does not exist (The system cannot find the file specified.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 10:02:21 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 09:53:19 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit Message-ID: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> #2965: GHC on OS X does not compile 64-bit ----------------------------+----------------------------------------------- Reporter: Axman6 | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86_64 (amd64) ----------------------------+----------------------------------------------- Not much to say other than GHC does not compile as a 64-bit program on OS X, even on 64-bit systems (all shipping macs are 64-bit, and have been for somewhere up to a year). I've tried to see if i can get it to compile 64-bit, and I haven't had any luck at all. configure doesn't seem to take any notice of CFLAGS etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 12:29:10 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 12:20:04 2009 Subject: [GHC] #2966: build system does not respect --with-gcc= Message-ID: <045.38910ced362f70db06ad52953362394b@localhost> #2966: build system does not respect --with-gcc= -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The ./configure scripts for all the core libs do not respect the `--with- gcc=` flag. The current build system passes this flag but it gets ignored. This means that overall the ghc build does not respect the `--with-gcc=` flag. This is kind of annoying for doing a build on Solaris, since we have to use a gcc other than the standard system one. When using a 'fake' gcc on the `$PATH` (a shell script that always fails), we get: {{{ ghc/libraries/unix $ ./configure --with-gcc=/opt/gcc-vanilla/4.1.2/bin/gcc configure: WARNING: unrecognized options: --with-gcc checking for gcc... gcc checking for C compiler default output file name... configure: error: in `/home/duncan/prgs/ghc/libraries/unix': configure: error: C compiler cannot create executables See `config.log' for more details. }}} The same problem occurs with: base, directory, process, old-time and editline. These are all of the core packages that use `./configure` scripts. On the other hand they all seem to check the `CC` environment variable. Perhaps the ghc build system should pass `--with-gcc=` to the Cabal Setup, and perhaps that should call configure with `CC` set. The problem applies to ghc-6.8.3 and ghc-HEAD (so probably also 6.10.x). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 12:53:12 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 12:44:15 2009 Subject: [GHC] #2966: build system does not respect --with-gcc= In-Reply-To: <045.38910ced362f70db06ad52953362394b@localhost> References: <045.38910ced362f70db06ad52953362394b@localhost> Message-ID: <054.b9db5f65a1ecee9d7fe9312507e0c27d@localhost> #2966: build system does not respect --with-gcc= ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Comment: They accept `--with-cc`. Is `--with-gcc` more standard? I don't know if supporting both is easy or not. The current code is: {{{ AC_ARG_WITH([cc], [C compiler], [CC=$withval]) AC_PROG_CC() }}} so perhaps {{{ AC_ARG_WITH([gcc], [C compiler], [CC=$withval]) AC_ARG_WITH([cc], [C compiler], [CC=$withval]) AC_PROG_CC() }}} or similar would work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 12:56:48 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 12:47:46 2009 Subject: [GHC] #2875: Correct SYB's representation of Char In-Reply-To: <046.b0f5f032bb0b9756d1b0c1824b96239d@localhost> References: <046.b0f5f032bb0b9756d1b0c1824b96239d@localhost> Message-ID: <055.d622f1bc6103fdeebda86145089f49c1@localhost> #2875: Correct SYB's representation of Char ---------------------------------+------------------------------------------ Reporter: dreixel | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 13:01:54 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 12:52:59 2009 Subject: [GHC] #2966: build system does not respect --with-gcc= In-Reply-To: <045.38910ced362f70db06ad52953362394b@localhost> References: <045.38910ced362f70db06ad52953362394b@localhost> Message-ID: <054.6b2f13e6b013f04c5d31f7ed36ad8076@localhost> #2966: build system does not respect --with-gcc= ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): In that case the ghc build system should pass `--with-cc` instead of `--with-gcc` as it does currently. Currently it looks like it just blindly passes all top-level `./configure` flags to all libraries via Cabal's `--configure-option` mechanism. Either that or the top level `./configure` script should accept `--with-cc` and not `--with-gcc`. One way or another we've got a mismatch between the top-level `./configure` script and all the library `./configure` scripts. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 13:17:24 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 13:08:17 2009 Subject: [GHC] #2966: build system does not respect --with-gcc= In-Reply-To: <045.38910ced362f70db06ad52953362394b@localhost> References: <045.38910ced362f70db06ad52953362394b@localhost> Message-ID: <054.2d1fc7a7e44d424f217cd356a65b3243@localhost> #2966: build system does not respect --with-gcc= ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 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 Mon Jan 19 13:17:44 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 13:08:40 2009 Subject: [GHC] #2963: Exception if current path has national symbols In-Reply-To: <044.20cd1d7dd4607528a617f9d3d52f59f8@localhost> References: <044.20cd1d7dd4607528a617f9d3d52f59f8@localhost> Message-ID: <053.12318dc6f4951943a748f2985ec29667@localhost> #2963: Exception if current path has national symbols ---------------------+------------------------------------------------------ Reporter: Tonal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------+------------------------------------------------------ Comment (by Tonal): See als http://bugs.darcs.net/issue1320 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 14:13:36 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 14:04:29 2009 Subject: [GHC] #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets In-Reply-To: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> References: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> Message-ID: <056.5a9daf3da55e572e2d591a1a5ea7315f@localhost> #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets -------------------------------+-------------------------------------------- Reporter: tphyahoo | Owner: bos Type: bug | Status: assigned Priority: normal | Milestone: Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: ipv6 | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by tphyahoo): Yes, not a very good patch I agree. I had an uncaught exception error a couple of days after I implemented. Anyway, here's a tweaked patch, which at least fixes that. {{{ < (Just peer, _) <- getNameInfo [] True False addr --- > (Just peer) <- > catchIO ( return . fst =<< getNameInfo [] True False addr ) > (\e -> case addr of > SockAddrInet port haddr -> return . Just =<< inet_ntoa haddr > SockAddrInet6 port flow haddr6 scope -> return . Just . show $ haddr6 > SockAddrUnix x -> return . Just $ x > ) > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 14:15:18 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 14:06:11 2009 Subject: [GHC] #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets In-Reply-To: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> References: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> Message-ID: <056.5c93fa89a3b13cb948387a86c1c6db99@localhost> #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets -------------------------------+-------------------------------------------- Reporter: tphyahoo | Owner: bos Type: bug | Status: assigned Priority: normal | Milestone: Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: ipv6 | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by tphyahoo): Also, for what it's worth, a quick and dirty fix which at least keeps happs apps from dying is simply to turn off ipv6 support like so: {{{ diff -rN old-network-2.2.0.1/Network.hs new-network-2.2.0.1/Network.hs 22c22 < #define IPV6_SOCKET_SUPPORT 1 --- > # /* define IPV6_SOCKET_SUPPORT 1 */ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 19 18:09:41 2009 From: trac at galois.com (GHC) Date: Mon Jan 19 18:00:39 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.600b993b2d44a3f469b3f02b71d7086f@localhost> #2965: GHC on OS X does not compile 64-bit -----------------------------+---------------------------------------------- Reporter: Axman6 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86_64 (amd64) -----------------------------+---------------------------------------------- Comment (by chak): I agree that it would be interesting to get this to work. But this won't be done with a couple of CFLAGS. There is more involved, such as getting the runtime system compile for 64bit. All the required code should already be in there (for 64bit support on other archs), but the Mac build currently assumes 32bit. So, that should be split into two paths, one Mac 32bit and one Mac 64bit (and then there is Mac ppc of course). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 03:03:55 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 02:54:54 2009 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.bb3d51f9aa7be67b81142bca30d3bea4@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------+---------------------------------------------------- Comment (by juhpetersen): For fedora it turned out problem was that ncurses-devel was needed for editline to configure correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 09:47:20 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 09:38:12 2009 Subject: [GHC] #2967: GHC panics while building the Crypto library Message-ID: <044.b9db496863116e41accd481bd65cc07c@localhost> #2967: GHC panics while building the Crypto library -------------------+-------------------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- GHC panics when I try to build Crypto-4.1.0. {{{ $ cabal -V cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library $ cabal install Crypto ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph }}} I've attached the full build log. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 09:51:19 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 09:42:11 2009 Subject: [GHC] #2967: GHC panics while building the Crypto library In-Reply-To: <044.b9db496863116e41accd481bd65cc07c@localhost> References: <044.b9db496863116e41accd481bd65cc07c@localhost> Message-ID: <053.9a8e2bbcc711e2dd1c7c9e86db57c446@localhost> #2967: GHC panics while building the Crypto library ----------------------+----------------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Changes (by liesen): * cc: johanliesen+ghc@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 09:52:34 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 09:43:28 2009 Subject: [GHC] #2967: GHC panics while building the Crypto library In-Reply-To: <044.b9db496863116e41accd481bd65cc07c@localhost> References: <044.b9db496863116e41accd481bd65cc07c@localhost> Message-ID: <053.2de0ae658004bdadd376c3897953843b@localhost> #2967: GHC panics while building the Crypto library ----------------------+----------------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Comment (by liesen): This also happens on os x (leopard) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 09:55:50 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 09:46:43 2009 Subject: [GHC] #2967: GHC panics while building the Crypto library In-Reply-To: <044.b9db496863116e41accd481bd65cc07c@localhost> References: <044.b9db496863116e41accd481bd65cc07c@localhost> Message-ID: <053.c60b0862f7eb25a22bbeaac64ade67ff@localhost> #2967: GHC panics while building the Crypto library ------------------------------+--------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by tibbe): * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Confirmed on Mac OS X 10.5 on my MacBook Pro Core 2 Duo in addition to Linux/x86_64. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 10:21:57 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 10:12:52 2009 Subject: [GHC] #2919: ghc panic while compiling Crypto In-Reply-To: <045.deee858f6ff0d3e43625e8810078b454@localhost> References: <045.deee858f6ff0d3e43625e8810078b454@localhost> Message-ID: <054.5135bc156103e3b78d3882d95732781f@localhost> #2919: ghc panic while compiling Crypto -------------------------+-------------------------------------------------- Reporter: wchogg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report; this is a duplicate of #2753. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 10:22:02 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 10:13:03 2009 Subject: [GHC] #2967: GHC panics while building the Crypto library In-Reply-To: <044.b9db496863116e41accd481bd65cc07c@localhost> References: <044.b9db496863116e41accd481bd65cc07c@localhost> Message-ID: <053.cf9f86c3a1b04600a0afa3a0d025d162@localhost> #2967: GHC panics while building the Crypto library ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | 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 #2753. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 10:28:18 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 10:19:16 2009 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 In-Reply-To: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> References: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> Message-ID: <061.7045e8a5e47ed7ac5fee3415313d5129@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by liesen): * cc: liesen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 10:34:19 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 10:25:10 2009 Subject: [GHC] #2968: add test for C trigraphs Message-ID: <045.2a7f68178978b83c4a4101bfbab4cf22@localhost> #2968: add test for C trigraphs -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- {{{ main = print "??)" }}} If we compile the above `-fvia-C` then some gcc versions report: {{{ /tmp/ghc6084_0/ghc6084_0.hc:99:30: warning: trigraph ??) ignored, use -trigraphs to enable }}} This should make us nervous. According to the GCC manual if we were ever to use `-std=c89` or any of the official C standard compliance modes (ie non-GNU) then we would get standard C (cpp) trigraph behavior. We should therefore add a codeGen/should_run test to make sure that the above program does always print `"??)"` and never `"]"`. This test only needs to be run for the `-fvia-C` 'ways', optc etc. It's not an immediate priority but it may trip someone up in future when porting or if we make unregisterised C code more standards compliant and start using one of the official `-std=` modes. It is unlikely to hit us but if it ever did it'd be a real pain to debug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 10:35:36 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 10:26:26 2009 Subject: [GHC] #2968: add test for C trigraphs In-Reply-To: <045.2a7f68178978b83c4a4101bfbab4cf22@localhost> References: <045.2a7f68178978b83c4a4101bfbab4cf22@localhost> Message-ID: <054.f70c4a8ffebcb64dbe901614ee8cc6f7@localhost> #2968: add test for C trigraphs ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by duncan): For info on gcc's treatment of trigraphs see http://gcc.gnu.org/onlinedocs/cpp/Initial-processing.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 10:59:11 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 10:50:03 2009 Subject: [GHC] #2968: add test for C trigraphs In-Reply-To: <045.2a7f68178978b83c4a4101bfbab4cf22@localhost> References: <045.2a7f68178978b83c4a4101bfbab4cf22@localhost> Message-ID: <054.fd7b01c37f281389da6ec4cd3d672ed4@localhost> #2968: add test for C trigraphs ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 11:27:51 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 11:18:47 2009 Subject: [GHC] #2929: INFINITY used in .hc files without -std=c99 In-Reply-To: <045.9c2069ffa5b68c9fb1e9f0987d2d791e@localhost> References: <045.9c2069ffa5b68c9fb1e9f0987d2d791e@localhost> Message-ID: <054.99e380bd9b691554f6c3a52a1c5e953a@localhost> #2929: INFINITY used in .hc files without -std=c99 -------------------------------+-------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: 1861 | Os: Solaris Architecture: sparc | -------------------------------+-------------------------------------------- Comment (by duncan): Note we should not use `-std=c99` without considering trigraphs, see #2968. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 13:02:11 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 12:53:05 2009 Subject: [GHC] #566: mips-sgi-irix6.5 port? In-Reply-To: <052.423537dd1667da6746f7c1d58532a716@localhost> References: <052.423537dd1667da6746f7c1d58532a716@localhost> Message-ID: <061.7216709334cc7ca960a06fc20bf67b66@localhost> #566: mips-sgi-irix6.5 port? ---------------------------------+------------------------------------------ Reporter: duncan_coutts | Owner: nobody Type: feature request | Status: closed Priority: normal | Milestone: _|_ Component: None | Version: None Severity: minor | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by duncan): * status: assigned => closed * resolution: None => wontfix Comment: I withdraw the feature request :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 13:02:19 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 12:53:16 2009 Subject: [GHC] #186: Bad sparc Int64 code via NCG with -O In-Reply-To: <045.00b040dbc11af02e0fa7455a84a2a38a@localhost> References: <045.00b040dbc11af02e0fa7455a84a2a38a@localhost> Message-ID: <054.4cd4f28a10484e250b73d16b32962ea5@localhost> #186: Bad sparc Int64 code via NCG with -O -------------------------------+-------------------------------------------- Reporter: nobody | Owner: benl Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler (NCG) | Version: 6.0.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: enum02 | Os: Unknown/Multiple Architecture: sparc | -------------------------------+-------------------------------------------- Comment (by duncan): Yay, Ben's got a fix: http://ghcsparc.blogspot.com/2009/01/grind.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 13:22:17 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 13:13:08 2009 Subject: [GHC] #2969: unix package built wrong on Solaris Message-ID: <045.0d30450289e14ebfae501919df8c4ac3@localhost> #2969: unix package built wrong on Solaris --------------------+------------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Os: Solaris | Architecture: sparc --------------------+------------------------------------------------------- On Solaris with recent gcc versions the unix package gets built with an inconsistent state of system header files which results in `getSymbolicLinkStatus` not working. In turn this breaks darcs. The problem is that the `HsUnix.h` file contains a bunch of inline functions. These get inlined into the `.hc` file for the `Files.hs` module that FFI imports them. The problem is that this `.hc` file `#include`s an RTS header files which uses some `#define` to get certain API spec compatibility and for some reason this causes the `lstat()` call to be directed to the 32bit file ABI whereas the `.hsc` file was compiled for the 64bit (large file support) ABI. The outcome is that the `.o` file for the `System.Posix.Files` module is actually calling the `lstat()` function when it expects to be calling the `lstat64()` function. As a result we get back the wrong `struct stat` and so of course all the functions like `isDirectory` etc are then looking at the wrong offsets in the `struct stat`. The functions that are being FFI imported are compiled into the `cbits/HsUnix.c` file anyway (because it `#import`s `HsUnix.h` with a `#define` to turn off the inlining) so there is no need for them to be inlined into the `.hc` file. The `cbits/HsUnix.c` gets built correctly (because it does not `#include` the RTS headers that cause the problem) and so does call `lstat64` rather than `lstat()`. This can be verified with `nm`. So the solution is to remove all the inline calls from `HsUnix.h`, changing them to simple prototypes, and to put the function bodies in `HsUnix.c`. This solution works fine. Tested on Solaris 10, ghc-6.8.3. The files appear to be unchanged in ghc 6.10 and HEAD so the same solution should work there. We should add a test case for this. It should test the `getSymbolicLinkStatus` function with a few things that obviously should work, like `isDirectory` etc. We might as well test `getFileStatus` too. The difference is that the FFI wrapper for `getFileStatus` is defined in the `base` package rather than the `unix` package. This is why it was unaffected by the above problem. Generally all the FFI wrappers defined via inlines in `.h` files that get `#include`d into `.hc` files are rather suspect, but especially so for wrappers of things defined in system header files. These should instead be wrapped in very simple .c files that `#include` a minimum of headers so as to not bump into weird untested combinations of system headers and standards compatibility `#define`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 14:30:51 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 14:21:44 2009 Subject: [GHC] #2943: Socket related IO cannot be be interrupted on Windows In-Reply-To: <049.2b628271ed720c2ee352804d23fc025a@localhost> References: <049.2b628271ed720c2ee352804d23fc025a@localhost> Message-ID: <058.b7146a01c9b7d38304df7ef8594194e3@localhost> #2943: Socket related IO cannot be be interrupted on Windows ----------------------------------+----------------------------------------- Reporter: h.holtmann | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Moved here: http://trac.haskell.org/network/ticket/2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 15:17:07 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 15:07:59 2009 Subject: [GHC] #2936: System.IO.Error needs to be imported unconditionally In-Reply-To: <044.99c35a4c8efbffdbebdc4f42d12f0d2d@localhost> References: <044.99c35a4c8efbffdbebdc4f42d12f0d2d@localhost> Message-ID: <053.865226cf6e125fea94174e5eb78e1990@localhost> #2936: System.IO.Error needs to be imported unconditionally ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/network | Version: 6.10.1 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've pushed an untested patch; please reopen if it's still broken for you. {{{ Tue Jan 20 20:10:57 GMT 2009 Ian Lynagh * Move imports out of ifdefs; fixes building with hugs (GHC trac #2936) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 15:51:23 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 15:42:15 2009 Subject: [GHC] #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets In-Reply-To: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> References: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> Message-ID: <056.861c2f5e251a564c565e7ec401caa825@localhost> #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets ----------------------------------+----------------------------------------- Reporter: tphyahoo | Owner: bos Type: bug | Status: assigned Priority: normal | Milestone: Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: ipv6 | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: FWIW, I think `liftM fst` is clearer than `return . fst =<< `. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 15:55:06 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 15:46:02 2009 Subject: [GHC] #2784: Cannot call connect with a socket that is already bound. In-Reply-To: <047.de4c3c5f634fbec7d0b7644c39e5f764@localhost> References: <047.de4c3c5f634fbec7d0b7644c39e5f764@localhost> Message-ID: <056.d298971ee9764e73486c96fee2746383@localhost> #2784: Cannot call connect with a socket that is already bound. ----------------------------------+----------------------------------------- Reporter: felixmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Moved to here: http://trac.haskell.org/network/ticket/3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 15:59:15 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 15:50:07 2009 Subject: [GHC] #2774: sIsReadable and sIsWritable return true after socket is closed. In-Reply-To: <047.480c8e606a3bfd77cd4272bd9432134f@localhost> References: <047.480c8e606a3bfd77cd4272bd9432134f@localhost> Message-ID: <056.403d685994f39e493cc69ff677212b36@localhost> #2774: sIsReadable and sIsWritable return true after socket is closed. ----------------------------------+----------------------------------------- Reporter: felixmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Moved here: http://trac.haskell.org/network/ticket/4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 16:18:38 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 16:09:28 2009 Subject: [GHC] #2726: getAddrInfo and addrFamily not in scope on Windows GHC 6.8 In-Reply-To: <055.2cef317f10a8954736a4828068318f0d@localhost> References: <055.2cef317f10a8954736a4828068318f0d@localhost> Message-ID: <064.f3dad9ccd16de9f8cfcf0453ea4acf91@localhost> #2726: getAddrInfo and addrFamily not in scope on Windows GHC 6.8 ----------------------------------+----------------------------------------- Reporter: speaker2machines | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Moved here: http://trac.haskell.org/network/ticket/5 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 16:59:18 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 16:50:17 2009 Subject: [GHC] #2875: Correct SYB's representation of Char In-Reply-To: <046.b0f5f032bb0b9756d1b0c1824b96239d@localhost> References: <046.b0f5f032bb0b9756d1b0c1824b96239d@localhost> Message-ID: <055.213df590a5f340997cc3a9b9038c83e8@localhost> #2875: Correct SYB's representation of Char ---------------------------------+------------------------------------------ Reporter: dreixel | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | 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: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 16:59:39 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 16:50:43 2009 Subject: [GHC] #2759: Data.Generics.ConstrRep isn't general enough In-Reply-To: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> References: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> Message-ID: <053.c733db5f3c0cc630ac7f0f967e6a96ae@localhost> #2759: Data.Generics.ConstrRep isn't general enough ----------------------------------+----------------------------------------- Reporter: guest | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: assigned => closed * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 17:11:27 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 17:02:46 2009 Subject: [GHC] #2968: add test for C trigraphs In-Reply-To: <045.2a7f68178978b83c4a4101bfbab4cf22@localhost> References: <045.2a7f68178978b83c4a4101bfbab4cf22@localhost> Message-ID: <054.eacb81c68c2a536766fe84c7b0500b83@localhost> #2968: add test for C trigraphs ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: igloo => * milestone: => 6.12 branch Comment: Good point; I've added a test `cg063`. It would make sense to avoid generating them too. Based on what `gcc -Wall` says, `"??)"` is a trigraph but `"?" "?)"` isn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 19:41:15 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 19:32:52 2009 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.d3bf5fd59e94e90a251ae8fe622cfdcb@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc -------------------------+-------------------------------------------------- Reporter: maeder | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Comment (by igloo): Thanks for the bindist, I've added it to the 6.10.1 download page. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 19:51:01 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 19:42:02 2009 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.a19fd76666eb3fa85219c5f2581dc3ac@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD, Xen | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by igloo): I don't remember seeing that error recently. Can you please try grabbing http://darcs.haskell.org/ghc-HEAD-2009-01-09-ghc-corelibs- testsuite.tar.bz2 , untarring, running {{{ ./darcs-all pull -a }}} and see if you still have problems? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 20:00:07 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 19:50:56 2009 Subject: [GHC] #2809: Patching libffi fails in Solaris In-Reply-To: <041.34e879df044c407444e4cdf62cae4e54@localhost> References: <041.34e879df044c407444e4cdf62cae4e54@localhost> Message-ID: <050.6f31e4b59093878d83f3cd57738ac0c2@localhost> #2809: Patching libffi fails in Solaris ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.11 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: Duplicated by #2957. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 20 19:59:42 2009 From: trac at galois.com (GHC) Date: Tue Jan 20 19:57:42 2009 Subject: [GHC] #2957: GHC head build fails on non-GNU system assuming `patch' command is GNU patch In-Reply-To: <046.69b0f585273150506f0caa1d5b147736@localhost> References: <046.69b0f585273150506f0caa1d5b147736@localhost> Message-ID: <055.0107b32b7e82cc87c6ea8695fdf67538@localhost> #2957: GHC head build fails on non-GNU system assuming `patch' command is GNU patch -------------------------------+-------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: Also reported as #2809. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 04:05:22 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 04:02:37 2009 Subject: [GHC] #2957: GHC head build fails on non-GNU system assuming `patch' command is GNU patch In-Reply-To: <046.69b0f585273150506f0caa1d5b147736@localhost> References: <046.69b0f585273150506f0caa1d5b147736@localhost> Message-ID: <055.0843890234e3a61d4ec12780371118be@localhost> #2957: GHC head build fails on non-GNU system assuming `patch' command is GNU patch -------------------------------+-------------------------------------------- Reporter: kgardas | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by kgardas): * owner: => igloo Comment: As a fix for this bug is already attached I'm switching owner to Igloo as per recommendation on ghc wiki. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 04:51:30 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 04:42:20 2009 Subject: [GHC] #2968: add test for C trigraphs In-Reply-To: <045.2a7f68178978b83c4a4101bfbab4cf22@localhost> References: <045.2a7f68178978b83c4a4101bfbab4cf22@localhost> Message-ID: <054.48bde243729527d6594909dd73b7c630@localhost> #2968: add test for C trigraphs ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:3 igloo]: > Based on what `gcc -Wall` says, `"??)"` is a trigraph but `"?" "?)"` isn't. Yes, the GCC page above says: {{{ The nine trigraphs and their replacements are Trigraph: ??( ??) ??< ??> ??= ??/ ??' ??! ??- Replacement: [ ] { } # \ ^ | ~ }}} It's also got some hints on how to avoid them, though it also seems to indicate that they're not portable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 05:56:03 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 05:46:52 2009 Subject: [GHC] #2970: detecting readline in top-level ./configure is no guarantee of readline support Message-ID: <045.071488a2ab1aa6304b45ea4e23fd8c3b@localhost> #2970: detecting readline in top-level ./configure is no guarantee of readline support -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This is about readline in 6.8.x, but presumably the same issue applies for editline in 6.10.x. The top level `./configure` script can detect readline, but then the readline package's `./configure` script can fail to do so. Presumably this is because that `./configure` script does not get passed the `--with- readline-includes=` and `--with-readline-libraries=` flags. The top level `./configure` script does not mention anything about these flags or readline in general. Presumably the top level configure script's readline checks can work if readline happens to be in the same place as was specified for gmp with the flags `--with-gmp-includes=` and `--with-readline-libraries=`. The way in which it silently gets automatically deseletected despite the reassuring messages from the top level `./configure` is quite confusing. It might be nice if we could say that we really want a feature and have it fail if it could not comply rather than silently turning the feature off. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 08:45:20 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 08:36:11 2009 Subject: [GHC] #2945: trace history should be global or add command :mergetrace In-Reply-To: <046.a1eed06b62edc58c92c0397ae05d5c35@localhost> References: <046.a1eed06b62edc58c92c0397ae05d5c35@localhost> Message-ID: <055.8e208c55e30ad8d818ef87a2554695a8@localhost> #2945: trace history should be global or add command :mergetrace ------------------------------+--------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by phercek): * summary: trace history should not be context/resume specific but global => trace history should be global or add command :mergetrace Comment: Nobody responded on the mailing list but I realized that there may be a use case for trace history being context/resume specific. An user may suspect some fuction is buggy and may want to inspect its behavior with different input values while stopped at a breakpoint. This would polute the global history since some of the function inputs would be different from the ones used in the debugged instance. An alternative to the global history is to store off the trace history of the last nested resume context after it finished and provide a command :mergetrace which would merge the last finished trace to the current trace. This does not change anything in the current user interface (it just adds one more command) so it should be acceptable for everybody. I do not mind which way it is finaly resolved. I just want access to the trace which just finished. From my point of view, whatever is easier to do is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 09:04:47 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 08:55:36 2009 Subject: [GHC] #2803: bring full top level of a module in scope when a breakpoint is hit in the module In-Reply-To: <046.652e8c43925e61f6025ee776347b88e6@localhost> References: <046.652e8c43925e61f6025ee776347b88e6@localhost> Message-ID: <055.c7e5a62580044488d4b6c27cd31386ea@localhost> #2803: bring full top level of a module in scope when a breakpoint is hit in the module ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by phercek): Having this implemented is also very handy for user defined command for conditional breakpoints. Sometimes I find myself in need to stop based on some structure member which accessor function is not exported. In such a case, I cannot use it in the code for the conditional breakpoint. To make this work my user defined conditional breakpoint command needs one more argument to specify the module name for explicit :module commands. This sucks. I tried to find out how to get the module name automatically when stopped at a breakpoint but the only think I can get is the file name using ":show context". The problem is that the file name does not need to correspond to the module name. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 09:05:50 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 08:56:38 2009 Subject: [GHC] #2956: Template Haskell: cannot splice sections In-Reply-To: <047.28aa1e0700e775ee72d74177d9f3a1d6@localhost> References: <047.28aa1e0700e775ee72d74177d9f3a1d6@localhost> Message-ID: <056.96636c541b44606a85aa778e2154d121@localhost> #2956: Template Haskell: cannot splice sections ---------------------------------+------------------------------------------ Reporter: Deewiant | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 09:19:16 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 09:10:06 2009 Subject: [GHC] #2946: tracing should be controled by a global flag (it should not be resume context specific) In-Reply-To: <046.683eb7b4d5d0c38dcae8da9a304188ed@localhost> References: <046.683eb7b4d5d0c38dcae8da9a304188ed@localhost> Message-ID: <055.393acaada2c0cc814f1081d6d75df567@localhost> #2946: tracing should be controled by a global flag (it should not be resume context specific) ------------------------------+--------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by phercek): Actually instead of ":trace on/off" the interface should be rather ":set trace True/False". The reason is relationship of this ticket to ticket #2737. The rest stays as it is. One more advantage to this approach is that user can check whether tracing is on with ":show trace" (if it is implemented). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 09:28:57 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 09:19:47 2009 Subject: [GHC] #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function In-Reply-To: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> References: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> Message-ID: <055.e4a79c941b367025dee394676a9139ec@localhost> #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by phercek): Before implementation of this is commited it should be decided about ticket #2946 which should be either accpeted or rejected. If it is rejected nothing changes but if #2964 is accepted then user interface for this command should be a bit different. Instead of ":tracelocal " there should be a command ":set trace ". If this second alternative is implemented then an user can check what is being traced by ":show trace". Being able to check what fucntions are being traced would be handy. Then it could be also added ":unset trace " xor ":unset trace " (in case trace local locations get numbered like breakpoints are). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 09:32:34 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 09:23:24 2009 Subject: [GHC] #2810: Debugger: change context to the module containing the current breakpoint In-Reply-To: <047.b89e274abc5219595c46be09d48a0b6b@localhost> References: <047.b89e274abc5219595c46be09d48a0b6b@localhost> Message-ID: <056.ad859bc4f9c64ec7fc7c997e633c2093@localhost> #2810: Debugger: change context to the module containing the current breakpoint ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: closing as dup of #2803 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 09:49:00 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 09:39:48 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine Message-ID: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine -------------------+-------------------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: critical Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- readFile "/proc/mounts" hangs on an amd64 machine with ghc 6.10.1, it worked find in ghc 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 10:20:09 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 10:10:59 2009 Subject: [GHC] #2956: Template Haskell: cannot splice sections In-Reply-To: <047.28aa1e0700e775ee72d74177d9f3a1d6@localhost> References: <047.28aa1e0700e775ee72d74177d9f3a1d6@localhost> Message-ID: <056.d8adada077ecb61bd4460c6341e773bb@localhost> #2956: Template Haskell: cannot splice sections ---------------------------------+------------------------------------------ Reporter: Deewiant | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Template Haskell | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * type: bug => merge * milestone: => 6.10.2 Comment: Thanks for the report; fixed in the HEAD. {{{ Wed Jan 21 14:17:06 GMT 2009 Ian Lynagh * When converting TH syntax to GHC syntax, need to put sections in parentheses Fixes trac #2956 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 11:30:33 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 11:21:26 2009 Subject: [GHC] #2970: detecting readline in top-level ./configure is no guarantee of readline support In-Reply-To: <045.071488a2ab1aa6304b45ea4e23fd8c3b@localhost> References: <045.071488a2ab1aa6304b45ea4e23fd8c3b@localhost> Message-ID: <054.733da94b7790670cabffea5f25f83634@localhost> #2970: detecting readline in top-level ./configure is no guarantee of readline support ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by maeder): in ghc-6.10.1 the problem is to detect `libedit` and the future seems to be `haskeline` -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 21 23:09:55 2009 From: trac at galois.com (GHC) Date: Wed Jan 21 23:00:43 2009 Subject: [GHC] #2972: GHCi broken in GHC 6.10.1 Message-ID: <046.36c84703d6f462149fdd781bf29492ec@localhost> #2972: GHCi broken in GHC 6.10.1 --------------------+------------------------------------------------------- Reporter: cemeyer | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: powerpc --------------------+------------------------------------------------------- GHCi works in 6.8.3, broken (segfaults on startup) in 6.10.1 on linux/ppc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 22 01:20:20 2009 From: trac at galois.com (GHC) Date: Thu Jan 22 01:11:07 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.65d9c5aadddeab09e1b0f7dd64e91b34@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ----------------------+----------------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Changes (by dsf): * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 22 01:21:39 2009 From: trac at galois.com (GHC) Date: Thu Jan 22 01:12:26 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.933071e9fb2a71ea408f9df6bc154e3a@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ----------------------+----------------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Comment (by dsf): I'm guessing from the responses on the mailing list that this affects amd64 machines and not i386 (or amd64 machines running an i386 kernel.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 22 01:23:31 2009 From: trac at galois.com (GHC) Date: Thu Jan 22 01:14:16 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.0f65e092342d8482e3b311042809b95d@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ----------------------+----------------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Comment (by dsf): Here is the related thread on the mailing list: http://www.haskell.org/pipermail/haskell-cafe/2009-January/054126.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 22 09:46:52 2009 From: trac at galois.com (GHC) Date: Thu Jan 22 09:37:47 2009 Subject: [GHC] #1293: building ghc 6.8.3 hangs on sparc solaris at Language/Haskell/Syntax.hs In-Reply-To: <041.4743f2c5e5b193bbb97979ddc2558baa@localhost> References: <041.4743f2c5e5b193bbb97979ddc2558baa@localhost> Message-ID: <050.64c7f31985762637a9ff84aee88dc72e@localhost> #1293: building ghc 6.8.3 hangs on sparc solaris at Language/Haskell/Syntax.hs ----------------------------------+----------------------------------------- Reporter: mm | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: hangs compilation | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | ----------------------------------+----------------------------------------- Comment (by duncan): Note also that using gcc-4.0.x or 4.1.x instead of 4.2.x avoids the massive compile times. See [wiki:Building/Solaris]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 22 09:57:54 2009 From: trac at galois.com (GHC) Date: Thu Jan 22 09:49:18 2009 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.e3ac7d9ecc28e4564b958b8000bbaba5@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc -------------------------+-------------------------------------------------- Reporter: maeder | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Comment (by duncan): We should push Ben's patch to the 6.10 branch {{{ Mon Jan 5 04:07:58 CET 2009 Ben.Lippmeier@anu.edu.au * Don't pin a register for gc_thread on SPARC. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 22 11:48:25 2009 From: trac at galois.com (GHC) Date: Thu Jan 22 11:39:10 2009 Subject: [GHC] #2973: In ghci, loadObj fails after :cd for compiled module Message-ID: <048.b96b3ed1645cb092e866c5bc84c34419@localhost> #2973: In ghci, loadObj fails after :cd for compiled module -----------------------------+---------------------------------------------- Reporter: sanders_n | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I am using ghc 6.10.1 from MacPorts, upgraded recently from 6.8.?. To cause the bug, enter: mkdir bug && pushd bug && echo 'module Bug where number = 12' >Bug.hs && ghc -c Bug.hs && popd && ghci Inside ghci, do {{{ :cd bug :l Bug number }}} This produces: {{{ GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :cd bug Prelude> :l Bug Ok, modules loaded: Bug. Prelude Bug> number ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): loadObj: failed 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 Jan 22 12:15:29 2009 From: trac at galois.com (GHC) Date: Thu Jan 22 12:06:14 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.3d6e38c1a033878509b761f51f312798@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ----------------------+----------------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Changes (by dsf): * architecture: x86_64 (amd64) => Unknown/Multiple Comment: No, I can now confirm that this bug affects i386 as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 22 15:47:40 2009 From: trac at galois.com (GHC) Date: Thu Jan 22 15:38:27 2009 Subject: [GHC] #2934: HEAP_ALLOCED() is not thread-safe In-Reply-To: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> References: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> Message-ID: <053.21ff2c5607e89cce28ed118df1dde969@localhost> #2934: HEAP_ALLOCED() is not thread-safe ----------------------------------+----------------------------------------- Reporter: anish | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: garbage collector | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | ----------------------------------+----------------------------------------- Comment (by atze): I have the same problem on AMD64, I have written a ray tracer in parallel and with -N(2-8) (university computer, 8 cores) the program crashes every time with a segmentation fault. -g1 fixes the problem but the program ran much faster with parallel garbage collection :( Source code is available if anyone wants it for testing purposes(post request here). Please fix this, parallel garbage collection gives major speed increases! Thanks, ghc and haskell are great. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 22 17:21:21 2009 From: trac at galois.com (GHC) Date: Thu Jan 22 17:12:10 2009 Subject: [GHC] #2974: Compiling HTTP-4000.0.4 makes GHC 6.11.20090121 panic Message-ID: <048.df60a9d4937c0403c88fddaad2bd957f@localhost> #2974: Compiling HTTP-4000.0.4 makes GHC 6.11.20090121 panic ----------------------+----------------------------------------------------- Reporter: wolverian | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Compiling Network.HTTP.MD5Aux makes GHC HEAD panic: {{{ [wolverian@noesis lambdabot]$ cabal install Resolving dependencies... 'HTTP-4000.0.4' is cached. Configuring HTTP-4000.0.4... Preprocessing library HTTP-4000.0.4... Building HTTP-4000.0.4... [ 1 of 15] Compiling Network.HTTP.Utils ( Network/HTTP/Utils.hs, dist/build/Network/HTTP/Utils.o ) [ 2 of 15] Compiling Network.HTTP.MD5Aux ( Network/HTTP/MD5Aux.hs, dist/build/Network/HTTP/MD5Aux.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.11.20090121 for x86_64-unknown-linux): srtExpr \ [m{v s2Li} [lid]] -> case <=#{v} [m{v s2Li} [lid] 1] :: Alg ghc-prim:GHC.Bool.Bool{(w) tc 3c} of wild2{v s3X3} [lid] { -- lvs: [n1{v s2Lg} [lid] m{v s2Li} [lid] xs1{v s2Lk} [lid] lvl21{v s2Ln} [lid]]; rhs lvs: [n1{v s2Lg} [lid] m{v s2Li} [lid] xs1{v s2Lk} [lid] lvl21{v s2Ln} [lid]]; srt:SRT:[] ghc-prim:GHC.Bool.False{(w) d 68} -> let { sat_s3X5{v} [lid] = [m{v s2Li} [lid] xs1{v s2Lk} [lid]] \u srt:SRT:[] [] case -#{v} [m{v s2Li} [lid] 1] :: Prim ghc- prim:GHC.Prim.Int#{(w) tc 3G} of sat_s3X4{v} [lid] { -- lvs: [m{v s2Li} [lid] xs1{v s2Lk} [lid]]; rhs lvs: [xs1{v s2Lk} [lid]]; srt:SRT:[] __DEFAULT -> xs1{v s2Lk} [lid] sat_s3X4{v} [lid]; }; } in ghc-prim:GHC.Types.:{(w) d 64} [lit1{v r2vA} [gid] sat_s3X5{v} [lid]]; ghc-prim:GHC.Bool.True{(w) d 6u} -> lvl21{v s2Ln} [lid]; } 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 Jan 22 19:19:49 2009 From: trac at galois.com (GHC) Date: Thu Jan 22 19:10:36 2009 Subject: [GHC] #1377: GHCi debugger tasks In-Reply-To: <047.b3e158073b17fc81d3d320da105cad09@localhost> References: <047.b3e158073b17fc81d3d320da105cad09@localhost> Message-ID: <056.f1370cba394cd3afdf4d9b837f48cdd4@localhost> #1377: GHCi debugger tasks ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by phercek): ''* Some kind of step over or next...''[[BR]] Now I see what was meant. It can be achieved with something like '':cmd return "_result\n:step"''. Though I do not have any workaround for step out (would require dynamic stack?). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 02:16:17 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 02:07:09 2009 Subject: [GHC] #2399: Template Haskell: support for view patterns In-Reply-To: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> References: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> Message-ID: <052.d3d22cc4f82f2b7dec52b624e1122c4e@localhost> #2399: Template Haskell: support for view patterns ---------------------------------+------------------------------------------ Reporter: fons | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by porges): * version: 6.9 => 6.11 Comment: I came across this limitation also, while trying to write something to emulate Erlang's BitSyntax. Erlang allows you to write: <> = <<"A">> And then H and T are both bound to 1. Similarly: <<01000001>> == <<"A">> is true. I was hoping to be able to write a quasiquoter to do something like this: highBitSet :: Word8 ? Bool highBitSet [$bits| H:1, _:7 |] = H But this currently is not possible (AFAIK!). So, basically I'd like to put a vote in for this. Would this be a hard change to make? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 04:42:19 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 04:33:06 2009 Subject: [GHC] #2739: GHC API crashes on template haskell splices In-Reply-To: <044.3bac7d34665c04ceca674c8a12436d56@localhost> References: <044.3bac7d34665c04ceca674c8a12436d56@localhost> Message-ID: <053.ebd3e265d394f6b4503791d7800cf724@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: nominolo Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by spl): * cc: leather@cs.uu.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 07:44:01 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 07:35:29 2009 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.494568f049cbb20afd86dc2d23377600@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc -------------------------+-------------------------------------------------- Reporter: maeder | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Comment (by maeder): Wrt my binary-dist I forgot to mention that it was compiled with gcc-4.2.2, but I was able to use it with gcc-3.4.4 after removing `-fno- toplevel-reorder` from `extra-gcc-opts` Under linux and macs there are `-mno-omit-leaf-frame-pointer -fno-unit- at-a-time` in `extra-gcc-opts`. May the lack of any of these options be responsible for the long compilation times observed with gcc-4.2.x #2906? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 07:45:30 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 07:36:50 2009 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.44a30ca025c05b55d814fdcf7059c3e7@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc -------------------------+-------------------------------------------------- Reporter: maeder | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Comment (by maeder): This ticket can be closed, as the patch fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 07:54:38 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 07:45:37 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.21054100acff033f38f1a6aa13652cfa@localhost> #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols) --------------------------+------------------------------------------------- Reporter: TimBishop | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | --------------------------+------------------------------------------------- Comment (by maeder): Sorry, I noticed this ticket only recently. It looks to me that libm.so points to libm.so.1, but libm.so.2 is needed for (dynamic) linking. At least I had similar link errors with libm.so being libm.so.1. I have no idea why you could finally link in a static libm.a and still have a reference to libm.so. What version of libm does `ldd` of your binary show? -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Fri Jan 23 08:58:51 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Fri Jan 23 08:51:45 2009 Subject: seg-fault in 6.10.1 Message-ID: <20090123135851.GA19747@scico.botik.ru> Dear GHC team, I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown, run the executable, and obtain Segmentation fault. Then, I noted that in a few places the compiler warned about skipping some class member implementations in some instances. I added these implementations, and now it works correct. Are you interested in the bug report on the above part of Segmentation fault ? ----------------- Serge Mechveliani mechvel@botik.ru From trac at galois.com Fri Jan 23 11:04:03 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 10:54:46 2009 Subject: [GHC] #2975: GHCi's :edit command calls the editor with stdin in nonblocking mode Message-ID: <043.b2a303db0a166aebaa5b3af21a5ff3b8@localhost> #2975: GHCi's :edit command calls the editor with stdin in nonblocking mode -----------------------------+---------------------------------------------- Reporter: kaol | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- When using editline support, GHCi sets stdin to nonblocking mode. {{{ withReadline = bracket_ stopTimer (do startTimer; setNonBlockingFD 0 -- Two problems are being worked around here: -- 1. readline sometimes puts stdin into blocking mode, -- so we need to put it back for the IO library }}} Most editors expect that stdin is in blocking mode and nothing in the code sets the mode that way and the editor inherits the mode via {{{system}}} call in {{{editFile}}}, when using {{{:edit}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 11:26:22 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 11:17:04 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.e7944224b01842406f12ac8577f29fc4@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ----------------------+----------------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Comment (by rm): SBCL ran into this problem some time ago. It turned out the Linux kernel doesn't support standard select semantics on files in procfs and sysfs: http://bugzilla.kernel.org/show_bug.cgi?id=11014 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 11:39:54 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 11:30:37 2009 Subject: [GHC] #2976: :show bindings give wrong results when a variable was redefined Message-ID: <046.67cbe4a77482922fe0ecb159593d1d6b@localhost> #2976: :show bindings give wrong results when a variable was redefined -----------------------------+---------------------------------------------- Reporter: phercek | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Bindings displayed with '':show bindings'' do not correspond to what can be observed by printing values explicitly for example by using '':force''. The differences happen when a variable is redefined.[[BR]] I saw the bug in 6.10.1, and 6.8.2. Pepe Iborra could reproduce it in 6.8.1 and noticed that it works well in 6.6. Notice the value and type reported for variable ''test'' after it has been redefined in this example. {{{ % ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> let test = 0 Prelude> :show bindings test :: Integer = _ Prelude> :force test test = 0 Prelude> let test = "zero" Prelude> :show bindings test :: Integer = 0 Prelude> :force test test = ['z','e','r','o'] Prelude> :quit Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 11:53:09 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 11:43:52 2009 Subject: [GHC] #2976: :show bindings give wrong results when a variable was redefined In-Reply-To: <046.67cbe4a77482922fe0ecb159593d1d6b@localhost> References: <046.67cbe4a77482922fe0ecb159593d1d6b@localhost> Message-ID: <055.be90679aa124da64ddd3cfd3c1e9be72@localhost> #2976: :show bindings give wrong results when a variable was redefined ------------------------------+--------------------------------------------- Reporter: phercek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by mnislaih): * cc: mnislaih@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From Christian.Maeder at dfki.de Fri Jan 23 12:24:13 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Fri Jan 23 12:14:55 2009 Subject: seg-fault in 6.10.1 In-Reply-To: <20090123135851.GA19747@scico.botik.ru> References: <20090123135851.GA19747@scico.botik.ru> Message-ID: <4979FD3D.1060503@dfki.de> Serge D. Mechveliani wrote: > Dear GHC team, let me answer as a plain ghc user. > I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown, > run the executable, and obtain > > Segmentation fault. > > Then, I noted that in a few places the compiler warned about skipping > some class member implementations in some instances. > I added these implementations, and now it works correct. Segmentation fault should not result from missing method definitions. So please report a bug if it can be reproduced. Cheers Christian > > Are you interested in the bug report on the above part of > Segmentation fault ? > > ----------------- > Serge Mechveliani > mechvel@botik.ru From trac at galois.com Fri Jan 23 12:29:09 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 12:26:21 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.f7ec640176aaa9ed23cd022af8ca29a0@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by simonmar): The platform test in `config.guess` doesn't pass any `-m64` options to gcc, all it does is test whether `__amd64` is defined. So doesn't that mean that the C compiler on your platform is generating 64-bit objects by default? I am still confused. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 12:37:05 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 12:27:49 2009 Subject: [GHC] #2964: System.Directory.getCurrentDirectory doesn't work on win32 if the current directory has non-ascii characters in its name In-Reply-To: <044.6eaf2b0abf33443a64d1d6f7b535c905@localhost> References: <044.6eaf2b0abf33443a64d1d6f7b535c905@localhost> Message-ID: <053.9497a287f2b9d4f10ed70dd10595a53d@localhost> #2964: System.Directory.getCurrentDirectory doesn't work on win32 if the current directory has non-ascii characters in its name ------------------------------------+--------------------------------------- Reporter: kirby | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ------------------------------------+--------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: looks like the same bug as #2963 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 12:56:52 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 12:54:04 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.4bd2359bbb3b152bb76408ad46aaf84e@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by kgardas): Not at all! GCC by default generates 32bit code: {{{ karel@silence:/tmp$ cat hello.c int main() { return 0; } karel@silence:/tmp$ gcc -o hello hello.c karel@silence:/tmp$ file hello hello: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available karel@silence:/tmp$ }}} In addition this define is not defined by default, but when you use -m64 option. Then it's used. BTW: I'm also a little bit confused by the fact that when I invoke config.guess from the command-line it claims it's running on i386-pc-solaris, but if I run ./configure then it shows x86_64 -unknown-solaris... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 16:19:12 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 16:10:00 2009 Subject: [GHC] #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 In-Reply-To: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> References: <052.22581ce23675b5d58c2247a1ee1a7ede@localhost> Message-ID: <061.e81c42e35bc75ca841c470570a371ba4@localhost> #2753: GHC 6.10.1 cannot compile Crypto-4.1.0 ---------------------------------+------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by awick): * cc: awick (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 23 18:26:26 2009 From: trac at galois.com (GHC) Date: Fri Jan 23 18:17:07 2009 Subject: [GHC] #2946: tracing should be controled by a global flag (it should not be resume context specific) In-Reply-To: <046.683eb7b4d5d0c38dcae8da9a304188ed@localhost> References: <046.683eb7b4d5d0c38dcae8da9a304188ed@localhost> Message-ID: <055.e97bbd5bb917b9cdf3a28b7ed9173231@localhost> #2946: tracing should be controled by a global flag (it should not be resume context specific) ------------------------------+--------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by phercek): Current :steplocal fills in trace history with all source locations executed even when they are not inside the function stepped through using :steplocal. If this is accepted then the source locations outside the localy stepped function should not be logged to trace history if trace is not set to True. Actually I think the locations ouside the locally stepped function should not be added to the trace history even when this is rejected in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From simonpj at microsoft.com Fri Jan 23 20:15:40 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Jan 23 20:03:55 2009 Subject: seg-fault in 6.10.1 In-Reply-To: <20090123135851.GA19747@scico.botik.ru> References: <20090123135851.GA19747@scico.botik.ru> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3328733CC55@EA-EXMSG-C334.europe.corp.microsoft.com> Yes we are. If you aren't using the FFI or unsafe things, you should not get a seg fault. Do help us to reproduce it -- thanks. Simon | -----Original Message----- | From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs- | bounces@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 23 January 2009 13:59 | To: glasgow-haskell-bugs@haskell.org | Cc: glasgow-haskell-users@haskell.org | Subject: seg-fault in 6.10.1 | | Dear GHC team, | | I `make' my (large) project in ghc-6.10.1, Linux Debian, i386-unknown, | run the executable, and obtain | | Segmentation fault. | | Then, I noted that in a few places the compiler warned about skipping | some class member implementations in some instances. | I added these implementations, and now it works correct. | | Are you interested in the bug report on the above part of | Segmentation fault ? | | ----------------- | Serge Mechveliani | mechvel@botik.ru | _______________________________________________ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Sat Jan 24 14:38:47 2009 From: trac at galois.com (GHC) Date: Sat Jan 24 14:29:59 2009 Subject: [GHC] #2977: Install phase fails when using --enable-shared Message-ID: <045.994e869e093bd3112bffee0662aa176e@localhost> #2977: Install phase fails when using --enable-shared -------------------+-------------------------------------------------------- Reporter: ingmar | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- Using todays snapshot (6.11.20090123), --enable-shared fails to install because the ghc-pkg we just built can't find its shared objects when run from the build directory. The install command used is: make -j5 -l5 -j1 DESTDIR=/var/tmp/paludis/build/dev-lang- ghc-6.11.20090123/image/ install-docs install Output snippet: ------------------------------------------------------------------------ == make install -rl 5; in /var/tmp/paludis/build/dev-lang- ghc-6.11.20090123/work/ghc-6.11.20090123/libffi ------------------------------------------------------------------------ x86_64-pc-linux-gnu-gcc -E -undef -traditional -P -DINSTALLING \ -DIMPORT_DIR='"/usr/lib64/ghc-6.11.20090123/imports"' \ -DLIB_DIR='"/usr/lib64/ghc-6.11.20090123"' \ -DINCLUDE_DIR='"/usr/lib64/ghc-6.11.20090123/include"' \ -DDATA_DIR='"/usr/lib64/ghc-6.11.20090123"' \ -DHTML_DIR='"/usr/lib64/ghc-6.11.20090123/html/libraries/ffi"' \ -DHADDOCK_IFACE='"/usr/lib64/ghc-6.11.20090123/html/libraries/ffi/ffi.haddock"' \ -I../includes \ -x c -I../includes -Iinclude -DPACKAGE=ffi -DVERSION= -DPKG_LIBDIR='"/usr/lib64/ghc-6.11.20090123"' -DPKG_DATADIR='"/usr/lib64/ghc-6.11.20090123"' package.conf.in \ | grep -v '^#pragma GCC' \ | sed -e 's/""//g' -e 's/:[ ]*,/: /g' \ | /var/tmp/paludis/build/dev-lang- ghc-6.11.20090123/work/ghc-6.11.20090123/utils/ghc-pkg/dist-install/build /ghc-pkg/ghc-pkg --global-conf /var/tmp/paludis/build/dev-lang- ghc-6.11.20090123/image//usr/lib64/ghc-6.11.20090123/package.conf update - --force /var/tmp/paludis/build/dev-lang- ghc-6.11.20090123/work/ghc-6.11.20090123/utils/ghc-pkg/dist-install/build /ghc-pkg/ghc-pkg: error while loading shared libraries: libHShaskell98-1.0.1.0-ghc6.11.20090123.so: cannot open shared object file: No such file or directory make[1]: *** [install] Error 127 make: *** [install] Error 1 I'll attach a full build log -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 24 14:48:29 2009 From: trac at galois.com (GHC) Date: Sat Jan 24 14:39:39 2009 Subject: [GHC] #2977: Install phase fails when using --enable-shared In-Reply-To: <045.994e869e093bd3112bffee0662aa176e@localhost> References: <045.994e869e093bd3112bffee0662aa176e@localhost> Message-ID: <054.b44d703aa2e844e2206b1ef33022f373@localhost> #2977: Install phase fails when using --enable-shared ----------------------+----------------------------------------------------- Reporter: ingmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Comment (by ingmar): > I'll attach a full build log Too big apparently. I've put the log at http://dev.exherbo.org/~ingmar /ghc-shared-x86_64.log. Or do people prefer to have it attached, bzipped? -- Ticket URL: GHC The Glasgow Haskell Compiler From igloo at earth.li Sat Jan 24 16:09:15 2009 From: igloo at earth.li (Ian Lynagh) Date: Sat Jan 24 15:59:54 2009 Subject: seg-fault in 6.10.1 In-Reply-To: <638ABD0A29C8884A91BC5FB5C349B1C3328733CC55@EA-EXMSG-C334.europe.corp.microsoft.com> References: <20090123135851.GA19747@scico.botik.ru> <638ABD0A29C8884A91BC5FB5C349B1C3328733CC55@EA-EXMSG-C334.europe.corp.microsoft.com> Message-ID: <20090124210915.GA14076@matrix.chaos.earth.li> On Sat, Jan 24, 2009 at 01:15:40AM +0000, Simon Peyton-Jones wrote: > > | Segmentation fault. > | > | Then, I noted that in a few places the compiler warned about skipping > | some class member implementations in some instances. > | I added these implementations, and now it works correct. > > If you aren't using the FFI or unsafe things, you should not get a seg fault. It's possible it's a C stack overflow caused by cyclic default method definitions. But worth checking, anyway. Thanks Ian From trac at galois.com Sun Jan 25 03:50:13 2009 From: trac at galois.com (GHC) Date: Sun Jan 25 03:40:50 2009 Subject: [GHC] #2978: Add support for more characters to UnicodeSyntax Message-ID: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> #2978: Add support for more characters to UnicodeSyntax -----------------------------+---------------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Here is a short patch to add support for some more Unicode characters when GHC is used with the -XUnicodeSyntax extension. 1. The following are enabled when used with Arrows: * `?` (LEFTWARDS ARROW-TAIL) = `-<` * `?` (RIGHTWARDS ARROW-TAIL) = `>-` * `?` (LEFTWARDS DOUBLE ARROW-TAIL) = `-<<` * `?` (RIGHTWARDS DOUBLE ARROW-TAIL) = `>>-` 2. The star '`?`' is allowed instead of '`*`' in kind signatures. I would also like to propose a couple of changes that I have been unable to figure out how to implement myself (I tried adding them to Lexer.x but this had no effect). They all follow a similar theme: * For TemplateHaskell: `? ?` (MATHEMATICAL _ WHITE SQUARE BRACKET) can be used instead of `[| |]` * For Generics: `? ?` (_ WHITE CURLY BRACKET) can be used instead of `{| |}` * For Arrows: `? ?` (Z NOTATION _ IMAGE BRACKET) can be used instead of `(| |)` -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 25 10:53:50 2009 From: trac at galois.com (GHC) Date: Sun Jan 25 10:44:27 2009 Subject: [GHC] #2979: better support for FFI C wrappers for macros in system headers Message-ID: <045.050d142d1954d12d764c4cd94c9c38c8@localhost> #2979: better support for FFI C wrappers for macros in system headers -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Often C functions get defined via macros on some systems. For example iconv gets munged and renamed by some silly macros on OSX. This messes up the iconv binding package (and haskeline which currently directly ffi imports iconv rather than using the Haskell iconv package). Actually making wrapper functions is harder than it should be. For one thing one has to pick a single name for the wrapper function and this then prevents loading multiple versions of a Haskell package because their C symbols will clash. We have similar problems for C snippets in other packages like bytestring, so it's not constraint to FFI wrappers. We should think about how to make this easier. We should think about where the best place to put improvements eg ghc, cabal, c2hs or hsc2hs. Perhaps just a way to compile versioned C function names using a CPP define for the current package name and version. Eg in the .c file: {{{ int HS_VERSIONED_SYMBOL(foo_wrapper) (int blah) { ... } }}} And similar in the .hs file where we ffi import it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 04:28:11 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 04:25:14 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.03bac9372a5b1786c9e9c77202f53ce7@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by simonmar): So `./configure` is actually misreporting your platform, because your platform by default is really `i386-pc-solaris`. Perhaps it is picking up a different C compiler somewhere that generates 64-bit code? Try investigating which $CC is used in `config.guess` vs. when calling it via `./configure`, and also which options are passed to $CC if any. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 05:14:13 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 05:04:48 2009 Subject: [GHC] #2833: internal error: throwTo: unrecognised why_blocked value In-Reply-To: <044.241eea212892e1f7fdf89a6a715bfb1f@localhost> References: <044.241eea212892e1f7fdf89a6a715bfb1f@localhost> Message-ID: <053.a033df70631d3a66933f8986605c8218@localhost> #2833: internal error: throwTo: unrecognised why_blocked value ---------------------------------+------------------------------------------ Reporter: lilac | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Dear Lilac, Could you test whether the 10.2 branch fixes your problem? Simon M has made a bunch of fixes to `throwTo` which may well have done the job. You should be able to use a recent snapshot distribution. [http://haskell.org/ghc/download.html] It's awkward for us to test because we have to install some particular version of Reactive. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 05:19:46 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 05:10:20 2009 Subject: [GHC] #2934: HEAP_ALLOCED() is not thread-safe In-Reply-To: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> References: <044.6991112bf5bb5ad525a492692eb31d8d@localhost> Message-ID: <053.f28dcbcde20152236538c2b46d07b8d0@localhost> #2934: HEAP_ALLOCED() is not thread-safe ----------------------------------+----------------------------------------- Reporter: anish | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: garbage collector | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | ----------------------------------+----------------------------------------- Comment (by simonpj): Problem is cache of memory map. Localise? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 06:27:45 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 06:18:28 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.e160619f79a629130117bfc798e92e24@localhost> #2917: alloca and allocaArray do not respect alignment -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by guest): Trying to fix my patch to not waste memory I realized that the patch is broken. It takes a pointer from some internal malloc and adjusts it for alignment. This will not work when that pointer is later given to free. I'm not sure how to fix this. It seems we need to have the low level allocator return a pointer that is properly aligned, otherwise giving the block back to the low level free will never work. In short, I don't know how to fix this. Note that this is a real problem. Using SSE instructions on the x86 requires the vectors to be properly aligned, otherwise you get a fault. So I can't use any of the allocators for Storable in Foreign (nor Data.Array.Storable) when allocating vectors. A hack would be to have the allocator return everything 16 byte aligned, but that really is a hack. The longer term solution must take alignment into account. -- Lennart -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 08:59:22 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 08:56:22 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.73d230a787afd50e2a0834958ae3eded@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by kgardas): It seems that config.guess always is using `cc' compiler (as it is installed) otherwise it would use gcc. i.e. cc is on the first try. The issue is that current config.guess is buggy while invoked from bash. i.e. code like: {{{ if echo '\n#ifdef __amd64\nIS_64BIT_ARCH\n#endif' | \ (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ grep IS_64BIT_ARCH >/dev/null }}} should generate following C code: {{{ #ifdef __amd64 IS_64BIT_ARCH #endif }}} but if invoked in bash, then it generates this code: {{{ \n#ifdef __amd64\nIS_64BIT_ARCH\n#endif }}} which C preprocessor leaves as it is and following grep finds IS_64BIT and config.guess things it's detecting AMD64 platform correctly. So yes, if I invoke config.guess from the command line, it's run by /bin/sh and it generates correct C code and reports i386-pc-solaris2 platform. The problem is that configure seems to always run config.guess by bash and so config.guess generates bad C code and reports x86_64 platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 09:42:42 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 09:33:14 2009 Subject: [GHC] #2980: Data.Generics reports wrong package? Message-ID: <046.f7418eb0a17f24f43c739702ff117886@localhost> #2980: Data.Generics reports wrong package? --------------------+------------------------------------------------------- Reporter: Martijn | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- On a Windows XP machine, importing the Data.Generics packages gives the following confusing error message: Could not find module `Data.Generics': it is a member of package base-3.0.3.0, which is hidden After adding the package 'syb' to the dependencies, everything went fine. The documentation of Generics also states base as its package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 10:06:46 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 09:57:21 2009 Subject: [GHC] #2961: Incorrect FFI code generated with -O In-Reply-To: <047.94e145e737e8c361ae873a27f61ac99c@localhost> References: <047.94e145e737e8c361ae873a27f61ac99c@localhost> Message-ID: <056.47167653a82b2571ca697a5c6ab3389f@localhost> #2961: Incorrect FFI code generated with -O -------------------------------+-------------------------------------------- Reporter: sjanssen | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 10:28:40 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 10:19:56 2009 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.fef1eb4830b216887f94c21354890b30@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc -------------------------+-------------------------------------------------- Reporter: maeder | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Comment (by simonmar): Replying to [comment:13 maeder]: > This ticket can be closed, as the patch fixed it. The patch is really a workaround, we should find out why gcc the GC gets miscompiled when the register variable is used. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 11:07:50 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 10:58:25 2009 Subject: [GHC] #2975: GHCi's :edit command calls the editor with stdin in nonblocking mode In-Reply-To: <043.b2a303db0a166aebaa5b3af21a5ff3b8@localhost> References: <043.b2a303db0a166aebaa5b3af21a5ff3b8@localhost> Message-ID: <052.7299cc95bae23a83033ad9285644f4d0@localhost> #2975: GHCi's :edit command calls the editor with stdin in nonblocking mode ---------------------------------+------------------------------------------ Reporter: kaol | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed * milestone: => 6.10.2 Comment: Thanks for the report. This one is already fixed: {{{ Fri Nov 14 13:05:46 GMT 2008 Simon Marlow * Don't put stdin into non-blocking mode (#2778, #2777) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 11:28:56 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 11:19:31 2009 Subject: [GHC] #2471: generate C wrappers for FFI functions In-Reply-To: <047.b55a3f6edbbae1ef25207e61f546365e@localhost> References: <047.b55a3f6edbbae1ef25207e61f546365e@localhost> Message-ID: <056.123453d8cae662ca18b17c849b16e75d@localhost> #2471: generate C wrappers for FFI functions ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (FFI) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): see also #2979 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 11:32:38 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 11:23:16 2009 Subject: [GHC] #2471: generate C wrappers for FFI functions In-Reply-To: <047.b55a3f6edbbae1ef25207e61f546365e@localhost> References: <047.b55a3f6edbbae1ef25207e61f546365e@localhost> Message-ID: <056.6f72c8167ded87adff09717b3156dacd@localhost> #2471: generate C wrappers for FFI functions ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (FFI) | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: actually #2979 is a better ticket, so closing this one as a dup. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 11:33:09 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 11:23:44 2009 Subject: [GHC] #2979: better support for FFI C wrappers for macros in system headers In-Reply-To: <045.050d142d1954d12d764c4cd94c9c38c8@localhost> References: <045.050d142d1954d12d764c4cd94c9c38c8@localhost> Message-ID: <054.f73e57a0dd6ea2d06eb86859169f1b88@localhost> #2979: better support for FFI C wrappers for macros in system headers ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: see also #2471 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 11:40:30 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 11:31:05 2009 Subject: [GHC] #2961: Incorrect FFI code generated with -O In-Reply-To: <047.94e145e737e8c361ae873a27f61ac99c@localhost> References: <047.94e145e737e8c361ae873a27f61ac99c@localhost> Message-ID: <056.b28661f0a86bd7085dec428a18d425db@localhost> #2961: Incorrect FFI code generated with -O -------------------------------+-------------------------------------------- Reporter: sjanssen | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Mon Jan 26 07:02:09 PST 2009 Simon Marlow * Fix #2961: we lost some of the generated code for stack args in genCCall A real bug in the x86_64 native code gen: nice! This bug would have been caught by -Wall, and I would have gone though and Walled this file but I know Ben is hacking on this file quite heavily and I don't want to create undue conflicts. Ben: it would be nice to enable -Wall here when you have time. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 11:44:18 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 11:34:52 2009 Subject: [GHC] #2961: Incorrect FFI code generated with -O In-Reply-To: <047.94e145e737e8c361ae873a27f61ac99c@localhost> References: <047.94e145e737e8c361ae873a27f61ac99c@localhost> Message-ID: <056.6064924431413760cf23ecd3d06f6411@localhost> #2961: Incorrect FFI code generated with -O -------------------------------+-------------------------------------------- Reporter: sjanssen | Owner: simonmar Type: merge | Status: reopened Priority: normal | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: closed => reopened * type: bug => merge * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 11:44:26 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 11:35:01 2009 Subject: [GHC] #2961: Incorrect FFI code generated with -O In-Reply-To: <047.94e145e737e8c361ae873a27f61ac99c@localhost> References: <047.94e145e737e8c361ae873a27f61ac99c@localhost> Message-ID: <056.e91cb576aa89b17269fe892784e918a7@localhost> #2961: Incorrect FFI code generated with -O -------------------------------+-------------------------------------------- Reporter: sjanssen | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: reopened => new * owner: simonmar => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 12:49:31 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 12:40:05 2009 Subject: [GHC] #2981: ".space" directive not recognised by solaris assembler Message-ID: <045.06c53c97857dc8d5e429d261e87cfc23@localhost> #2981: ".space" directive not recognised by solaris assembler --------------------+------------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (NCG) Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Solaris | Architecture: sparc --------------------+------------------------------------------------------- The Solaris assembler (`/usr/ccs/bin/as`) does not recognise the `.space` directive. Presumably the GNU assembler does. {{{ /usr/ccs/bin/as: "test.s", line 484: error: unknown opcode ".space" /usr/ccs/bin/as: "test.s", line 484: error: statement syntax }}} It happens building ghc head on sparc solaris with the NCG turned on. However the pretty-printing code: `compiler/nativeGen/PprMach.hs:` {{{ pprData (CmmUninitialised bytes) = ptext (sLit ".space ") <> int bytes }}} does not look like it's in a section that is specific to sparc or solaris. So presumably the same issue applies on Solaris on x86 systems when using the system gcc and assembler rather than GNU as. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 16:04:25 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 15:55:11 2009 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.e6535629350ff8c8af04b3ede3e9212a@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value ---------------------------------+------------------------------------------ Reporter: SamB | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: patch | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by SamB): So ... whatever happened to my patch? It doesn't look like it's in yet... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 16:47:56 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 16:38:38 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.7c0b99564eb2b2b1782094ce775fd3f8@localhost> #2917: alloca and allocaArray do not respect alignment -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by guest): I'm working on a new patch that I think will work, except it relies on posix_memalign() which seems to be a rare beast. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 26 19:59:51 2009 From: trac at galois.com (GHC) Date: Mon Jan 26 19:50:23 2009 Subject: [GHC] #2980: Data.Generics reports wrong package? In-Reply-To: <046.f7418eb0a17f24f43c739702ff117886@localhost> References: <046.f7418eb0a17f24f43c739702ff117886@localhost> Message-ID: <055.717d8b55c1ed0da14c8fcc3621625166@localhost> #2980: Data.Generics reports wrong package? -------------------------------+-------------------------------------------- Reporter: Martijn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by duncan): Which documentation says base is the right package? URL? We need to fix that to say base <= 3 or syb if using base 4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 27 03:51:32 2009 From: trac at galois.com (GHC) Date: Tue Jan 27 03:48:31 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.c64e34c9f97cf45d7229d616d0b0ee8a@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by simonmar): Sigh. If we fix `config.guess` then we ought to push the patch back upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 27 04:03:14 2009 From: trac at galois.com (GHC) Date: Tue Jan 27 03:53:54 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.1c3d4bee4f40af997af49628597446c6@localhost> #2917: alloca and allocaArray do not respect alignment -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by simonmar): Yes, good point. The `allocaBytes` version is fine, btw (except that it should avoid wasting memory when alignement <= 8). `posix_memalign()` is the only way I know to allocate aligned memory from the OS. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 27 04:39:09 2009 From: trac at galois.com (GHC) Date: Tue Jan 27 04:36:03 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.6e880467d1738e5fdd2fd2939ccb486b@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by kgardas): Indeed! But the change is pretty simple and isolated to Solaris. See attach fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 27 06:43:56 2009 From: trac at galois.com (GHC) Date: Tue Jan 27 06:40:55 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.face1bfd70471538727ab287ddd9ee13@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by simonmar): Patch committed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 27 07:17:17 2009 From: trac at galois.com (GHC) Date: Tue Jan 27 07:07:47 2009 Subject: [GHC] #2973: In ghci, loadObj fails after :cd for compiled module In-Reply-To: <048.b96b3ed1645cb092e866c5bc84c34419@localhost> References: <048.b96b3ed1645cb092e866c5bc84c34419@localhost> Message-ID: <057.a3cb500dd924b0600fe3438b37cae498@localhost> #2973: In ghci, loadObj fails after :cd for compiled module ---------------------------------+------------------------------------------ Reporter: sanders_n | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 27 09:03:21 2009 From: trac at galois.com (GHC) Date: Tue Jan 27 08:53:50 2009 Subject: [GHC] #2982: GHCi crashes if a :def command gets a pattern-match error Message-ID: <046.80931cceccca77f15ec37ce09ae8c426@localhost> #2982: GHCi crashes if a :def command gets a pattern-match error -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Peter Hercek reports {{{ % ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :def err (\_->return $ concat $ replicate (read "\"1\"") "a") Prelude> :err ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): Prelude.read: no parse Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The "no parse" is quite correct: `(read "\"1\"") :: Int` should fail to parse. But it's wrong that a crashing `:def` should crash out of GHCi. Rather it should just return to the prompt, preferably with a failure message saying that running a `:def` failed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 27 18:56:02 2009 From: trac at galois.com (GHC) Date: Tue Jan 27 18:46:34 2009 Subject: [GHC] #2981: ".space" directive not recognised by solaris assembler In-Reply-To: <045.06c53c97857dc8d5e429d261e87cfc23@localhost> References: <045.06c53c97857dc8d5e429d261e87cfc23@localhost> Message-ID: <054.8b4411956f2dfd89f6f2add85f566b8b@localhost> #2981: ".space" directive not recognised by solaris assembler ----------------------------+----------------------------------------------- Reporter: duncan | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: sparc ----------------------------+----------------------------------------------- Changes (by benl): * status: new => assigned * owner: => benl Comment: I have a patch for this. We can use .skip instead, it means the same thing and is recognised by both GNU as and Solaris as. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 27 19:01:00 2009 From: trac at galois.com (GHC) Date: Tue Jan 27 18:51:31 2009 Subject: [GHC] #1501: Panic in RegisterAlloc In-Reply-To: <044.f7c3918326114c19463f5f9e9eea6707@localhost> References: <044.f7c3918326114c19463f5f9e9eea6707@localhost> Message-ID: <053.dc43bbb1c851f82d94197ded1e6b4ead@localhost> #1501: Panic in RegisterAlloc -------------------------------+-------------------------------------------- Reporter: guest | Owner: benl Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Compiler (NCG) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: cmm002 | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by benl): * status: reopened => new * owner: => benl -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 27 19:01:51 2009 From: trac at galois.com (GHC) Date: Tue Jan 27 18:52:23 2009 Subject: [GHC] #1501: Panic in RegisterAlloc In-Reply-To: <044.f7c3918326114c19463f5f9e9eea6707@localhost> References: <044.f7c3918326114c19463f5f9e9eea6707@localhost> Message-ID: <053.0227e480111bf00f8e977b98c9c8c186@localhost> #1501: Panic in RegisterAlloc -------------------------------+-------------------------------------------- Reporter: guest | Owner: benl Type: bug | Status: assigned Priority: high | Milestone: 6.12 branch Component: Compiler (NCG) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: cmm002 | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by benl): * status: new => assigned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 27 19:05:32 2009 From: trac at galois.com (GHC) Date: Tue Jan 27 18:56:13 2009 Subject: [GHC] #1015: regex001(ghci,threaded1) seg-faults under Solaris In-Reply-To: <052.533384a70abd2d45f0347c9d49345eeb@localhost> References: <052.533384a70abd2d45f0347c9d49345eeb@localhost> Message-ID: <061.7f82e5883d300cafb5752e94a89b1796@localhost> #1015: regex001(ghci,threaded1) seg-faults under Solaris ---------------------------------+------------------------------------------ Reporter: maeder@tzi.de | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by benl): * status: new => assigned * owner: => benl -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 03:19:52 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 03:10:20 2009 Subject: [GHC] #2983: Segmentation fault in ray tracer with certain options Message-ID: <052.ab008e7a26a83a06094f6364ea685223@localhost> #2983: Segmentation fault in ray tracer with certain options ----------------------------------+----------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: seg fault, ray tracer | Testcase: Os: MacOS X | Architecture: x86 ----------------------------------+----------------------------------------- The attached program, RayT.hs, when compiled like so can be executed normally: {{{ $ ghc --make -O2 -funbox-strict-fields RayT.hs [1 of 1] Compiling Main ( RayT.hs, RayT.o ) RayT.hs:7:9: Warning: No explicit method nor default method for `*' In the instance declaration for `Num Vector' RayT.hs:7:9: Warning: No explicit method nor default method for `abs' In the instance declaration for `Num Vector' RayT.hs:7:9: Warning: No explicit method nor default method for `signum' In the instance declaration for `Num Vector' Linking RayT ... $ ./RayT 9 512 > test.png $ file test.png test.png: Netpbm PGM "rawbits" image data $ }}} But when compiled with these options, it seg faults: {{{ $ ghc --make RayT.hs -O2 -fvia-C -funbox-strict-fields -optc-O3 -fexcess- precision -optc-ffast-math -funfolding-keeness-factor=10 [1 of 1] Compiling Main ( RayT.hs, RayT.o ) RayT.hs:7:9: Warning: No explicit method nor default method for `*' In the instance declaration for `Num Vector' RayT.hs:7:9: Warning: No explicit method nor default method for `abs' In the instance declaration for `Num Vector' RayT.hs:7:9: Warning: No explicit method nor default method for `signum' In the instance declaration for `Num Vector' Linking RayT ... $ ./RayT 9 512 > test.png zsh: segmentation fault ./RayT 9 512 > test.png $ gdb RayT GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries ... done (gdb) start 9 512 Breakpoint 1 at 0x521e2 Starting program: /Users/austinseipp/code/lhc/lhc- head/regress/tests/2_language/RayT 9 512 Reading symbols for shared libraries ++. done Breakpoint 1, 0x000521e2 in main () (gdb) continue Continuing. P5 512 512 255 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x00000000 0x00002fc9 in s367_info () (gdb) backtrace #0 0x00002fc9 in s367_info () #1 0x00000000 in ?? () (gdb) $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 04:19:40 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 04:10:15 2009 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.48291fa98caaad4d68124772ebd7abdf@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value ---------------------------------+------------------------------------------ Reporter: SamB | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: patch | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.10 branch => 6.12 branch Comment: Patch pushed. {{{ Tue Jan 27 00:48:25 PST 2009 Samuel Bronson * Implement #2191 (traceCcs# -- prints CCS of a value when available -- take 3) }}} we can't merge to 6.10 because this would be an API change. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 04:19:49 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 04:10:21 2009 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.d53e1bca653030290a35a16b568edcb8@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value ---------------------------------+------------------------------------------ Reporter: SamB | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 6.12 branch Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: patch | 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 Wed Jan 28 04:21:01 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 04:11:30 2009 Subject: [GHC] #2973: In ghci, loadObj fails after :cd for compiled module In-Reply-To: <048.b96b3ed1645cb092e866c5bc84c34419@localhost> References: <048.b96b3ed1645cb092e866c5bc84c34419@localhost> Message-ID: <057.32e1727a47be3806d896d1e702000d5d@localhost> #2973: In ghci, loadObj fails after :cd for compiled module ---------------------------------+------------------------------------------ Reporter: sanders_n | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Fixed: {{{ Tue Jan 27 04:16:48 PST 2009 Simon Marlow * #2973: we should virtualise the CWD inside the GHC API, not in the client }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 04:21:19 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 04:11:48 2009 Subject: [GHC] #2973: In ghci, loadObj fails after :cd for compiled module In-Reply-To: <048.b96b3ed1645cb092e866c5bc84c34419@localhost> References: <048.b96b3ed1645cb092e866c5bc84c34419@localhost> Message-ID: <057.d0fca494f4c1340a07433b7e6e18da69@localhost> #2973: In ghci, loadObj fails after :cd for compiled module ---------------------------------+------------------------------------------ Reporter: sanders_n | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 05:16:49 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 05:07:17 2009 Subject: [GHC] #2984: Vectorized dph code doesn't terminate Message-ID: <042.776c42012cc46c4d8dc7e12433e5e6d8@localhost> #2984: Vectorized dph code doesn't terminate -------------------+-------------------------------------------------------- Reporter: fre | Owner: Type: bug | Status: new Priority: normal | Component: Data Parallel Haskell Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- The program attached to this ticket doesn't terminate when vectorisation is used. It runs fine when vectorisation is not enabled. The problem seems to be the use of sumP or mapP with the empty array. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 11:13:01 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 11:03:28 2009 Subject: [GHC] #2709: System.Directory.doesDirectoryExist "\\" is False on Windows In-Reply-To: <047.62ffe3d738f377c87f772b23e67bd03b@localhost> References: <047.62ffe3d738f377c87f772b23e67bd03b@localhost> Message-ID: <056.d61cfdb83dc83d0f79434bc7cb2f667f@localhost> #2709: System.Directory.doesDirectoryExist "\\" is False on Windows ------------------------------------+--------------------------------------- Reporter: Deewiant | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 11:16:17 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 11:06:45 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.09fe8dce74749bf93668bf9feff495c0@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: low => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 11:20:38 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 11:11:05 2009 Subject: [GHC] #2827: Win32 releases lack versioned binaries In-Reply-To: <044.f4f9519bc323ffec43db3e4ff5846813@localhost> References: <044.f4f9519bc323ffec43db3e4ff5846813@localhost> Message-ID: <053.f752278fe82d9b9a99a7bf4eb5ddd6bd@localhost> #2827: Win32 releases lack versioned binaries ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 11:24:43 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 11:15:11 2009 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.d9fcddfc9236002f7ea2b0b9578e834b@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: high prio because it's nearly done, I should finish this before the release. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 11:31:17 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 11:21:52 2009 Subject: [GHC] #2897: HsFFI.h is not in the default include path for hsc2hs In-Reply-To: <042.b2d6e868e73bff261558ad2f8fec87f6@localhost> References: <042.b2d6e868e73bff261558ad2f8fec87f6@localhost> Message-ID: <051.02ddd7c189be4f0f48aa9394ac72a582@localhost> #2897: HsFFI.h is not in the default include path for hsc2hs ---------------------------------+------------------------------------------ Reporter: cjs | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: hsc2hs | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 11:38:54 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 11:29:21 2009 Subject: [GHC] #2267: Bogus "unused import" warning In-Reply-To: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> References: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> Message-ID: <055.09bb7f808d8fad738640d570c5690b29@localhost> #2267: Bogus "unused import" warning ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by snoyberg): * version: 6.8.2 => 6.10.1 Comment: Here's a small program with the bug. Hope this helps. {{{ {-# OPTIONS_GHC -fwarn-unused-imports -Werror #-} import qualified Data.ByteString as B import qualified Data.ByteString.UTF8 as BU toString :: B.ByteString -> String toString = BU.toString fromString :: String -> B.ByteString fromString = BU.fromString main :: IO () main = putStrLn $ toString $ fromString "Hello World!" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 12:43:47 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 12:34:13 2009 Subject: [GHC] #2985: Bogus superclass dictionary with equality constraints Message-ID: <046.2a07c12c429b1c153dd6d5bf785cfc60@localhost> #2985: Bogus superclass dictionary with equality constraints -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- {{{ {-# LANGUAGE TypeFamilies, UndecidableInstances #-} {-# OPTIONS -fglasgow-exts -Wnot #-} module Main where instance (Num a, Num b, a ~ b) => Num (a,b) where x * _ = x test1 = (1,1) * (2,2) main = print test1 }}} Running this program produces `<>`. Reason is that the `Num (a,b)` dictionary gets an `Eq` superclass dictionary that is essentially bottom. I'm not sure why, but it's a bad bug. See http://article.gmane.org/gmane.comp.lang.haskell.general/16796 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 17:56:54 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 17:47:22 2009 Subject: [GHC] #2986: :info printing instances often isn't wanted Message-ID: <043.cc7348275a1e64e6491d1ee94042b0a6@localhost> #2986: :info printing instances often isn't wanted -----------------------------+---------------------------------------------- Reporter: Remi | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: :info instances | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- :info shows all instances of types/classes, which often obscures the info I'm actually interested in. See the output of e.g. ":info Show" or ":info [] Maybe Int": The class and types are rather lost in between the instances. My proposal is to add an option to suppress the printing of instances. With the attached patch for 6.10.1 (although it applies to HEAD too), ":info -Show" will only print the class. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 28 23:39:48 2009 From: trac at galois.com (GHC) Date: Wed Jan 28 23:30:13 2009 Subject: [GHC] #2987: panic when compiling again Message-ID: <047.ad4a56debe0fa0023bf1923dd30e1509@localhost> #2987: panic when compiling again ---------------------+------------------------------------------------------ Reporter: dsrogers | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 ---------------------+------------------------------------------------------ haskelldb 0.10 doesn't build under ghc 6.10.1. I download it with: {{{ cabal fetch }}} Then unpack it and use the attached modified .cabal file to enable a build with: {{{ cabal build }}} It should build. Do a {{{ cabal install }}} It will then attempt to rebuild, but will fail with the error: {{{ [18 of 25] Compiling Database.HaskellDB.Database ( src/Database/HaskellDB/Database.hs, dist/build/Database/HaskellDB/Database.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): idInfo r{tv adJo} [tv] }}} However, if you clean and then install it will succeed {{{ cabal clean cabal install }}} ghc 6.10.1 doesn't like something about the intermediate files left over from the cabal build step. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 29 06:50:11 2009 From: trac at galois.com (GHC) Date: Thu Jan 29 06:40:35 2009 Subject: [GHC] #2988: Improve float-in Message-ID: <046.83e28bfdd70de8fbe4dfb2a2f0f105d9@localhost> #2988: Improve float-in -------------------------------------------+-------------------------------- Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------------+-------------------------------- At the moment we can get a cascade of simplifier iterations like this: {{{ let x1 = blah x2 = x1 : [] x3 = 1 : x2 x4 = 2 : x3 in case blah of True -> f x4 False -> g x4 }}} Then `x4` satisfies the conditions for `postInlineUnconditionally` (not top-level, used once in each case branch, not inside lambda). So it's inlined. In the next iteration of the simplifier, `x3` satisfies the conditions, and so on. It might be better for `postUnconditionally` to require an interesting context. But then this case doesn't work so well: {{{ let x = blah in case foo of { A -> ..x..; B -> ..x..; C -> ..no x.. } }}} If C is the hot branch, it's a good idea to push `x` into the A,B branches. But perhaps this question is one that `FloatIn` should deal with, not `postInlineUnconditionally`. Indeed `FloatIn` has the following comment: {{{ -- For case expressions we duplicate the binding if it is -- reasonably small, and if it is not used in all the RHSs -- This is good for situations like -- let x = I# y in -- case e of -- C -> error x -- D -> error x -- E -> ...not mentioning x... }}} So this ticket is just to record the idea: * Make `postInlineUnconditionally` check for interesting context ...and check on performance changes, and whether `FloatIn` is doing the Right Thing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 29 08:37:08 2009 From: trac at galois.com (GHC) Date: Thu Jan 29 08:27:34 2009 Subject: [GHC] #2987: panic when compiling again In-Reply-To: <047.ad4a56debe0fa0023bf1923dd30e1509@localhost> References: <047.ad4a56debe0fa0023bf1923dd30e1509@localhost> Message-ID: <056.6a48160bca441fa5271bbad4c4a35f80@localhost> #2987: panic when compiling again -------------------------+-------------------------------------------------- Reporter: dsrogers | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: That's bad. I can't make it happen, though, on Linux. Can anyone else? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 29 10:18:05 2009 From: trac at galois.com (GHC) Date: Thu Jan 29 10:08:33 2009 Subject: [GHC] #2974: Compiling HTTP-4000.0.4 makes GHC 6.11.20090121 panic In-Reply-To: <048.df60a9d4937c0403c88fddaad2bd957f@localhost> References: <048.df60a9d4937c0403c88fddaad2bd957f@localhost> Message-ID: <057.c67a83941603b2141b30cd8e4527ab63@localhost> #2974: Compiling HTTP-4000.0.4 makes GHC 6.11.20090121 panic -------------------------------+-------------------------------------------- Reporter: wolverian | 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 for finding this. I've fixed it now: {{{ Thu Jan 29 05:19:54 PST 2009 simonpj@microsoft.com * Two more wibbles to CorePrep (fixes HTTP package and DPH) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 29 13:02:31 2009 From: trac at galois.com (GHC) Date: Thu Jan 29 12:52:57 2009 Subject: [GHC] #2986: :info printing instances often isn't wanted In-Reply-To: <043.cc7348275a1e64e6491d1ee94042b0a6@localhost> References: <043.cc7348275a1e64e6491d1ee94042b0a6@localhost> Message-ID: <052.47cc1d523a4646c1ded499d02cdbd110@localhost> #2986: :info printing instances often isn't wanted ---------------------------------+------------------------------------------ Reporter: Remi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: :info instances | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * cc: glasgow-haskell-users@haskell.org (added) * difficulty: => Unknown Comment: The goal of being able to ask (in GHCi) about a class without seeing all its instances seems to be a good one. But what about syntax? Is Remi's proposed UI the right one? He suggests: {{{ :info Show -- See class definition and instances :info -Show -- See class definition only }}} But an alternative could be: {{{ :info Show -- See class definition only :instances Show -- See instances of Show :instances Bool -- See instances of Bool }}} That'd give upward room to grow. For example, one might want {{{ :instances Show (Tree _) -- See instances of form (Show (Tree ...)) }}} Maybe there are other alternatives. So for me the user interface is the issue. If we can evolve a consensus I'm sure it won't be hard to implement. Would anyone like to volunteer to drive the debate? With that in mind I'm trying the experiment of adding ghc-users to the cc- list. Debate on the list, record proposals, and pros/cons on this ticket. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 29 15:16:52 2009 From: trac at galois.com (GHC) Date: Thu Jan 29 15:07:15 2009 Subject: [GHC] #2987: panic when compiling again In-Reply-To: <047.ad4a56debe0fa0023bf1923dd30e1509@localhost> References: <047.ad4a56debe0fa0023bf1923dd30e1509@localhost> Message-ID: <056.0f512c6158ca200de423f3c94eb98409@localhost> #2987: panic when compiling again ---------------------------------+------------------------------------------ Reporter: dsrogers | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by Deewiant): * os: MacOS X => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: Reproduced on x86-64 Linux, GHC 6.10.1: {{{ [18 of 25] Compiling Database.HaskellDB.Database ( src/Database/HaskellDB/Database.hs, dist/build/Database/HaskellDB/Database.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-linux): idInfo r{tv adgM} [tv] }}} Exact steps followed: {{{ $ cabal fetch haskelldb $ cd ~/.cabal/packages/hackage.haskell.org/haskelldb/0.10 $ tar xf haskelldb-0.10.tar.gz $ cd haskelldb-0.10 $ wget 'http://hackage.haskell.org/trac/ghc/attachment/ticket/2987/haskelldb.cabal?format=raw' $ mv 'haskelldb.cabal?format=raw' haskelldb.cabal $ cabal configure; cabal build; cabal install }}} And yes, doing a `cabal clean` makes it work again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 29 17:24:14 2009 From: trac at galois.com (GHC) Date: Thu Jan 29 17:14:38 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.70240b6ebfb3755e95ca03d3734237ad@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ----------------------+----------------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Comment (by duncan): The question is why did it work in 6.8 and not work now in 6.10? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 29 22:55:51 2009 From: trac at galois.com (GHC) Date: Thu Jan 29 22:46:20 2009 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.ea0bcd18ec8026d7e91254b0f8770aa5@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -------------------------------+-------------------------------------------- Reporter: tim | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by japple): * version: 6.9 => 6.10.1 * architecture: x86 => x86_64 (amd64) Comment: ctrl- does not work. #2741 lists a hacky solution for delete. Is there a solution for the rest of they key bindings? ghci-haskeline makes no visible difference in the behavior. $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> should move one word back;5D $ uname -a Linux XXXXXXX 2.6.23.17-88.fc7 #1 SMP Thu May 15 00:02:29 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux $ stty -a speed 38400 baud; rows 24; columns 136; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke Prelude> System.IO.hIsTerminalDevice System.IO.stdin True Prelude> System.IO.hIsTerminalDevice System.IO.stdout True Prelude> System.Environment.getEnv "TERM" "xterm" $ ls -lh /usr/lib/libedit.* lrwxrwxrwx 1 root root 17 2009-01-29 19:15 /usr/lib/libedit.so -> libedit.so.0.0.26 lrwxrwxrwx 1 root root 17 2009-01-29 16:56 /usr/lib/libedit.so.0 -> libedit.so.0.0.26 -rwxr-xr-x 1 root root 149K 2007-11-04 04:31 /usr/lib/libedit.so.0.0.26 $ ls -lh /usr/lib64/libedit.* lrwxrwxrwx 1 root root 17 2009-01-29 19:15 /usr/lib64/libedit.so -> libedit.so.0.0.26 lrwxrwxrwx 1 root root 17 2009-01-29 16:55 /usr/lib64/libedit.so.0 -> libedit.so.0.0.26 -rwxr-xr-x 1 root root 167K 2007-11-04 04:28 /usr/lib64/libedit.so.0.0.26 ghci performs fine in emacs The C program does not recognize ctrl+ :browse System.Console.Editline.Readline and ghci history work fine -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 29 22:59:35 2009 From: trac at galois.com (GHC) Date: Thu Jan 29 22:50:03 2009 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.4548dac49c07d53bce7ccac24235e574@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -------------------------------+-------------------------------------------- Reporter: tim | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by japple): * status: closed => reopened * resolution: invalid => Comment: (Sorry, meant to his "preview") ctrl- does not work. #2741 lists a hacky solution for delete. Is there a solution for the rest of the usual key bindings? ghci-haskeline makes no visible difference in the wonky behavior. {{{ $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> should move one word back;5D }}} {{{ $ uname -a Linux XXXXXXX 2.6.23.17-88.fc7 #1 SMP Thu May 15 00:02:29 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux }}} {{{ $ stty -a speed 38400 baud; rows 24; columns 136; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke }}} {{{ Prelude> System.IO.hIsTerminalDevice System.IO.stdin True Prelude> System.IO.hIsTerminalDevice System.IO.stdout True Prelude> System.Environment.getEnv "TERM" "xterm" }}} {{{ $ ls -lh /usr/lib/libedit.* lrwxrwxrwx 1 root root 17 2009-01-29 19:15 /usr/lib/libedit.so -> libedit.so.0.0.26 lrwxrwxrwx 1 root root 17 2009-01-29 16:56 /usr/lib/libedit.so.0 -> libedit.so.0.0.26 -rwxr-xr-x 1 root root 149K 2007-11-04 04:31 /usr/lib/libedit.so.0.0.26 $ ls -lh /usr/lib64/libedit.* lrwxrwxrwx 1 root root 17 2009-01-29 19:15 /usr/lib64/libedit.so -> libedit.so.0.0.26 lrwxrwxrwx 1 root root 17 2009-01-29 16:55 /usr/lib64/libedit.so.0 -> libedit.so.0.0.26 -rwxr-xr-x 1 root root 167K 2007-11-04 04:28 /usr/lib64/libedit.so.0.0.26 }}} ghci performs fine in emacs The C program does not recognize ctrl+ :browse System.Console.Editline.Readline and ghci history work fine -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 00:18:35 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 00:08:57 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.9359e8d5239200e7191be6783fe01715@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ----------------------+----------------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Comment (by dsf): Replying to [comment:6 duncan]: > The question is why did it work in 6.8 and not work now in 6.10? If you try reading it using a ByteString function in 6.8 you will get a similar failure. I suspect that that code has moved into the regular IO module. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 00:22:09 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 00:12:43 2009 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.973edeb44a5d3ac24faf6292f9613ad3@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -------------------------------+-------------------------------------------- Reporter: tim | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by judah): Let me address each of those problems separately: 1) Ctrl- doesn't work Both editline and haskeline have ways to be told about ctrl-. For ghci-haskeline, instructions to add ctrl- are at: http://trac.haskell.org/haskeline/wiki/CustomKeyBindings For the standard ghci with editline, you should add the following to your .editrc file: {{{ bind "\e[1;5D" vi-prev-word bind "\e[1;5C" vi-next-word }}} where the key sequence might need to be replaced depending on your terminal. 2) The delete key doesn't work I agree that the delete behavior in editline is problematic; there's no really satisfying fix short of improving or replacing that library. But *should* work in ghci-haskeline. If it doesn't, can you please do the following: - Type {{{ghc -e getLine}}}, press `delete` and then `return` to see the control sequence for the `delete` key. - Type {{{infocmp}}} and paste the line with the kdch1 entry. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 01:04:50 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 00:55:17 2009 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.468ec46262ec03131dcc1a8f52c446d2@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -------------------------------+-------------------------------------------- Reporter: tim | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by japple): I was looking at a bad copy of ghci-haskeline. Delete does work in it. The "-e getLine" trick and the two listed shortcuts fixed my other issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 02:34:30 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 02:24:51 2009 Subject: [GHC] #2989: ByteString causes C stack overflow in generated code Message-ID: <045.e817821e697fd12e025d388665fba1f4@localhost> #2989: ByteString causes C stack overflow in generated code --------------------+------------------------------------------------------- Reporter: Olathe | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- I accidentally left off the apostrophe in the following code. {{{ cData = L.copy cData' }}} That's how I found out that 'fix copy' causes Haskell programs to die. {{{ import Data.ByteString.Lazy import Control.Monad.Fix main = print (fix copy) }}} {{{ >ghc file.hs >main C stack overflow in generated code >ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> Control.Monad.Fix.fix Data.ByteString.copy Loading package bytestring-0.9.1.4 ... linking ... done. " >ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> Control.Monad.Fix.fix Data.ByteString.Lazy.copy Loading package bytestring-0.9.1.4 ... linking ... done. > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 07:10:52 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 07:01:47 2009 Subject: [GHC] #2933: LDFLAGS ignored by build system In-Reply-To: <045.854117476da424db3736910ffba011f0@localhost> References: <045.854117476da424db3736910ffba011f0@localhost> Message-ID: <054.66f86715923a08f9a31e6acc6a23c49e@localhost> #2933: LDFLAGS ignored by build system ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ingmar): * cc: ingmar@exherbo.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 08:37:09 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 08:27:31 2009 Subject: [GHC] #2973: In ghci, loadObj fails after :cd for compiled module In-Reply-To: <048.b96b3ed1645cb092e866c5bc84c34419@localhost> References: <048.b96b3ed1645cb092e866c5bc84c34419@localhost> Message-ID: <057.711b9c5ffef0fd4f850a0fdaadb7987f@localhost> #2973: In ghci, loadObj fails after :cd for compiled module ---------------------------------+------------------------------------------ Reporter: sanders_n | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | 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: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 08:37:18 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 08:27:37 2009 Subject: [GHC] #2956: Template Haskell: cannot splice sections In-Reply-To: <047.28aa1e0700e775ee72d74177d9f3a1d6@localhost> References: <047.28aa1e0700e775ee72d74177d9f3a1d6@localhost> Message-ID: <056.2273cd5a4267f81a859815f9c4a52d3a@localhost> #2956: Template Haskell: cannot splice sections ---------------------------------+------------------------------------------ Reporter: Deewiant | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Template Haskell | 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: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 09:32:21 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 09:22:41 2009 Subject: [GHC] #2723: Unnecessary warning for record wildcards In-Reply-To: <044.5ab60ea4e40213824e6aecfc247bc68c@localhost> References: <044.5ab60ea4e40213824e6aecfc247bc68c@localhost> Message-ID: <053.6b7e459ea4d2cb4062a97d0074211d82@localhost> #2723: Unnecessary warning for record wildcards -----------------------------------------+---------------------------------- Reporter: judah | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rename/should_fail/T2723 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by igloo): Revisited this as it was depended on by the fix for #2914. Turns out that we just needed to also pull {{{ Tue Oct 28 07:46:39 GMT 2008 simonpj@microsoft.com * Remove dead code }}} So now this fix is merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 09:32:31 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 09:22:55 2009 Subject: [GHC] #2914: RecordWildCards doesn't work with associated datatypes inside class instances In-Reply-To: <045.003431a2c8a375b9d493daaeb2179785@localhost> References: <045.003431a2c8a375b9d493daaeb2179785@localhost> Message-ID: <054.cdea659e191c7a4ec3c22d518d57731d@localhost> #2914: RecordWildCards doesn't work with associated datatypes inside class instances ---------------------------------------------+------------------------------ Reporter: ganesh | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rename/should_compiler/T2914 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 09:55:48 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 09:46:08 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.c06058e3dc941fb2c31e4a544020e6bf@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ----------------------+----------------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Comment (by rm): I think I've tracked this down to libraries/base/GHC/Handle.hs. In order to fix #2363, calls to fdReady were added before every IO operation between 6.8.3 and 6.10.1. For real files, this works fine. For the special not-really-files files in /proc and /sys it can fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 10:37:22 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 10:27:41 2009 Subject: [GHC] #2985: Bogus superclass dictionary with equality constraints In-Reply-To: <046.2a07c12c429b1c153dd6d5bf785cfc60@localhost> References: <046.2a07c12c429b1c153dd6d5bf785cfc60@localhost> Message-ID: <055.fec8c5acc75abfbf30ec9c4a3d5a2c32@localhost> #2985: Bogus superclass dictionary with equality constraints -----------------------------------------------+---------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: indexed-types/should_run/T2985 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------+---------------------------- Changes (by simonpj): * testcase: => indexed-types/should_run/T2985 * owner: => igloo * type: bug => merge Comment: Excellent bug. Fixed by {{{ Fri Jan 30 07:27:38 PST 2009 simonpj@microsoft.com * Fix Trac #2985: generating superclasses and recursive dictionaries The Note [Recursive instances and superclases] explains the subtle issues to do with generating the bindings for superclasses when we compile an instance declaration, at least if we want to do the clever "recursive superclass" idea from the SYB3 paper. The old implementation of tcSimplifySuperClasses stumbled when type equalities entered the picture (details in the Note); this patch fixes the problem using a slightly hacky trick. When we re-engineer the constraint solver we'll want to keep an eye on this. Probably worth merging to the 6.10 branch. }}} Worth merging. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 10:46:36 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 10:37:15 2009 Subject: [GHC] #2399: Template Haskell: support for view patterns In-Reply-To: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> References: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> Message-ID: <052.a9a7251678cc30b4136a1c0911df934a@localhost> #2399: Template Haskell: support for view patterns ---------------------------------+------------------------------------------ Reporter: fons | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): What is the "change" that you advocate? The one that this ticket started with, namely adding view patterns to TH? I have not looked into it in detail, but I don't think it's hard. As usual for TH, it means * Design the TH syntax data types * Write code in GHC to convert between TH and HsSyn No rocket science. The trouble is that these TH extensions never get to the top of my priority list! But nagging is good... that ups the priority. I also always hope that someone else will to the work and send a patch! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 11:44:12 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 11:34:31 2009 Subject: [GHC] #2937: source file that compiled fine fails to recompile after touching it (yes, another one) In-Reply-To: <047.dbb1a127d7dcdc429c0bd3cde852bbdb@localhost> References: <047.dbb1a127d7dcdc429c0bd3cde852bbdb@localhost> Message-ID: <056.397e187d62a2182c14cc2459f08e198d@localhost> #2937: source file that compiled fine fails to recompile after touching it (yes, another one) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tc245 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * testcase: => tc245 * owner: igloo => simonpj * type: merge => bug * milestone: => 6.10.2 Comment: I've made a test `tc245`, but this still fails in the 6.10 branch before it gets to the second GHC invocation: {{{ [1 of 2] Compiling Tc245_A ( Tc245_A.hs, Tc245_A.o ) [2 of 2] Compiling Tc245 ( tc245.hs, tc245.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1.20090128 for x86_64-unknown-linux): Maybe.fromJust: Nothing Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Simon, do you know what's going on here? Is there another patch I should merge, or is this something that's not expected to work in 6.10? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 11:58:41 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 11:49:01 2009 Subject: [GHC] #2937: source file that compiled fine fails to recompile after touching it (yes, another one) In-Reply-To: <047.dbb1a127d7dcdc429c0bd3cde852bbdb@localhost> References: <047.dbb1a127d7dcdc429c0bd3cde852bbdb@localhost> Message-ID: <056.4fcc5d484d8eb08c8f0b267801912a00@localhost> #2937: source file that compiled fine fails to recompile after touching it (yes, another one) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tc245 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Ah. Its seems that * this `fromJust` failure is an example of #2417; * which is marked as a dup of #1968 * which was fixed in the HEAD but not 6.10 GHC 6.10 doesn't support GADTs in associated types, which this test uses. It is a still a bug that 6.10 crashes under such circumstances. Do we care enough? If 6.10 is long-lived, perhaps we do. So pls create a ticket for the absence of a decent error message and we can do a 6.10 only patch. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 13:41:42 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 13:32:02 2009 Subject: [GHC] #2960: Add instance Data.Traversable for Data.IntMap In-Reply-To: <047.ad713d40a6f1b4b691c2eb21a7e2047b@localhost> References: <047.ad713d40a6f1b4b691c2eb21a7e2047b@localhost> Message-ID: <056.2d6fd529942597e589967fc7a4fc5054@localhost> #2960: Add instance Data.Traversable for Data.IntMap -------------------------------+-------------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by Deewiant): Discussion's over, archive at http://www.haskell.org/pipermail/libraries/2009-January/011171.html Summary: Ross Paterson voted in agreement, otherwise silence. We have consensus! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 13:48:38 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 13:39:00 2009 Subject: [GHC] #2961: Incorrect FFI code generated with -O In-Reply-To: <047.94e145e737e8c361ae873a27f61ac99c@localhost> References: <047.94e145e737e8c361ae873a27f61ac99c@localhost> Message-ID: <056.9cee51b9640085d0f76278d57084a54d@localhost> #2961: Incorrect FFI code generated with -O -------------------------------+-------------------------------------------- Reporter: sjanssen | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler (FFI) | 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: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 13:49:19 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 13:39:39 2009 Subject: [GHC] #2944: Mutually recursive equality constraints In-Reply-To: <060.51642b5b9daf07feaf7d5262417a8b88@localhost> References: <060.51642b5b9daf07feaf7d5262417a8b88@localhost> Message-ID: <069.77c859278db0184fa79d88941b53befe@localhost> #2944: Mutually recursive equality constraints ---------------------------------------------------+------------------------ Reporter: MartijnVanSteenbergen | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: indexed-types/should_compile/T2944 | Os: MacOS X Architecture: x86 | ---------------------------------------------------+------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 14:15:08 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 14:05:29 2009 Subject: [GHC] #2985: Bogus superclass dictionary with equality constraints In-Reply-To: <046.2a07c12c429b1c153dd6d5bf785cfc60@localhost> References: <046.2a07c12c429b1c153dd6d5bf785cfc60@localhost> Message-ID: <055.bdd6b1b80a95050caa37b6186f211940@localhost> #2985: Bogus superclass dictionary with equality constraints -----------------------------------------------+---------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: indexed-types/should_run/T2985 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------+---------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 14:36:50 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 14:27:12 2009 Subject: [GHC] #2944: Mutually recursive equality constraints In-Reply-To: <060.51642b5b9daf07feaf7d5262417a8b88@localhost> References: <060.51642b5b9daf07feaf7d5262417a8b88@localhost> Message-ID: <069.0c13b1cd6acd45ac496803983ae30832@localhost> #2944: Mutually recursive equality constraints ---------------------------------------------------+------------------------ Reporter: MartijnVanSteenbergen | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: indexed-types/should_compile/T2944 | Os: MacOS X Architecture: x86 | ---------------------------------------------------+------------------------ Comment (by MartijnVanSteenbergen): Thanks. =) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 14:52:01 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 14:42:21 2009 Subject: [GHC] #2990: "GHC Commentary: The byte-code interpreter and dynamic linker " is empty Message-ID: <043.129af6995c79ba29401862c98a48b859@localhost> #2990: "GHC Commentary: The byte-code interpreter and dynamic linker " is empty -----------------------------+---------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- There is no content on the wiki page [wiki:Commentary/Rts/Interpreter]! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 15:21:26 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 15:11:46 2009 Subject: [GHC] #2991: .mix files generation broken with -fhpc and --make flags with lhs modules Message-ID: <045.fbdf830be4083dc434ba708ecd719a55@localhost> #2991: .mix files generation broken with -fhpc and --make flags with lhs modules -----------------------------+---------------------------------------------- Reporter: ppavel | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: hpc make lhs | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- assume the project consisting of two files: !Main.lhs and !MyModule.hs. Main.lhs imports !MyModule via standard import. Build the project with ghc --make -fhpc -o main Main.lhs The generated .mix file contains relevant information and hpc markup correctly shows the coverage for !MyModule. Now rename !MyModule.hs to !MyModule.lhs and enclose the code there in \begin{code} / \end{code}. Build again. The compilation still succeeds and the executable works fine. But !MyModule.mix now seems wrong and no hpc coverage information is available for !MyModule -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 19:36:22 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 19:26:41 2009 Subject: [GHC] #2989: ByteString causes C stack overflow in generated code In-Reply-To: <045.e817821e697fd12e025d388665fba1f4@localhost> References: <045.e817821e697fd12e025d388665fba1f4@localhost> Message-ID: <054.dcab5564481ff3958a88789ea2baef09@localhost> #2989: ByteString causes C stack overflow in generated code ----------------------+----------------------------------------------------- Reporter: Olathe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Comment (by dons): Can you explain why this is a bug? Loks like the expected behaviour to me... ? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 30 22:04:17 2009 From: trac at galois.com (GHC) Date: Fri Jan 30 21:54:37 2009 Subject: [GHC] #2588: Missed suggestion with context on foralls In-Reply-To: <051.f82176fc0c07b1750e90df780f097cc7@localhost> References: <051.f82176fc0c07b1750e90df780f097cc7@localhost> Message-ID: <060.cac3eab8d13c9440238e007bb307678e@localhost> #2588: Missed suggestion with context on foralls ---------------------------------+------------------------------------------ Reporter: NeilMitchell | 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 SamB): Why not just warn whenever {{{forall}}} is parsed as a type variable? It's a very odd name for a type variable anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 00:57:55 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 00:55:22 2009 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.e62568f15a268bf3ef3ca32a1b0f87c3@localhost> #1346: bootstrap from HC files ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by bogner): * cc: mail@justinbogner.com (added) Comment: Replying to [ticket:1346 simonmar]: > There's some work to do on 6.8 to ensure that we can still bootstrap from HC files. This will be slightly harder due to the new Cabal-based build system for libraries, and the solution will probably involve 'setup makefile' somewhere. Also we'll need to update the building guide to include the new instructions, whatever they may be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 01:42:48 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 01:33:06 2009 Subject: [GHC] #2992: GHCi Memory Leak in Windows Vista Message-ID: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> #2992: GHCi Memory Leak in Windows Vista --------------------+------------------------------------------------------- Reporter: Andir | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- If use ghci.exe and separating compiling via ghc.exe, memory leak in ghci occurred. After exhausting available memory Vista has no any respond. Steps for reproduce: 1) Run GHCi: process list has 2 processes: ghci.exe (a), ghc.exe (b), 2) Run separated compilation process 20 times: Command Line: for /L %i in (1,1,20) do ghc -fforce-recomp -O --make "problem.hs" -o "problem.exe" Sample Haskell Program listing (problem.hs): main :: IO () main = do print $ [x | x <- [1..]] putStrLn "Hello, world!" 3) In process list (taskmgr.exe) you can see processor activity and increased value of "Memory (Private Working Set)" for process (b). 4) As run result "Memory (Private Working Set)" increased about 100Mb. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 01:59:06 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 01:49:25 2009 Subject: [GHC] #2992: GHCi Memory Leak in Windows Vista In-Reply-To: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> References: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> Message-ID: <053.09857f209cc262111c7fa04a02cc5205@localhost> #2992: GHCi Memory Leak in Windows Vista ---------------------+------------------------------------------------------ Reporter: Andir | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------+------------------------------------------------------ Comment (by Andir): Reproduced by other users via haskell-cafe: http://www.haskell.org/pipermail/haskell-cafe/2009-January/054035.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 09:18:51 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 09:09:12 2009 Subject: [GHC] #2992: GHCi Memory Leak in Windows Vista In-Reply-To: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> References: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> Message-ID: <053.cb8157169fbe696bab50933e8774109c@localhost> #2992: GHCi Memory Leak in Windows Vista ---------------------+------------------------------------------------------ Reporter: Andir | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------+------------------------------------------------------ Changes (by Tonal): * cc: tonal.promsoft@gmail.ru (added) Comment: It leak reproduce without real file "problem.hs".[br] Need only start ghci and run command line: {{{ for /L %i in (1,1,20) do ghc -fforce-recomp -O --make problem.hs -o problem.exe }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 15:16:35 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 15:08:19 2009 Subject: [GHC] #2993: Precedence errors are reported for undefined operators Message-ID: <045.dc49aabd93adad128f189ed9b9b23308@localhost> #2993: Precedence errors are reported for undefined operators -----------------------------+---------------------------------------------- Reporter: Olathe | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I found a misleading error message. If I add the import for (<$>), but I forget to save the file {{{ -- other imports -- import Control.Applicative ((<$>)) main = print $ (+1).(+2) <$> Just 5 }}} I get the error {{{ precedence parsing error cannot mix `(.)' [infixr 9] and `(<$>)' [infixl 9] in the same infix expression }}} which is rather hard to debug, since it makes it seem that the problem is either with Control.Applicative's precedence definitions or that I've somehow imported (<$>) with a different precedence from somewhere else. It would be nice if it would report instead that (<$>) wasn't defined yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 15:30:17 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 15:20:34 2009 Subject: [GHC] #2994: give better error messages for instance declarations with the wrong number of parameters Message-ID: <047.7c1f3570de5b9324f1c6d8cab58ffeb9@localhost> #2994: give better error messages for instance declarations with the wrong number of parameters -----------------------------+---------------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Consider the following erroneous program which tries to define an instance of `MonadReader`. {{{ import Control.Monad.Reader newtype Reader' r a = Reader' (r -> a) instance MonadReader (Reader' r) }}} This instance declaration is wrong, because the `MonadReader` type class has two parameters. But ghc's error message is not very helpful: {{{ /tmp/err.hs:5:21: `Reader' r' is not applied to enough type arguments Expected kind `*', but `Reader' r' has kind `* -> *' In the instance declaration for `MonadReader (Reader' r)' }}} While if I give too many arguments, e.g., `instance MonadReader r r (Reader' r)`, I always get a good error message, even if the kinds of some of the leading types are wrong: {{{ Kind error: `MonadReader' is applied to too many type arguments In the instance declaration for `MonadReader r r (Reader' r)' }}} So it'd be great if the error message for giving too few type arguments could be more like that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 15:45:18 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 15:35:34 2009 Subject: [GHC] #2993: Precedence errors are reported for undefined operators In-Reply-To: <045.dc49aabd93adad128f189ed9b9b23308@localhost> References: <045.dc49aabd93adad128f189ed9b9b23308@localhost> Message-ID: <054.8bb852cfc9f775dafaf0e75e917f260b@localhost> #2993: Precedence errors are reported for undefined operators ------------------------------+--------------------------------------------- Reporter: Olathe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by Olathe): It appears that (<$>) being undefined is reported in a later error message. I usually fix the first error reported, then move on to others, so it would be nice if it reported that it left out the precedence error for undefined operators entirely. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 16:47:38 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 16:39:18 2009 Subject: [GHC] #2986: :info printing instances often isn't wanted In-Reply-To: <043.cc7348275a1e64e6491d1ee94042b0a6@localhost> References: <043.cc7348275a1e64e6491d1ee94042b0a6@localhost> Message-ID: <052.11ea2582dcbc404c19b1cc328ab2df62@localhost> #2986: :info printing instances often isn't wanted ---------------------------------+------------------------------------------ Reporter: Remi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: :info instances | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by Remi): I don't particularly care for what UI is used exactly, adding a flag to :info seemed simply the easiest way to solve the issue for me. So splitting the thing into :info and :instances is perfectly fine with me, except that they share a common prefix, and I rather like being able to just type {{{ :i Show }}} The other thing is that I can imagine more complicated ways of searching for instances would perhaps better be done by e.g. hoogle. (hoogle+ghci- integration or something.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 17:13:05 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 17:04:21 2009 Subject: [GHC] #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions In-Reply-To: <047.1bde2d0a50f92799bbadb2d6cc5101e0@localhost> References: <047.1bde2d0a50f92799bbadb2d6cc5101e0@localhost> Message-ID: <056.a6ae946e10b8e1f817e2dce29089541c@localhost> #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions ---------------------------------+------------------------------------------ Reporter: shelarcy | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report. I've updated the docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 17:13:14 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 17:04:27 2009 Subject: [GHC] #2819: Bad example code in documentation of Control.Exception.catch In-Reply-To: <043.8ffe86f1c4d9c257331fb2a6c7fabfed@localhost> References: <043.8ffe86f1c4d9c257331fb2a6c7fabfed@localhost> Message-ID: <052.3f56e4e95e4df15c948c4fa75532ac7b@localhost> #2819: Bad example code in documentation of Control.Exception.catch ---------------------------------+------------------------------------------ Reporter: mafo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report. I've updated the docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 17:13:46 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 17:04:47 2009 Subject: [GHC] #2939: Example in library doco for Control.Exception.handle is no longer supported in GHC 6.10 In-Reply-To: <041.e04e0170350b212eed6fdb779e4b100d@localhost> References: <041.e04e0170350b212eed6fdb779e4b100d@localhost> Message-ID: <050.da3b05277025f85321bd06f47778211b@localhost> #2939: Example in library doco for Control.Exception.handle is no longer supported in GHC 6.10 ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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 * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. I've updated the docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 18:08:34 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 17:59:33 2009 Subject: [GHC] #2692: ghc-6.10.0.20081007 seg faults on Sparc In-Reply-To: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> References: <045.b06b0ab2c1c887d4319783181d70d6f9@localhost> Message-ID: <054.028a75236228f0389920fdfccde50ca7@localhost> #2692: ghc-6.10.0.20081007 seg faults on Sparc -------------------------+-------------------------------------------------- Reporter: maeder | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Comment (by igloo): Replying to [comment:11 duncan]: > We should push Ben's patch to the 6.10 branch > {{{ > Mon Jan 5 04:07:58 CET 2009 Ben.Lippmeier@anu.edu.au > * Don't pin a register for gc_thread on SPARC. > }}} Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 31 18:23:12 2009 From: trac at galois.com (GHC) Date: Sat Jan 31 18:13:29 2009 Subject: [GHC] #2960: Add instance Data.Traversable for Data.IntMap In-Reply-To: <047.ad713d40a6f1b4b691c2eb21a7e2047b@localhost> References: <047.ad713d40a6f1b4b691c2eb21a7e2047b@localhost> Message-ID: <056.233386a554775e910e5ed8e6533b9566@localhost> #2960: Add instance Data.Traversable for Data.IntMap ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler