From trac at galois.com Tue Jul 1 02:11:04 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 02:02:17 2008 Subject: [GHC] #2399: Template Haskell: support for view patterns In-Reply-To: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> References: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> Message-ID: <052.92ff29a41683f9e94e29c8283b077aac@localhost> #2399: Template Haskell: support for view patterns ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by AudreyTang): Simon, it's difficult to add a guard there, because a QuasiQuoter accepts the pattern-generation function of the form: {{{ quoteExprPat :: String -> TH.PatQ }}} But in TH, Guard is part of Body, so a quasiquoter designated to the PatQ side cannot affect the BodyQ side. As there seems to be no other Pat constructors that's useful for a [$rx|...|] at the pattern side, would you consider accepting a patch that adds ViewP for 6.10? Cheers, Audrey (The context for [$rx|...|] is http://hackage.haskell.org/cgi-bin/hackage- scripts/package/regexqq btw.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 02:11:17 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 02:02:29 2008 Subject: [GHC] #2399: Template Haskell: support for view patterns In-Reply-To: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> References: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> Message-ID: <052.0edc688b89c97652c0c0c0aa781ae7d0@localhost> #2399: Template Haskell: support for view patterns ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by AudreyTang): * cc: audreyt@audreyt.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 04:10:34 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 04:01:52 2008 Subject: [GHC] #2355: Building NDP fails with GHC panic on x86_64 In-Reply-To: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> References: <045.b11d6fc22a2344e33956c4877e3aa5f7@localhost> Message-ID: <054.5e0719adca76c08a41b34ac9fef3718a@localhost> #2355: Building NDP fails with GHC panic on x86_64 ---------------------------+------------------------------------------------ Reporter: Nolari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: fixed Keywords: ndp ghc panic | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------------+------------------------------------------------ Changes (by rl): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 04:54:15 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 04:45:39 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.9d20c783abc86fb542847971e1b7336c@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Changes (by maeder): * status: closed => reopened * version: 6.6 => 6.8.3 * resolution: fixed => * summary: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) => more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) Comment: Rerunning the above example using ghc-6.8.3 the object file ATC2.o has now 3.5 MB instead of 1.3 MB for ghc-6.8.2 {{{ maeder@leibniz:/local/maeder/atc> ls -sh1 total 13M 308K ATC.hi 88K ATC.hs 1.3M ATC.o 144K ATC2.hi 16K ATC2.hs 16K ATC2.hs~ 3.5M ATC2.o 7.1M ATC3 8.0K ATC3.hi 4.0K ATC3.hs 4.0K ATC3.o 4.0K Common 4.0K Makefile 4.0K Makefile~ 12K atc.2.tgz 4.0K programatica }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 06:52:52 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 06:44:06 2008 Subject: [GHC] #2399: Template Haskell: support for view patterns In-Reply-To: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> References: <043.ea0fa95d3ba4304244b4038504ec46d3@localhost> Message-ID: <052.c760e469ab6f97b5a69a5bb726dcc86c@localhost> #2399: Template Haskell: support for view patterns ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by simonpj): Ah I see. I'd missed the quasiquoter connnection. One way to fix this would be to add view patterns to TH. But it made me wonder: why aren't pattern guards compositional? At the moment they are resolutely top-level. And, as you say, not part of patterns. But syntax aside it would make perfect sense to make them part of a pattern: {{{ pat ::= var | C pat1 ... patn | pat|quals }}} where `qual` is a pattern-guard "qualifier". So (again, syntax aside) you could write {{{ f (x | x>3) = ... g ([y] | Just z <- lookup y) = ... }}} That would push pattern guards into the syntax of patterns. Now view patterns are syntactic sugar: {{{ (exp -> pat) means (x | pat <- exp x) where x is fresh }}} The reverse encoding is also possible {{{ (pat | quals) means (f -> Just (v1,...,vn)) where (v1,...,vn) are the variables bound by pat f pat | quals = Just vs }}} I'm not sure I'm advocating this (yet!), but I hadn't thought of it before so I thought I'd jot it down. If TH users agree about just how to beef up patterns, I'm not against adding it. I'm just a bit conscious that view patterns are experimental and the more concrete we pour the harder it becomes to change. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 07:55:16 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 07:46:38 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.c78d18e882b8ede3b637aba214894720@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: 6.8.3 => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 08:27:35 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 08:18:46 2008 Subject: [GHC] #2378: panic: lookupVers1, when standalone deriving Typeable and Data In-Reply-To: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> References: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> Message-ID: <053.032f661232b1c24763c698eeba4b00d2@localhost> #2378: panic: lookupVers1, when standalone deriving Typeable and Data ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by simonpj): Nice program. You revealed at least three bugs in the implementation of standalone deriving, and that's without counting the `lookupVers1` problem, which doesn't show up in HEAD. So I've fixed all of them in the HEAD. Since we've pushed 6.8.3 out now, we've missed the boat on that. If we ever release 6.8.4 we should put the patch in: {{{ Tue Jul 1 13:09:08 BST 2008 simonpj@microsoft.com * Several fixes to 'deriving' including Trac #2378 }}} There's no good workaround for 6.8.3 except not to use standalone deriving. Also doing this: {{{ newtype T f = ... deriving( Typeable1 ) }}} seems unfixably broken in 6.8.3 I'm afraid. I think you may have to use a data type instead. Thanks for bringing all this to light. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 08:36:19 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 08:27:29 2008 Subject: [GHC] #2378: panic: lookupVers1, when standalone deriving Typeable and Data In-Reply-To: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> References: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> Message-ID: <053.0563ecd14850e899882db6c0b7247091@localhost> #2378: panic: lookupVers1, when standalone deriving Typeable and Data -------------------------------------------+-------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_compile/T2378 | Architecture: x86 Os: MacOS X | -------------------------------------------+-------------------------------- Changes (by simonpj): * testcase: => deriving/should_compile/T2378 * owner: simonpj => igloo * type: bug => merge Comment: Added a test for the newtype deriving thing. I was wrong above: the thing that is broken is standalone deriving for `Typeable1` of newtype: {{{ newtype T a = ... deriving instance Typeable1 T }}} Also reclassifying as 'merge' so that Ian can keep it on his merge list for 6.8.4 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 09:52:08 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 09:43:21 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.c79495b005ec4735516c2f46c577fac6@localhost> #2307: Poor warning for conflicting functional dependencies --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report! Here is a minimal testcase: {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, OverlappingInstances, UndecidableInstances, IncoherentInstances, FlexibleInstances #-} module Foo where class C a b c | a -> b, a -> c instance C Int (Maybe String) Float instance C Int (Maybe Bool) Double }}} With the HEAD: {{{ Proof_default.hs:8:0: Functional dependencies conflict between instance declarations: instance [incoherent] C Int (Maybe String) Float -- Defined at Proof_default.hs:8:0-34 instance [incoherent] C Int (Maybe Bool) Double -- Defined at Proof_default.hs:9:0-35 instance [incoherent] C Int (Maybe Bool) Double -- Defined at Proof_default.hs:9:0-35 }}} Before just nubbing the instances, we should make sure that it's not a bug that it is finding the same one multiple times in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 11:27:57 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 11:19:06 2008 Subject: [GHC] #2409: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined Message-ID: <044.7dae041a5daf9b581d3da7c20ea58977@localhost> #2409: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- This module: {{{ module Foo where f :: Int -> Int f _ | () `seq` False = undefined | otherwise = error "XXX" g :: Int -> Int g _ | () `seq` False = undefined | otherwise = error "XXX" }}} doesn't compile with 6.8.3 or the HEAD; here's what happens with the HEAD (compiled with -DDEBUG, but I'm pretty sure it wouldn't work anyway): {{{ $ ghc -fforce-recomp -c Foo.hs ghc-6.9.20080701: panic! (the 'impossible' happened) (GHC version 6.9.20080701 for x86_64-unknown-linux): ASSERT failed! file stgSyn/CoreToStg.lhs line 922 (){v 71} [lid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ ghc -fforce-recomp -c Foo.hs -O /tmp/ghc4665_0/ghc4665_0.s: Assembler messages: /tmp/ghc4665_0/ghc4665_0.s:95:0: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined }}} The original problem report, using Takusen, is here: http://www.haskell.org/pipermail/glasgow-haskell- users/2008-June/015037.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:27:58 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:19:13 2008 Subject: [GHC] #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto-all' Message-ID: <045.6d20356736e6fa3c22e35dd97141b722@localhost> #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto- all' -----------------------+---------------------------------------------------- Reporter: pgavin | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- Specifically, the failure happens while compiling libraries/base/Data/Complex.hs: ------ compiler output -------- /Users/pgavin/local/ghc-6.9/src/ghc-6.9/compiler/stage1/ghc-inplace -package-name base-3.0 -hide-all-packages -split-objs -i -idist/build -i. -idist/build/autogen -Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package ghc-prim-0.1 -package integer-0.1 -package rts-1.0 -O -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XPatternSignatures -XStandaloneDeriving -XPatternGuards -XCPP -idist/build -prof -caf-all -auto-all -hisuf p_hi -hcsuf p_hc -osuf p_o -H32m -O -H32m -O2 -O2 -Rghc-timing -XGenerics -O2 -Wall -fno-warn- deprecated-flags -w -c Data/Complex.hs -o dist/build/Data/Complex.p_o -ohi dist/build/Data/Complex.p_hi /var/folders/o2/o2fca1ekG9SKEu61XaHsjE+++TI/-Tmp-/ghc51695_0/ghc51695_0.split__108.s:1256:0: FATAL:Symbol _base_DataziComplex_zeze_CAF_cc_ccs already defined. ------------------------------- Compilation succeeds if the SPECIALIZE pragmas are removed from the instance declarations for Num, Fractional, and Floating. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:36:14 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:27:24 2008 Subject: [GHC] #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 In-Reply-To: <053.ab23f29da9729b185efbfb211d6ff539@localhost> References: <053.ab23f29da9729b185efbfb211d6ff539@localhost> Message-ID: <062.ffdbcf99f88f656d3ae17cc42989f40c@localhost> #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt/equal | Architecture: Unknown Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * os: MacOS X => Multiple * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:37:02 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:28:11 2008 Subject: [GHC] #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 In-Reply-To: <053.ab23f29da9729b185efbfb211d6ff539@localhost> References: <053.ab23f29da9729b185efbfb211d6ff539@localhost> Message-ID: <062.f880df31e9df46e7cae2e43cf1f9eabf@localhost> #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt/equal | Architecture: Unknown Os: Multiple | ----------------------------+----------------------------------------------- Comment (by igloo): This is reproducible with `./validate --slow`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:37:05 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:28:15 2008 Subject: [GHC] #2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669 In-Reply-To: <053.ce70667c924b83874db7013d3e3aa9b8@localhost> References: <053.ce70667c924b83874db7013d3e3aa9b8@localhost> Message-ID: <062.ff01fc93c752926d6e3131002d13b8b2@localhost> #2368: ASSERT failed! file coreSyn/CorePrep.lhs line 669 -----------------------------------------------+---------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: simplCore/should_compile/simpl014 | Architecture: Unknown Os: MacOS X | -----------------------------------------------+---------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: This is reproducible with `./validate --slow`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:37:48 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:28:57 2008 Subject: [GHC] #2367: ASSERT failed! file basicTypes/MkId.lhs line 643 In-Reply-To: <053.3399b2ac3a6fdeb953db1e5f9a9f109a@localhost> References: <053.3399b2ac3a6fdeb953db1e5f9a9f109a@localhost> Message-ID: <062.d43d0b623ccdddfa7597d81d16fe9412@localhost> #2367: ASSERT failed! file basicTypes/MkId.lhs line 643 ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt/records | Architecture: Unknown Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: I can't reproduce this with `./validate --slow`; did someone fix it? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 12:42:12 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:33:21 2008 Subject: [GHC] #2409: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined In-Reply-To: <044.7dae041a5daf9b581d3da7c20ea58977@localhost> References: <044.7dae041a5daf9b581d3da7c20ea58977@localhost> Message-ID: <053.d5593285190a1d46806cdca1fbad813c@localhost> #2409: Error: symbol `ghczmprim_GHCziUnit_Z0T_closure' is already defined ------------------------------------------+--------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deSugar/should_compile/T2409 | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by simonpj): * testcase: => deSugar/should_compile/T2409 * status: new => closed * resolution: => fixed Comment: Urgle. That's my fault. Fixed by {{{ Tue Jul 1 17:37:22 BST 2008 simonpj@microsoft.com * Easy fix for Trac #2409 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 13:00:09 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 12:51:24 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.1050106d655fd650acef08d023c10b77@localhost> #2307: Poor warning for conflicting functional dependencies -----------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2307 | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T2307 * status: new => closed * resolution: => fixed Comment: Excellent, thanks for refining the test case. That made it easy. In fact, nubbing is the right thing, because `FunDeps.badFunDeps` looks through the fundeps one by one; in this case there are two, and the same instance conflicts with both. Fixed by {{{ Tue Jul 1 17:58:30 BST 2008 simonpj@microsoft.com * Fix Trac #2307: need to nub bad fundep reports }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 13:51:35 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 13:42:44 2008 Subject: [GHC] #2376: GHC.Word: shiftR and shiftL are not marked as inline. In-Reply-To: <044.1d775a18fce526f6afc014f2bd5a4272@localhost> References: <044.1d775a18fce526f6afc014f2bd5a4272@localhost> Message-ID: <053.59cf79a7196dd7d98bce89f421e50c1a@localhost> #2376: GHC.Word: shiftR and shiftL are not marked as inline. ----------------------------------+----------------------------------------- Reporter: mjark | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: inline shiftR shiftL | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 13:53:23 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 13:44:34 2008 Subject: [GHC] #2373: Build fails to pass locations of external tools to libraries In-Reply-To: <042.251f9ace7edb49f0e772cf590973862b@localhost> References: <042.251f9ace7edb49f0e772cf590973862b@localhost> Message-ID: <051.f137deb63afc37e75e2324a22350118f@localhost> #2373: Build fails to pass locations of external tools to libraries ----------------------+----------------------------------------------------- Reporter: bos | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 Comment: Agreed; thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 14:05:20 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 13:56:29 2008 Subject: [GHC] #2369: tcrun007: Can't find interface-file declaration for variable .... In-Reply-To: <053.4d3797d81d5c149bb343005d923746dd@localhost> References: <053.4d3797d81d5c149bb343005d923746dd@localhost> Message-ID: <062.6db05407f34e49017a80aea689e535dd@localhost> #2369: tcrun007: Can't find interface-file declaration for variable .... ---------------------------------------------+------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: typechecker/should_run/tcrun007 | Architecture: Unknown Os: Unknown | ---------------------------------------------+------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: That's expected; the devel2 build settings don't build the libraries with `-XGenerics`, which this test relies upon. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:04:18 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 14:55:30 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.bf39eed87f001e8268a40cb4ff6ebb4a@localhost> #2307: Poor warning for conflicting functional dependencies -----------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2307 | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Changes (by igloo): * status: closed => reopened * resolution: fixed => * milestone: 6.10 branch => 6.10.1 Comment: The behaviour when the types in the instances were changed felt a little odd to me, so I had a quick look at the code, and I think it's broken; e.g. this module: {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, OverlappingInstances, UndecidableInstances, IncoherentInstances, FlexibleInstances #-} module Foo where class C a b c | b -> c instance C Bool Int Float instance C Char Int Double }}} is accepted by GHC, but violates `b -> c`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:25:59 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:17:28 2008 Subject: [GHC] #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. Message-ID: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. ------------------------+--------------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- x86_64 6.9 build from June 15. I can't distill it down to a single simple testcase, but the backtrace is very informative: ASSERTION FAILED: file RaiseAsync.c, line 1015 The assertion in question is "ASSERT(stmGetEnclosingTRec(tso->trec) == NO_TREC)". This assertion is only called when we hit an ATOMICALLY_FRAME with stop_at_atomically activated. We only do that when Schedule.c is running the garbage collector and raises an exception to retry an invalid stm transaction. I don't follow enough here to offer a real patch, but obviously there is a false assumption that the transaction we're trying to retry does not have an enclosing trec. Why this may be the case is somewhat beyond me. I'm doing various things with unsafeIOToSTM, so I think the answer may be that there is some sort of forking going on with threaded IO which means that threads may have enclosing trecs. {{{ #0 0x00002b134fdb9b45 in raise () from /lib64/libc.so.6 #1 0x00002b134fdbb0e0 in abort () from /lib64/libc.so.6 #2 0x00000000009b40e0 in rtsFatalInternalErrorFn (s=0xa2c670 "ASSERTION FAILED: file %s, line %u\n", ap=0x41000e50) at RtsMessages.c:164 #3 0x00000000009b3ca4 in barf (s=0xa2c670 "ASSERTION FAILED: file %s, line %u\n") at RtsMessages.c:40 #4 0x00000000009b3cfe in _assertFail (filename=0xa3200c "RaiseAsync.c", linenum=1015) at RtsMessages.c:55 #5 0x00000000009e4675 in raiseAsync (cap=0xd734a0, tso=0x2b1351bdb000, exception=0x0, stop_at_atomically=rtsTrue, stop_here=0x0) at RaiseAsync.c:1015 #6 0x00000000009e365b in throwToSingleThreaded_ (cap=0xd734a0, tso=0x2b1351bdb000, exception=0x0, ---Type to continue, or q to quit--- stop_at_atomically=rtsTrue, stop_here=0x0) at RaiseAsync.c:73 #7 0x00000000009b6b51 in scheduleDoGC (cap=0xd734a0, task=0xd8e750, force_major=rtsFalse) at Schedule.c:2046 #8 0x00000000009b5a9d in schedule (initialCapability=0xd734a0, task=0xd8e750) at Schedule.c:718 #9 0x00000000009b77db in workerStart (task=0xd8e750) at Schedule.c:2537 #10 0x00002b134fb73020 in start_thread () from /lib64/libpthread.so.0 #11 0x00002b134fe4df8d in clone () from /lib64/libc.so.6 #12 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:48:04 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:39:15 2008 Subject: [GHC] #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) In-Reply-To: <045.86b9b930b3ded50e36018e43dce2d355@localhost> References: <045.86b9b930b3ded50e36018e43dce2d355@localhost> Message-ID: <054.b106f09132f33302f1783a5136e7f61d@localhost> #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => low * milestone: => 6.10.1 Old description: > [ 7 of 78] Compiling Data.Array.Parallel.Base.Rebox ( > Data/Array/Parallel/Base/Rebox.hs, > dist/build/Data/Array/Parallel/Base/Rebox.o ) > ghc-6.9.20080614: panic! (the 'impossible' happened) > (GHC version 6.9.20080614 for i386-apple-darwin): > initC: srt_lbl > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > < samples), 11M in use, 0.00 INIT (0.00 elapsed), 0.17 MUT (1.05 elapsed), > 0.08 GC (0.09 elapsed) :ghc>> New description: {{{ [ 7 of 78] Compiling Data.Array.Parallel.Base.Rebox ( Data/Array/Parallel/Base/Rebox.hs, dist/build/Data/Array/Parallel/Base/Rebox.o ) ghc-6.9.20080614: panic! (the 'impossible' happened) (GHC version 6.9.20080614 for i386-apple-darwin): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> }}} Comment: And if it is still broken for you, can you please attach the source code you were trying to compile and tell us what the commandline was? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:49:29 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:40:45 2008 Subject: [GHC] #2380: Adjustor.o crash compiling ghc 6.8.3 on iBook G4 10.4.11 In-Reply-To: <045.f144b092f23e8db9c081050578f2b103@localhost> References: <045.f144b092f23e8db9c081050578f2b103@localhost> Message-ID: <054.67ae7513de97f367e976fb1b0cb6606e@localhost> #2380: Adjustor.o crash compiling ghc 6.8.3 on iBook G4 10.4.11 --------------------------+------------------------------------------------- Reporter: povman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:50:43 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:42:04 2008 Subject: [GHC] #2383: hsc2hs puts -F on call to ghc In-Reply-To: <045.232f26bacbe72f9746a671f222e80879@localhost> References: <045.232f26bacbe72f9746a671f222e80879@localhost> Message-ID: <054.ea2ab8613d8689f75b1c644a967c2212@localhost> #2383: hsc2hs puts -F on call to ghc ---------------------+------------------------------------------------------ Reporter: povman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: hsc2hs | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ---------------------+------------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:54:30 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:45:39 2008 Subject: [GHC] #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable In-Reply-To: <053.8442170ef9b4829325987986f707598b@localhost> References: <053.8442170ef9b4829325987986f707598b@localhost> Message-ID: <062.6292f1ce06dec8ae136d74bfab59f3eb@localhost> #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: MacOS X | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:57:31 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:48:41 2008 Subject: [GHC] #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version In-Reply-To: <045.bc3bbec7f28e57f84d533f6eb759f26c@localhost> References: <045.bc3bbec7f28e57f84d533f6eb759f26c@localhost> Message-ID: <054.376500dd3d6f41acf24dd84542032a80@localhost> #2349: SIZET_FMT in includes/mkDerivedConstants.c needs to be "d" under older Solaris version ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 15:58:10 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 15:49:23 2008 Subject: [GHC] #2383: hsc2hs puts -F on call to ghc In-Reply-To: <045.232f26bacbe72f9746a671f222e80879@localhost> References: <045.232f26bacbe72f9746a671f222e80879@localhost> Message-ID: <054.5d32eec9537201c97dba4fd3514baa03@localhost> #2383: hsc2hs puts -F on call to ghc ---------------------+------------------------------------------------------ Reporter: povman | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: hsc2hs | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ---------------------+------------------------------------------------------ Changes (by ross): * status: new => closed * resolution: => invalid Comment: As Christian has said, this was never in the mainline. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 16:13:59 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 16:05:30 2008 Subject: [GHC] #2352: POSIX.1 unsetenv returns int In-Reply-To: <043.9a1a67d0fcfde818f197866387595049@localhost> References: <043.9a1a67d0fcfde818f197866387595049@localhost> Message-ID: <052.7008a86509e98fb780eb71e19c7bb0a7@localhost> #2352: POSIX.1 unsetenv returns int ----------------------------+----------------------------------------------- Reporter: donn | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/unix | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: NetBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 Old description: > While plenty of C libraries declare void unsetenv(), the POSIX.1003.1 > standard is int unsetenv(), with return values 0 or -1. In the latter > case, errno is set to EINVAL, for causes including the present of "=" in > the value. Of course this is not of earthshaking importance. > > The following is the autoconf test (just a copy of the same test for > usleep().) > > --- libraries/unix/configure.ac.dist 2008-06-03 10:39:45.000000000 > -0700 > +++ libraries/unix/configure.ac 2008-06-06 21:43:19.000000000 -0700 > @@ -75,6 +75,19 @@ > ;; > esac > > +### POSIX.1003.1 unsetenv returns 0 or -1 (EINVAL), but older > implementations > +### in common use return void. > +AC_CACHE_CHECK([return type of unsetenv], cv_func_unsetenv_return_type, > + [AC_EGREP_HEADER(changequote(<, >) ]+unsetenv>changequote([, ]), > + /usr/include/stdlib.h, > + [cv_func_unsetenv_return_type=void], > + [cv_func_unsetenv_return_type=int])]) > +case "$cv_func_unsetenv_return_type" in > + "void" ) > + AC_DEFINE([UNSETENV_RETURNS_VOID], [1], [Define if stdlib.h declares > unsetenv to return void.]) > + ;; > +esac > + > dnl ** sometimes RTLD_NEXT is hidden in #ifdefs we really don't wan to > set > AC_MSG_CHECKING(for RTLD_NEXT from dlfcn.h) > AC_EGREP_CPP(yes, New description: While plenty of C libraries declare void unsetenv(), the POSIX.1003.1 standard is int unsetenv(), with return values 0 or -1. In the latter case, errno is set to EINVAL, for causes including the present of "=" in the value. Of course this is not of earthshaking importance. The following is the autoconf test (just a copy of the same test for usleep().) {{{ --- libraries/unix/configure.ac.dist 2008-06-03 10:39:45.000000000 -0700 +++ libraries/unix/configure.ac 2008-06-06 21:43:19.000000000 -0700 @@ -75,6 +75,19 @@ ;; esac +### POSIX.1003.1 unsetenv returns 0 or -1 (EINVAL), but older implementations +### in common use return void. +AC_CACHE_CHECK([return type of unsetenv], cv_func_unsetenv_return_type, + [AC_EGREP_HEADER(changequote(<, >)changequote([, ]), + /usr/include/stdlib.h, + [cv_func_unsetenv_return_type=void], + [cv_func_unsetenv_return_type=int])]) +case "$cv_func_unsetenv_return_type" in + "void" ) + AC_DEFINE([UNSETENV_RETURNS_VOID], [1], [Define if stdlib.h declares unsetenv to return void.]) + ;; +esac + dnl ** sometimes RTLD_NEXT is hidden in #ifdefs we really don't wan to set AC_MSG_CHECKING(for RTLD_NEXT from dlfcn.h) AC_EGREP_CPP(yes, }}} Comment: Thanks for the patch, we'll take a look -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 16:14:38 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 16:05:56 2008 Subject: [GHC] #2353: GHC inliner doesn't In-Reply-To: <044.0a130fadcfff13182791f64ebade3181@localhost> References: <044.0a130fadcfff13182791f64ebade3181@localhost> Message-ID: <053.50c46d8ccae6195b38747c2392e3b48a@localhost> #2353: GHC inliner doesn't ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 16:18:28 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 16:09:44 2008 Subject: [GHC] #2354: NOINLINE pragma ignored In-Reply-To: <044.82d464aa2a8db887c5d15527893ee9e8@localhost> References: <044.82d464aa2a8db887c5d15527893ee9e8@localhost> Message-ID: <053.a6d8c91b562065fed22ae8688e8a6c23@localhost> #2354: NOINLINE pragma ignored ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 16:19:39 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 16:10:56 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.6c0b058e853b2e1e9bc987a5009fb999@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From dons at galois.com Tue Jul 1 17:09:04 2008 From: dons at galois.com (Don Stewart) Date: Tue Jul 1 17:00:14 2008 Subject: Missing symbol when loading cbits in ghci Message-ID: <20080701210904.GF8817@liouville.galois.com> Anyone seen this? $ ghci A.hs Prelude Main> main : /home/dons/.cabal/lib/download-0.3/ghc-6.8.2/HSdownload-0.3.o: unknown symbol `stat64' ghc-6.8.2: unable to load package `download-0.3' I can compile and link code against HSdownload just fine, but loading in ghci fails with state64 undefined (a kernel symbol). To reproduce: $ cabal update $ cabal install download $ ghci Prelude> :m + Network.Download Prelude Network.Download> openURI "http://haskell.org" : /home/dons/.cabal/lib/download-0.3/ghc-6.8.2/HSdownload-0.3.o: unknown symbol `stat64' ghc-6.8.2: unable to load package `download-0.3' Is this something that ghci should know about on linux? Or can anyone think of another reason why ghci can't see stat64? -- Don From trac at galois.com Tue Jul 1 20:05:22 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 19:56:32 2008 Subject: [GHC] #2402: ghc fails sans error message. In-Reply-To: <046.ec9278b09c51ceec22610f63a11d7929@localhost> References: <046.ec9278b09c51ceec22610f63a11d7929@localhost> Message-ID: <055.02251f8935f193ed579f9c079728e429@localhost> #2402: ghc fails sans error message. ----------------------+----------------------------------------------------- Reporter: lpsmith | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 20:19:23 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 20:10:42 2008 Subject: [GHC] #2401: unsafeIOToSTM hangs with 64 bit multicore. In-Reply-To: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> References: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> Message-ID: <052.8a93a93e36c5648fa298d3e087a1dc94@localhost> #2401: unsafeIOToSTM hangs with 64 bit multicore. ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the report; I don't /think/ that the `unsafeIOToSTM` should be to blame, although I'm not too familiar with STM. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 20:33:08 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 20:24:21 2008 Subject: [GHC] #2398: segfault in cmpLocks on 64 bit multicore In-Reply-To: <043.83483373a348f7384863a195a6f7e5cf@localhost> References: <043.83483373a348f7384863a195a6f7e5cf@localhost> Message-ID: <052.9c955f9d368937452bb244a9680221e1@localhost> #2398: segfault in cmpLocks on 64 bit multicore ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * priority: normal => low * difficulty: => Unknown * milestone: => 6.10.1 Comment: I can't reproduce this using the first 351k of my exim `spec.txt` as the file contents, compiling with GHC 6.8.3: {{{ ghc -fforce-recomp --make q -O -threaded }}} and running with just {{{ ./q }}} or {{{ ./q +RTS -N3 }}} on an amd64/Linux machine. I do get a load of {{{ q: foo/984: openFile: resource exhausted (Too many open files) }}} but that is to be expected. It would be useful if you could attach a text file that triggers the problem for you, and give details of how you are compiling and running the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 21:21:18 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 21:12:35 2008 Subject: [GHC] #2358: Template Haskell's TupleT considers unary tuples as a valid types. In-Reply-To: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> References: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> Message-ID: <052.2ce4ca1ba97292420a62f17dbf30fa63@localhost> #2358: Template Haskell's TupleT considers unary tuples as a valid types. ------------------------------+--------------------------------------------- Reporter: fons | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_1tuple | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 1 21:21:37 2008 From: trac at galois.com (GHC) Date: Tue Jul 1 21:12:49 2008 Subject: [GHC] #2378: panic: lookupVers1, when standalone deriving Typeable and Data In-Reply-To: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> References: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> Message-ID: <053.891c8f974d5a39813575b6ca52093ee9@localhost> #2378: panic: lookupVers1, when standalone deriving Typeable and Data -------------------------------------------+-------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_compile/T2378 | Architecture: x86 Os: MacOS X | -------------------------------------------+-------------------------------- Changes (by igloo): * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 01:06:35 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 00:57:46 2008 Subject: [GHC] #2398: segfault in cmpLocks on 64 bit multicore In-Reply-To: <043.83483373a348f7384863a195a6f7e5cf@localhost> References: <043.83483373a348f7384863a195a6f7e5cf@localhost> Message-ID: <052.936e9cd04727a71537d79363fb26b5a5@localhost> #2398: segfault in cmpLocks on 64 bit multicore ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Comment (by sclv): {{{ > ghc --make -threaded -O2 -debug testfi.hs > gdb --args ./testfi +RTS -N4 (gdb) run [Lots of text removed] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x43806950 (LWP 1248)] 0x000000000043990c in cmpLocks (w1=531, w2=1132470304) at posix/FileLock.c:35 35 return (l1->device == l2->device && l1->inode == l2->inode); (gdb) bt #0 0x000000000043990c in cmpLocks (w1=531, w2=1132470304) at posix/FileLock.c:35 #1 0x0000000000458166 in lookupHashTable (table=0x6ae110, key=1132470304) at Hash.c:197 #2 0x0000000000439a1d in lockFile (fd=533, dev=2055, ino=10584501, for_writing=0) at posix/FileLock.c:73 #3 0x000000000040597a in s7AW_info () #4 0x0000000600000012 in ?? () #5 0x0000000000405e28 in scJ1_info () #6 0x0000000000405e10 in scJ1_info () #7 0x0000000000444a00 in ?? () #8 0x00002aaaaab15c50 in ?? () #9 0x0000000000405e40 in scJ1_info () #10 0x00002aaaaab15c50 in ?? () #11 0x0000000000000000 in ?? () }}} Again this is on an Intel Core 2 Quad. I'm now running it on a 6.9 snapshot from June 15, by the way, and getting the same result. Note that it seems to happen 75% of the time at least at -N4. At -N3 I'm getting it 25% of the time or so. I'll attach the file I'm using as well, although I doubt that should have much impact on the results. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 01:48:39 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 01:39:47 2008 Subject: [GHC] #2398: segfault in cmpLocks on 64 bit multicore In-Reply-To: <043.83483373a348f7384863a195a6f7e5cf@localhost> References: <043.83483373a348f7384863a195a6f7e5cf@localhost> Message-ID: <052.62782d8226048a10df2fe57feb0a5fb9@localhost> #2398: segfault in cmpLocks on 64 bit multicore ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Comment (by sclv): Looking through the code, it seems to me that the HashTable used by FileLock.c isn't concurrent/threadsafe, and neither FileLock.c nor the foreign call to it from GHC.Handle serialize access. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 07:34:00 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 07:25:13 2008 Subject: [GHC] #2313: libHSrts_thr_debug linked against non-existing bfd library In-Reply-To: <046.369fe8828ff5a3c111568f185c25c8f0@localhost> References: <046.369fe8828ff5a3c111568f185c25c8f0@localhost> Message-ID: <055.c39ac447c0aa589c2bb856f4ab39415e@localhost> #2313: libHSrts_thr_debug linked against non-existing bfd library ----------------------------+----------------------------------------------- Reporter: kgardas | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Solaris | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed * milestone: => 6.10.1 Old description: > It seems there is a bug in RTS somewhere which makes libHSrts_thr_debug > in a way it's including some symbols from the bfd library. The bug shows > itself as a lot of testsuite tests failing with undefined symbols which > originates in the BFD library. Example: > > =====> cg013(threaded1) > cd ./codeGen/should_run && '/buildbot/ghc/kgardas/build/compiler/stage2 > /ghc-inplace' -no-recomp -dcore-lint -dcmm-lint -Di386_unknown_solaris2 > -o cg013 cg013.hs -threaded -debug >cg013.comp.stderr 2>&1 > Compile failed (status 256) errors were: > Undefined first referenced > symbol in file > bfd_openr > /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) > bfd_init > /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) > bfd_check_format_matches > /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) > ld: fatal: Symbol referencing errors. No output written to cg013 > collect2: ld returned 1 exit status New description: It seems there is a bug in RTS somewhere which makes libHSrts_thr_debug in a way it's including some symbols from the bfd library. The bug shows itself as a lot of testsuite tests failing with undefined symbols which originates in the BFD library. Example: {{{ =====> cg013(threaded1) cd ./codeGen/should_run && '/buildbot/ghc/kgardas/build/compiler/stage2 /ghc-inplace' -no-recomp -dcore-lint -dcmm-lint -Di386_unknown_solaris2 -o cg013 cg013.hs -threaded -debug >cg013.comp.stderr 2>&1 Compile failed (status 256) errors were: Undefined first referenced symbol in file bfd_openr /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) bfd_init /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) bfd_check_format_matches /buildbot/ghc/kgardas/build/rts/libHSrts_thr_debug.a(Printer.thr_debug_o) ld: fatal: Symbol referencing errors. No output written to cg013 collect2: ld returned 1 exit status }}} Comment: Patch applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 07:55:26 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 07:46:47 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.402b9090b6e72832f55031b2a2efd028@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by maeder): changing all instances like the following from {{{ instance (ShATermConvertible c, ShATermConvertible t) => ShATermConvertible (Q c t) where toShATermAux att0 ((:=>) a b) = do (att1, a') <- toShATerm' att0 a (att2, b') <- toShATerm' att1 b return $ addATerm (ShAAppl "(:=>)" [a',b'] []) att2 fromShATermAux ix att0 = case getShATerm ix att0 of ShAAppl "(:=>)" [a,b] _ -> case fromShATerm' a att0 of { (att1, a') -> case fromShATerm' b att1 of { (att2, b') -> (att2, (:=>) a' b') }} u -> fromShATermError "Q" u }}} to {{{ _toShATermAux_Q att0 ((:=>) a b) = do (att1, a') <- toShATerm' att0 a (att2, b') <- toShATerm' att1 b return $ addATerm (ShAAppl "(:=>)" [a',b'] []) att2 _fromShATermAux_Q ix att0 = case getShATerm ix att0 of ShAAppl "(:=>)" [a,b] _ -> case fromShATerm' a att0 of { (att1, a') -> case fromShATerm' b att1 of { (att2, b') -> (att2, (:=>) a' b') }} u -> fromShATermError "Q" u instance (ShATermConvertible c, ShATermConvertible t) => ShATermConvertible (Q c t) where toShATermAux = _toShATermAux_Q fromShATermAux = _fromShATermAux_Q }}} avoids the blow up -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 08:37:54 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 08:29:01 2008 Subject: [GHC] #2330: ghc-pkg should not report duplicate depends In-Reply-To: <045.a0d888b36f9d7b158756f697bfe898a1@localhost> References: <045.a0d888b36f9d7b158756f697bfe898a1@localhost> Message-ID: <054.2bcb4a651d2c692c9f9d818a9b59c89e@localhost> #2330: ghc-pkg should not report duplicate depends ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by duncan): My guess is to make a ghc-pkg registration file with a duplicate value in the 'depends' field and then register that package. Really it'd be better if it were rejected at registration time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 11:08:16 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 10:59:23 2008 Subject: [GHC] #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" Message-ID: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- To reproduce, create the files: Main.hs: {{{ module Main ( main, Baz ) where import Foo ( Bar ) type Spqr = Bar data Baz = Baz Spqr main = putStrLn "Hello" }}} Main.hs-boot: {{{ module Main where data Baz }}} Foo.hs: {{{ module Foo where import {-# SOURCE #-} Main ( Baz ) type Bar = Baz }}} Then run this command sequence: {{{ $ ghc Main.hs-boot ... $ ghc Foo.hs ... $ ghc Main.hs ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-apple-darwin): tcIfaceGlobal (local): not found: main:Main.Baz{tc r2T} [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Note the problem does not seem to manifest itself outside of one-shot mode. The full trace is: {{{ $ ghc Main.hs -ddump-if-trace -ddump-tc-trace FYI: cannot read old interface file: Main.hi: openBinaryFile: does not exist (No such file or directory) Considering whether to load base:Prelude Reading interface for base:Prelude; reason: Prelude is directly imported readIFace /usr/local/lib/ghc-6.8.2/lib/base-3.0.1.0/Prelude.hi updating EPS_ Considering whether to load main:Foo Reading interface for main:Foo; reason: Foo is directly imported readIFace Foo.hi updating EPS_ updating EPS_ Loading orphan modules: base:GHC.Base Considering whether to load base:GHC.Base {- SYSTEM -} Reading interface for base:GHC.Base; reason: base:GHC.Base is a orphan-instance module readIFace /usr/local/lib/ghc-6.8.2/lib/base-3.0.1.0/GHC/Base.hi updating EPS_ loadHiBootInterface main:Main Reading [boot] interface for main:Main; reason: Need the hi-boot interface for main:Main to compare against the Real Thing readIFace Main.hi-boot Finished typechecking interface for main:MainStarting fork { Declaration for Baz Loading decl for Main.Baz updating EPS_ tcIfaceDecl4 Main.Baz } ending fork Declaration for Baz Type envt: [(r2T, Type constructor `Main.Baz')] Main.hs:1:0: Tc2 Main.hs:1:0: tcTyAndCl Main Main.hs:1:0: kcd1 Spqr [[]] [[]] In the type synonym declaration for `Spqr' Main.hs:5:12: lk1 Bar In the type synonym declaration for `Spqr' Main.hs:5:12:Starting fork { Declaration for Bar Loading decl for Foo.Bar updating EPS_ ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-apple-darwin): tcIfaceGlobal (local): not found: main:Main.Baz{tc r2T} [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This happens because when typechecking the type synonym Main.Spqr, kcTyVar calls tcLookup. This causes GHC to pull on the declaration for Foo.Bar. However, this declaration makes use of Main.Baz via a SOURCE import and we haven't yet got around to type checking Main.Baz! Hence tcIfaceGlobal dies, unable to find Baz in the type environment. Note that reversing the order of the declarations of Main.Baz and Main.Spqr doesn't seem to make a difference. I think this is because Baz in turn uses Spqr. I only have limited knowledge of the type checker, but I think a possible fix to this would be to type check the right hand sides of type synonym declarations lazily so we put Main.Baz into the environment before we go off exploring Foo.Bar. We seem to use a trick to deal with a similar type checking interface data constructors? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 11:20:26 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 11:11:32 2008 Subject: [GHC] #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" In-Reply-To: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> References: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> Message-ID: <062.a2af27f16229fb6b8360b01c3abdeb23@localhost> #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Comment (by batterseapower): Actually, I've just confirmed that the synonym Main.Spqr is irrelevant: you can replace the use of it in Main.Baz with Foo.Bar itself and get the same behaviour. A workaround for this bug is to use a newtype rather than a type synonym in Foo. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 15:11:37 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 15:02:44 2008 Subject: [GHC] #2413: Segmentation fault in ghc --interactive when run with +RTS -Da Message-ID: <053.7a18e92eaea058983613232db722e65d@localhost> #2413: Segmentation fault in ghc --interactive when run with +RTS -Da -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- This was observed in HEAD as of 02/07/2008. 1. Compile a stage2 GHC with the -debug option on. 2. Run stage2/ghc-inplace --interactive RTS -Da Expected result: GHCi comes up, maybe showing some extra debugging information Actual result: {{{ stg_ap_0_ret... Segmentation fault }}} This has been observed on amd64/Linux and amd64/OSX 10.5. Interestingly, -Da is omitted from the RTS help text. Maybe DebugFlags.apply is known to be broken? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 15:43:05 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 15:34:12 2008 Subject: [GHC] #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) In-Reply-To: <045.86b9b930b3ded50e36018e43dce2d355@localhost> References: <045.86b9b930b3ded50e36018e43dce2d355@localhost> Message-ID: <054.dc0d8dbc18490aab799084d663dae58c@localhost> #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by megacz): * status: new => closed * resolution: => wontfix Comment: Sorry about the slow reply. I've tried updating GHC to latest darcs, but now the NDP build fails at an earlier point ("cabal-bin: cabal: Don't know what to do!... Warning: Package is unbuildable"), so I can't tell if it helped or not. So, I guess, close this bug since it can no longer be reproduced. Thanks for your time! - a -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 16:16:19 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 16:07:25 2008 Subject: [GHC] #2346: Compilation of large source files requires a lot of RAM In-Reply-To: <046.285595109907aedbac69f385749bac00@localhost> References: <046.285595109907aedbac69f385749bac00@localhost> Message-ID: <055.2e74d3ac507de2d76b8e4ac105c19402@localhost> #2346: Compilation of large source files requires a lot of RAM ------------------------------------------+--------------------------------- Reporter: choener | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 16:19:04 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 16:10:10 2008 Subject: [GHC] #2406: Data.List.sortFun In-Reply-To: <046.08859d63266a4054020b2d26eaa3a7a5@localhost> References: <046.08859d63266a4054020b2d26eaa3a7a5@localhost> Message-ID: <055.30911e305451a6916afc66a2bee7ee03@localhost> #2406: Data.List.sortFun -----------------------------+---------------------------------------------- Reporter: lpsmith | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: If you want to propose for the base library, please see http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 16:23:12 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 16:14:18 2008 Subject: [GHC] #2360: More information in occurs check message In-Reply-To: <042.d2d1b5c4c3c7a52b18a6186683534f09@localhost> References: <042.d2d1b5c4c3c7a52b18a6186683534f09@localhost> Message-ID: <051.ac3adeaf7d4cf578d3ca2f3f35fe30ed@localhost> #2360: More information in occurs check message -----------------------------+---------------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 17:23:39 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 17:14:46 2008 Subject: [GHC] #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) In-Reply-To: <045.86b9b930b3ded50e36018e43dce2d355@localhost> References: <045.86b9b930b3ded50e36018e43dce2d355@localhost> Message-ID: <054.35c1463bc95ba82b7ce1cf2356358026@localhost> #2379: ghc-6.9.20080614: panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by simonpj): Ian and Roman are working on fixing the build-system problem. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 17:28:15 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 17:19:35 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.63140c5d936076c0b25037fa3e737b67@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by simonpj): Adding data from Christian: * For ghc-6.8.2 our compressed binary hets.bz2 shrunk from 7.2 MB to 6.6 MB * For ghc-6.8.3 from 13 MB to 6.8 MB (some manual instance are left in our code) http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/linux/daily/ http://www.informatik.uni- bremen.de/agbkb/forschung/formal_methods/CoFI/hets/linux/versions/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 18:10:27 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 18:01:36 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.a8f58e4d371a3253d05e1184b8794ae3@localhost> #2307: Poor warning for conflicting functional dependencies -----------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2307 | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Comment (by simonpj): crumbs, good catch Ian. You are referring to `FunDeps.trimRoughMatchTcs`? Indeed that looks wrong: it should match on the `ls` rather than everything except `rs`. Is that what you meant, or did you have something else in mind? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 18:59:58 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 18:51:03 2008 Subject: [GHC] #2390: RPM spec file not present in source distribution tarball In-Reply-To: <046.dbf14f1bcd9b3aa5d69835f4914e4112@localhost> References: <046.dbf14f1bcd9b3aa5d69835f4914e4112@localhost> Message-ID: <055.1e50f3d0034c9ba465c5a4c53c8de13a@localhost> #2390: RPM spec file not present in source distribution tarball --------------------------+------------------------------------------------- Reporter: mikedlr | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the patch. The difference between the `.in` and non-`.in` versions is just: {{{ -%define version @ProjectVersion@ -%define release @release@ +%define version 6.9.20080702 +%define release 1 }}} so this change looks like it makes sense, for released versions at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 20:48:48 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 20:39:53 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.411b8a5e5df3cfa1d122936f6b4205f3@localhost> #2307: Poor warning for conflicting functional dependencies -----------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2307 | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Comment (by igloo): I can't think of a case where just-ls won't work, so that sounds right to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 2 23:47:35 2008 From: trac at galois.com (GHC) Date: Wed Jul 2 23:38:48 2008 Subject: [GHC] #2397: inclusion of Network.Curl causes compiler issues and coredumps In-Reply-To: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> References: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> Message-ID: <053.42f2b1127c8efb6db6dbda00772e9ab1@localhost> #2397: inclusion of Network.Curl causes compiler issues and coredumps ----------------------------------+----------------------------------------- Reporter: b7j0c | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- Comment (by b7j0c): ignore above comments regarding hxt and text.xml.light, it is doubtful they are the issue -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 01:23:31 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 01:14:36 2008 Subject: [GHC] #2414: GHCi segfault Message-ID: <043.07db70092bd8811bd5934348939d4781@localhost> #2414: GHCi segfault ------------------------+--------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- {{{ Prelude> Data.List.unfoldr Just (1,1) [1,zsh: segmentation fault ghci -v0 }}} Spotted in #haskell, ghc-6.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 01:34:18 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 01:25:23 2008 Subject: [GHC] #2415: unfoldr segfaults Message-ID: <046.a7585c7af4f9fc06bd8cc9b64ada6c12@localhost> #2415: unfoldr segfaults ------------------------+--------------------------------------------------- Reporter: vininim | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- > unfoldr Just (1,1) Results [1, Segmentation fault Seems to be a typechecking bug since Just doesn't really match unfoldr signature for a generator. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 01:37:52 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 01:28:58 2008 Subject: [GHC] #2415: unfoldr segfaults In-Reply-To: <046.a7585c7af4f9fc06bd8cc9b64ada6c12@localhost> References: <046.a7585c7af4f9fc06bd8cc9b64ada6c12@localhost> Message-ID: <055.de4e206deda2ca86fbab15902a5915f6@localhost> #2415: unfoldr segfaults -------------------------+-------------------------------------------------- Reporter: vininim | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: major | Resolution: duplicate Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Changes (by vininim): * status: new => closed * resolution: => duplicate Comment: Duplicate of http://hackage.haskell.org/trac/ghc/ticket/2414. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 01:52:57 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 01:44:00 2008 Subject: [GHC] #2414: GHCi / GHC segfault : type checker problem In-Reply-To: <043.07db70092bd8811bd5934348939d4781@localhost> References: <043.07db70092bd8811bd5934348939d4781@localhost> Message-ID: <052.65350a168cac01321697be35ce2ccdfd@localhost> #2414: GHCi / GHC segfault : type checker problem ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Comment (by AudreyTang): More data points: {{{ unfoldr Just ((),()) -- crash unfoldr (id Just) ((),()) -- fine unfoldr (id . Just) ((),()) -- fine unfoldr (Just . id) ((),()) -- fine }}} Also GHC 6.4.3 is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 12:16:55 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 12:08:02 2008 Subject: [GHC] #1687: A faster (^)-function. In-Reply-To: <064.1e051c3fce5c2da263cdc0424cf20634@localhost> References: <064.1e051c3fce5c2da263cdc0424cf20634@localhost> Message-ID: <073.8640ab8d7a35b5d1c1b41d3405f64f77@localhost> #1687: A faster (^)-function. ---------------------------------------+------------------------------------ Reporter: moonlite@dtek.chalmers.se | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Prelude | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------------------+------------------------------------ Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 12:18:02 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 12:09:09 2008 Subject: [GHC] #2310: Panic in ghci 6.8.2 with -fglasgow-exts In-Reply-To: <044.6adffbe80c29ff86b9900afa24eb80ad@localhost> References: <044.6adffbe80c29ff86b9900afa24eb80ad@localhost> Message-ID: <053.49d96ba60eed1ab4d4d85626e8521d65@localhost> #2310: Panic in ghci 6.8.2 with -fglasgow-exts --------------------+------------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2310 | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * status: new => closed * type: merge => bug * resolution: => fixed * milestone: 6.10 branch => 6.10.1 Comment: Wasn't merged in time for 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 12:19:22 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 12:10:56 2008 Subject: [GHC] #2175: stableptr003 fails In-Reply-To: <044.d06ef41a33cee91ab166dec272f5c106@localhost> References: <044.d06ef41a33cee91ab166dec272f5c106@localhost> Message-ID: <053.3d5059a5ac6e5c40585b87ef29be85c0@localhost> #2175: stableptr003 fails ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * type: merge => bug * resolution: => fixed Comment: Wasn't merged in time for 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 12:21:14 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 12:12:50 2008 Subject: [GHC] #2378: panic: lookupVers1, when standalone deriving Typeable and Data In-Reply-To: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> References: <044.817cb3c6a4bf0ec145ce20c20c5af470@localhost> Message-ID: <053.0f070ae316362385bd3f787095d8df91@localhost> #2378: panic: lookupVers1, when standalone deriving Typeable and Data -------------------------------------------+-------------------------------- Reporter: guest | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_compile/T2378 | Architecture: x86 Os: MacOS X | -------------------------------------------+-------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 12:21:21 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 12:12:56 2008 Subject: [GHC] #2358: Template Haskell's TupleT considers unary tuples as a valid types. In-Reply-To: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> References: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> Message-ID: <052.3edd79f99538d786a492aff3efce67e4@localhost> #2358: Template Haskell's TupleT considers unary tuples as a valid types. ------------------------------+--------------------------------------------- Reporter: fons | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_1tuple | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 14:31:06 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 14:22:11 2008 Subject: [GHC] #2390: RPM spec file not present in source distribution tarball In-Reply-To: <046.dbf14f1bcd9b3aa5d69835f4914e4112@localhost> References: <046.dbf14f1bcd9b3aa5d69835f4914e4112@localhost> Message-ID: <055.b36c5bcea80523b4cb83ec7e98f7e8fb@localhost> #2390: RPM spec file not present in source distribution tarball --------------------------+------------------------------------------------- Reporter: mikedlr | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Patch applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 20:40:19 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 20:31:21 2008 Subject: [GHC] #2373: Build fails to pass locations of external tools to libraries In-Reply-To: <042.251f9ace7edb49f0e772cf590973862b@localhost> References: <042.251f9ace7edb49f0e772cf590973862b@localhost> Message-ID: <051.17e4629e3ea24dcbbcc8c85880a2edf6@localhost> #2373: Build fails to pass locations of external tools to libraries ----------------------+----------------------------------------------------- Reporter: bos | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks, I've fixed this. We now pass the flags, provided the values were not empty. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 20:40:11 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 20:31:35 2008 Subject: [GHC] #2352: POSIX.1 unsetenv returns int In-Reply-To: <043.9a1a67d0fcfde818f197866387595049@localhost> References: <043.9a1a67d0fcfde818f197866387595049@localhost> Message-ID: <052.c7cd6d244e81c4300a9843009319fd57@localhost> #2352: POSIX.1 unsetenv returns int ----------------------------+----------------------------------------------- Reporter: donn | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/unix | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: NetBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: http://osdir.com/ml/lib.gnulib.bugs/2004-11/msg00009.html says that it returns `void` on NetBSD, and FreeBSD and Redhat 7.3 GNU/Linux, while my man page and http://www.opengroup.org/onlinepubs/009695399/functions/unsetenv.html agree that it should return `int`, so both cases really do exist. I've applied the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 20:40:15 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 20:31:47 2008 Subject: [GHC] #2307: Poor warning for conflicting functional dependencies In-Reply-To: <051.74da8f65a0dfd1e30516012444a9f297@localhost> References: <051.74da8f65a0dfd1e30516012444a9f297@localhost> Message-ID: <060.1b820c7009077938a5aa564a3f302bc5@localhost> #2307: Poor warning for conflicting functional dependencies ----------------------------------------------------+----------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2307, tcfail202 | Architecture: Unknown Os: Unknown | ----------------------------------------------------+----------------------- Changes (by igloo): * testcase: typecheck/should_fail/T2307 => typecheck/should_fail/T2307, tcfail202 * status: reopened => closed * resolution: => fixed Comment: I've made the change and added a test: tcfail202 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 3 22:09:49 2008 From: trac at galois.com (GHC) Date: Thu Jul 3 22:01:04 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.f41fed6ede79300a59a3ccb6d60934fe@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by chak): * cc: chak@cse.unsw.edu.au (added) Comment: Replying to [comment:1 guest]: > This really surprises me. Why doesn't think produce a link error? > Each instance declaration should give rise to a global symbol uniquely determined by the class and the type, I'd presume. And when they meet there will be a clash. > Obviously I'm wrong, as this (scary) example shows. I believe, toplevel symbols binding dictionaries include the module (and package name) like all other toplevel symbols. The example -although violating the current language definition- is less scary than one might think. You cannot abuse it (even if you chuck FDs into the mix) to coerce types unsafely (or circumvent strong typing in any other way). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 00:52:27 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 00:43:59 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main Message-ID: <048.56959a6c70911c633555f1458314494a@localhost> #2416: Optimization defeated by merging module into main -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- I have a library, `TheModule`, and an application that uses `TheModule`, called `Main`. When `TheModule` lives in `TheModule.hs` and `Main` lives in `Main.hs`, optimization works as expected. When I copy all of `TheModule`'s definitions and all of `Main`'s definitions into `Both.hs`, much less optimization occurs, as can be seen from -ddump-simpl, as well as the drastic difference in running times. The program performs a lot of small matrix-vector multiplications. The single command line argument tells how many to do. {{{ time ./Main 1000000 20.0 :. (59.0 :. (100.0 :. (137.0 :. ()))) real 0m0.389s user 0m0.152s sys 0m0.232s time ./Both 100000 20.0 :. (59.0 :. (100.0 :. (137.0 :. ()))) real 0m3.462s user 0m3.368s sys 0m0.068s }}} So that makes Both about 100 times slower. Compiled with -O2 and -fexcess- precision -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 00:58:39 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 00:50:11 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.d40b6c7376d6063bddb95b8a917b555d@localhost> #2416: Optimization defeated by merging module into main -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by sedillard): The main reason Main.hs is so much faster is this: {{{ ghc --make Main.hs -O2 -fexcess-precision -ddump-simpl | grep D# [1 of 2] Compiling TheModule ( TheModule.hs, TheModule.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... (no hits) }}} There are no calls D# in the compiled Main.hs, whereas Both.hs ends up with many D# constructors in the main loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 01:07:22 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 00:58:54 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.29591290745a87aa0e60cfc903e63869@localhost> #2416: Optimization defeated by merging module into main -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by dolio): What happens if you put: {{{ module Main (main) where }}} at the top of Both.hs? The obvious difference between the two setups is that Main.hs exports only main, m4 and v4, whereas Both exports all the functions in TheModule as well. When things are exported like that, GHC is more conservative about optimizations. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 01:11:00 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 01:02:33 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.bff246b043059d149a7f9132b7b6fa7e@localhost> #2416: Optimization defeated by merging module into main -------------------------------+-------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by sedillard): Adding `module Main (main) where` does not change the behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 01:50:17 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 01:41:50 2008 Subject: [GHC] #2359: Data.IntMap update{Min, Max}WithKey corrupts data structure In-Reply-To: <042.245aba7cabc38180cbe3d307aebd0f3e@localhost> References: <042.245aba7cabc38180cbe3d307aebd0f3e@localhost> Message-ID: <051.992c7ca32e29ce3a3c7e6664b5732850@localhost> #2359: Data.IntMap update{Min,Max}WithKey corrupts data structure ----------------------------+----------------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by sedillard): The problem was a typo, probably from cutting and pasting. I don't think more illuminating comments would have helped. A proper test, on the other hand... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 03:41:21 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 03:32:22 2008 Subject: [GHC] #2417: using GADT syntax for an associated datatype causes GHC to panic Message-ID: <044.b2b50269f86bb871052f27e2bada0368@localhost> #2417: using GADT syntax for an associated datatype causes GHC to panic ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- I am aware that this is probably not supposed to be supported. But even if using a GADT as an associated datatype instance does not directly work, it would be nice if * the GADT syntax was supported for "normal" associated datatypes, * the error message was more informative. Example program: {{{ {-# LANGUAGE TypeFamilies, GADTs #-} class X a where data T a instance X Int where data T Int where C :: T Int }}} Error message: {{{ ghc-6.9.20080615: panic! (the 'impossible' happened) (GHC version 6.9.20080615 for x86_64-unknown-linux): Maybe.fromJust: Nothing }}} Occurs with recent snapshot, but also with 6.8.2 and 6.8.3. Andres -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 04:55:41 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 04:46:48 2008 Subject: [GHC] #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 In-Reply-To: <053.ab23f29da9729b185efbfb211d6ff539@localhost> References: <053.ab23f29da9729b185efbfb211d6ff539@localhost> Message-ID: <062.0d782f51fa1cd115044a0ccce8399094@localhost> #2366: ASSERT failed! file typecheck/TcMType.lhs line 517 ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: gadt/equal | Architecture: Unknown Os: Multiple | ----------------------------+----------------------------------------------- Changes (by chak): * status: new => closed * resolution: => duplicate Comment: Duplicate of #2212. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 05:26:23 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 05:17:27 2008 Subject: [GHC] #2212: Double assignment to coercion variable In-Reply-To: <046.ad4e8af6cf182013c618bfd8fa17eb5c@localhost> References: <046.ad4e8af6cf182013c618bfd8fa17eb5c@localhost> Message-ID: <055.347c4263a28fbbed8caa94e6c6cd721e@localhost> #2212: Double assignment to coercion variable ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: equal | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): See also #2366, which gives a list of other tests that trigger this failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 05:28:55 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 05:19:58 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.05876514e66033183164577204ef59d8@localhost> #2416: Optimization defeated by merging module into main -----------------------+---------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -----------------------+---------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Thank you very much for a nice test case. Usually splitting things across modules makes things worse, not better, so it's an interesting case. I'll look into it. But probably not immediately -- POPL deadline then trip. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 05:38:23 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 05:29:40 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.dba2d83b1cafb53a9aab8a4d3c4c8a2d@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * priority: high => low * milestone: 6.10.1 => _|_ Comment: Currently this is by design. What would the unique global symbol be for {{{ instance C (T a) [Maybe b] }}} Oh, and `T` might be a type synonym. We could encode the type as a string, I suppose, but the error message (from the linker) would still be execrable. For indexed-type instances, overlap is unsound, so there's an eager check. On reflection, if you don't use `-fallow-overlapping-instances` GHC should arguably do the same eager check for class instances; that would more faithfully implement the Report. Even doing that is not trivial, because GHC goes to some lengths to avoid looking at (literally) thousands of interface files on every compilation, just on the off-chance that there'll be an instance declaration lurking there. With overlap allowed, it's clear that you can make different choices in different parts of the program. So I'm not sure what to do; and the only thing that comes to mind isn't cheap. For now I'll put it as low-prio, unless people start yelling that it's ruining their day. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 05:49:48 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 05:40:49 2008 Subject: [GHC] #2414: GHCi / GHC segfault : type checker problem In-Reply-To: <043.07db70092bd8811bd5934348939d4781@localhost> References: <043.07db70092bd8811bd5934348939d4781@localhost> Message-ID: <052.8e3583f5a329b3159aa9a002e52c9595@localhost> #2414: GHCi / GHC segfault : type checker problem -------------------------------------+-------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.1 Comment: Excellent report! Happily `-dcore-lint` nails the problem, as usual. As you speculated, it's in the type checker. A missing occurs check is allows through a bogus program. I wonder how long this has been lurking! I have not yet found the bug -- but I know where to look now. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 07:51:25 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 07:42:26 2008 Subject: [GHC] #2418: desugaring type function application to constraint makes bug disappear Message-ID: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> #2418: desugaring type function application to constraint makes bug disappear ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: type families | Testcase: Architecture: Unknown | Os: Unknown ------------------------------+--------------------------------------------- When considering type functions, I find it helpful to desugar their applications into additional constraints (`tf a` becomes `tf a~tfa=>tfa`). But consider this example from a recent [http://www.haskell.org/pipermail /haskell-cafe/2008-July/044911.html haskell-cafe thread]: {{{ {-# OPTIONS_GHC -fglasgow-exts #-} class Blah f a where blah :: a -> T f f a class A f where type T f :: (* -> *) -> * -> * -- wrapper :: forall a f tf . (Blah f a,T f~tf) => a -> tf f a wrapper :: forall a f . (Blah f a) => a -> T f f a wrapper x = blah x }}} for which `GHCi, version 6.9.20080514` yields: {{{ C:\Documents and Settings\cr3\Desktop\TF.hs:8:12: Could not deduce (Blah f a) from the context (Blah f1 a) arising from a use of `blah' at C:\Documents and Settings\cr3\Desktop\TF.hs:8:12-17 Possible fix: add (Blah f a) to the context of the type signature for `wrapper' In the expression: blah x In the definition of `wrapper': wrapper x = blah x C:\Documents and Settings\cr3\Desktop\TF.hs:8:12: Couldn't match expected type `T f1 f1 a' against inferred type `T f f a' In the expression: blah x In the definition of `wrapper': wrapper x = blah x Failed, modules loaded: none. }}} Switching to the desugared version of the `wrapper` signature makes the error go away, so the "desugared" and original version are not equivalent in the current implementation of type families! See also [http://www.haskell.org/pipermail/haskell-cafe/2008-July/044914.html]. For added fun, GHCi reports the sugared type when using the desugared one: {{{ *Main> :t wrapper wrapper :: (Blah f a) => a -> T f f a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 07:59:08 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 07:50:09 2008 Subject: [GHC] #2418: desugaring type function application to constraint makes bug disappear In-Reply-To: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> References: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> Message-ID: <053.6941fc3a4114d6ef3c2434fb9d33094f@localhost> #2418: desugaring type function application to constraint makes bug disappear -------------------------------------+-------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: type families | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Thanks. We're collecting type-function-related bugs here http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus. Manuel is on the job, now that his exam season is nearly over. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 08:37:20 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 08:28:37 2008 Subject: [GHC] #2282: threaded runtime system crashes on powerpc with -N2 In-Reply-To: <068.a075e93dacb792d84b85e8eb8eea3deb@localhost> References: <068.a075e93dacb792d84b85e8eb8eea3deb@localhost> Message-ID: <077.66b96a2c01830f07577061111bf6f55c@localhost> #2282: threaded runtime system crashes on powerpc with -N2 -------------------------------------------+-------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------------------------+-------------------------------- Comment (by thorkilnaur): I have tried several combinations of machines/OS X versions and GHC versions and consistently succeeded in running your program. But the PPC machines that I have are single-core, so this is probably naive. I presume that you use a multi-core machine of some kind? Could you supply some additional details please? Also about the source of the GHC 6.8.2 that you use? (For example, is it some binary, from !MacPorts, built from a source distribution or something else entirely?) Thanks and best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 08:57:45 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 08:48:51 2008 Subject: [GHC] #2400: location-dependent scope issue with ghci.conf In-Reply-To: <044.0ebdce0c676199b2cfa87a9fbb8c81a2@localhost> References: <044.0ebdce0c676199b2cfa87a9fbb8c81a2@localhost> Message-ID: <053.3ca0189607fbb1655d9875fe9913abc1@localhost> #2400: location-dependent scope issue with ghci.conf ---------------------+------------------------------------------------------ Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: This doesn't look like a bug to me. Existing bindings are discarded when a module is loaded, so the binding `msg` is not available after loading `Main`. To avoid this you need to refer to `msg` by name rather than by a string, i.e. bind it at the time `grep` is defined, rather than when `grep` is run. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 09:04:49 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 08:55:50 2008 Subject: [GHC] #2182: ghci session retains instances after :m -Module In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@localhost> References: <044.c09df8f4b72158c8c14035187a5540c9@localhost> Message-ID: <053.e0e8fd0e6f0f9c6d1b1bc84788643b21@localhost> #2182: ghci session retains instances after :m -Module ---------------------+------------------------------------------------------ Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by simonmar): * priority: normal => low * milestone: 6.10 branch => _|_ Comment: In fact this is a known bug mentioned in the User's Guide: [http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs- ghc] (see the final bullet point). We don't have a ticket open for it as far as I can tell, though, so I'll leave this one open. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 09:20:30 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 09:11:31 2008 Subject: [GHC] #2398: segfault in cmpLocks on 64 bit multicore In-Reply-To: <043.83483373a348f7384863a195a6f7e5cf@localhost> References: <043.83483373a348f7384863a195a6f7e5cf@localhost> Message-ID: <052.4bccac5a3fcb2bcd7a14602f24eb4537@localhost> #2398: segfault in cmpLocks on 64 bit multicore ----------------------------+----------------------------------------------- Reporter: sclv | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: low => high * owner: => simonmar Comment: Replying to [comment:6 sclv]: > Looking through the code, it seems to me that the HashTable used by FileLock.c isn't concurrent/threadsafe, and neither FileLock.c nor the foreign call to it from GHC.Handle serialize access. Absolutely right, I completely failed to do the proper locking here. I'll fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 09:25:24 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 09:16:23 2008 Subject: [GHC] #2419: Extensible exceptions Message-ID: <044.f010ed756089aa253e6a05c76683fcdc@localhost> #2419: Extensible exceptions -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- This is a proposal to replace the current exception mechanism in the base library with extensible exceptions. It also reimplements the existing exceptions on top of extensible exceptions, for legacy applications. Proposed deadline: 25th July. = What are extensible exceptions? = Simon's extensible extensions paper is very easy to read, and describes the problems and proposed solution very well: http://www.haskell.org/~simonmar/papers/ext-exceptions.pdf I won't try to reproduce everything the paper says here, but here is the list of what we want extracted from it: * A hierarchy of exception types, such that a particular catch can choose to catch only exceptions that belong to a particular subclass and re-throw all others. * A way to add new exception types at any point in the hierarchy from library or program code. * The boilerplate code required to add a new type to the exception hierarchy should be minimal. * Exceptions should be thrown and caught using the same primitives, regardless of the types involved. I heartily recommend having a read through of the paper. = Patches and examples = The patches are here: http://darcs.haskell.org/ext-excep/ along with `Examples.hs`, which gives some examples of using it. The patches aren't polished; if this proposal is accepted then there is some more work to do, moving things around inside the base package to simplify the dependencies, and to maximise the amount of code that can be shared between all the impls. There's also some GHC-specific fiddling to be done, to make GHC.!TopHandler use the new exceptions. This can all be done without further library proposals, though. Also, currently it derives Data.Typeable, which is unportable, but we can easily work around that. The only extensions that I don't think that we can do without are !ExistentialQuantification and Rank2Types. !DeriveDataTypeable makes the implementation easier, and !DeriveDataTypeable and !PatternSignatures make using it easier. = Library function differences = As far as the library functions are concerned, here are the main differences: The old and new types for catch are: {{{ Old: catch :: IO a -> (Exception -> IO a) -> IO a New: catch :: Exception e => IO a -> (e -> IO a) -> IO a }}} i.e. catch can now catch any type of exception; we don't have to force all the different types of extension into one fixed datatype. All the other exception functions are similarly changed to handle any type of extension, e.g. we now have {{{ try :: Exception e => IO a -> IO (Either e a) }}} Now that you can write handlers for different exception types, you might want to catch multiple different types at the same point. You can use catches for this. For example, the !OldException module needs to catch all the new exception types and put them into the old Exception type, so that the legacy handler can be run on them. It looks like this: {{{ catch :: IO a -> (Exception -> IO a) -> IO a catch io handler = io `catches` [Handler (\e -> handler e), Handler (\exc -> handler (ArithException exc)), Handler (\exc -> handler (ArrayException exc)), ...] }}} where the first Handler deals with exceptions of type Exception, the second those of type !ArithException, and so on. If you want to catch all exceptions, e.g. if you want to cleanup and rethrow the exception, or just print the exception at the top-level, you can use the new function catchAny: {{{ catchAny :: IO a -> (forall e . Exception e => e -> IO a) -> IO a }}} You can happily write {{{ `catchAny` \e -> print e }}} where {{{ `catch` \e -> print e }}} would give you an ambiguous type variable error. There's also {{{ ignoreExceptions :: IO () -> IO () }}} which can be used instead of try for things like {{{ ignoreExceptions (hClose h) }}} (where we don't look at the result, so the exception type would be ambiguous if we used try). (I'm not sure if this is the best name for this function). All the build failures I've seen with the new exceptions library have been cases where you need to change a "catch" to "catchAny", "try" to "ignoreExceptions", or occassionally a different function, e.g. "bracket" or "handle", is used to handle any extension, so adding a type signature involving the !SomeException type solves the problem. The old interface is available in Control.!OldException. Currently it doesn't catch exceptions that don't fit into the old Exception type; we could catch them, show them and treat them as user errors, but then the exception has changed if it gets rethrown. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 09:30:01 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 09:21:01 2008 Subject: [GHC] #2419: Extensible exceptions In-Reply-To: <044.f010ed756089aa253e6a05c76683fcdc@localhost> References: <044.f010ed756089aa253e6a05c76683fcdc@localhost> Message-ID: <053.3ff5bb9a606d44f7295f3b80a271e8d8@localhost> #2419: Extensible exceptions ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by igloo): Thread starts here: http://www.haskell.org/pipermail/libraries/2008-July/010095.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 09:36:07 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 09:27:09 2008 Subject: [GHC] #2407: internal error In-Reply-To: <048.61f1ce93106e412769adb2b6a8addcd6@localhost> References: <048.61f1ce93106e412769adb2b6a8addcd6@localhost> Message-ID: <057.508f7cd7df78780b8b779c6d49b32b5a@localhost> #2407: internal error ----------------------------+----------------------------------------------- Reporter: vigalchin | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * component: Compiler => Runtime System * milestone: => 6.10.1 Old description: > timer: internal error: resurrectThreads: thread blocked in a strange way > (GHC version 6.8.2 for i386_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Aborted (core dumped) New description: {{{ timer: internal error: resurrectThreads: thread blocked in a strange way (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} Comment: Can you provide us with the program that generates the error? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 09:38:44 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 09:29:48 2008 Subject: [GHC] #2408: threadWaitRead on mingw32 threaded causes internal error In-Reply-To: <044.646a5d9cf31ef2594dbfe492fec77132@localhost> References: <044.646a5d9cf31ef2594dbfe492fec77132@localhost> Message-ID: <053.87251253c6ea7b8022df7d27415d6b7a@localhost> #2408: threadWaitRead on mingw32 threaded causes internal error ----------------------------+----------------------------------------------- Reporter: kirby | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.1 Comment: `threadWaitRead` has never worked on Windows with -threaded. It shouldn't really be part of the `Control.Concurrent` API, with its FD argument and all. But I'm looking into making `hWaitForInput` work on Windows, and that would let us implement `threadWaitRead` too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 09:41:57 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 09:32:58 2008 Subject: [GHC] #2400: location-dependent scope issue with ghci.conf In-Reply-To: <044.0ebdce0c676199b2cfa87a9fbb8c81a2@localhost> References: <044.0ebdce0c676199b2cfa87a9fbb8c81a2@localhost> Message-ID: <053.d720ce0d765a971ee42de9409adee5ff@localhost> #2400: location-dependent scope issue with ghci.conf ---------------------+------------------------------------------------------ Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Comment (by claus): Hm, I'm sure I tested this against older GHCi versions at the time (the example is a stripped down version of the real `.ghci/ghci.conf` I've been using for quite some time). But I can't seem to reproduce a working version with older GHCis now, so closing is right. You probably meant it the other way round: bind `msg` at the time `grep` is run, rather than defined. Thanks, that also works in the current version of my full script, but prevents reuse of the function represented here by `msg` in other commands (cross-stage persistence in GHCi scripts is tricky, not least because of the awkward syntax). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 10:47:58 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 10:38:58 2008 Subject: [GHC] #2398: segfault in cmpLocks on 64 bit multicore In-Reply-To: <043.83483373a348f7384863a195a6f7e5cf@localhost> References: <043.83483373a348f7384863a195a6f7e5cf@localhost> Message-ID: <052.fc761749edadaa25b48102ddeea5f8e4@localhost> #2398: segfault in cmpLocks on 64 bit multicore ----------------------------+----------------------------------------------- Reporter: sclv | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri Jul 4 15:46:26 BST 2008 Simon Marlow * FIX #2398: file locking wasn't thread-safe }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 10:58:43 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 10:49:59 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.83d1adbbabff5c648033857310bee5c8@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by morrow): * cc: mjm2002@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 11:08:56 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 10:59:56 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.6eacf75d3ccd18ef27365543d5605cac@localhost> #2416: Optimization defeated by merging module into main -----------------------+---------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -----------------------+---------------------------------------------------- Comment (by sedillard): Thanks for looking into it. It has something to do with the Storable instance. I've noticed consistently flaky behavior from the combination of that class and my vector data type. Until the NDP array libraries mature, or until someone helps me with this [http://www.haskell.org/pipermail /haskell-cafe/2008-July/044879.html], Storable is all I've got and I use it heavily. Originally, I meant to submit another bug, and I was trying to create a simple test case, which is when I ran across this behavior while trying to merge everything into one file. That original bug, also involving Storable, is even weirder: I have a type Vec4 a, which is polymorphic in a, and a Storable instance for that. (Same as in this file.) I also have a specialized types, Vec2D - Vec4D, with unpacked doubles, and functions pack/unpack which convert between the polymorphic and specialized types. The weirdness is this: when I declare a Storable instance for Vec2D, using pack/unpack and the Storable methods of Vec2 a, then the optimization fails for Vec4 a's Storable methods. The test case is the same as here, Main.hs doing many 4x4 matrix/vector multiplies. So when I define type B's Storable instance using type A's, then optimization fails for type A's methods, even though no values of type B are ever used. Totally bizarre. I can reproduce this, but like I said, I ran into this here bug when trying to make a single- file test case, so first things first I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 11:13:54 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 11:04:55 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.cc4142c173d1815cc3c3e1956d3cb23e@localhost> #2416: Optimization defeated by merging module into main -----------------------+---------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -----------------------+---------------------------------------------------- Comment (by simonpj): If you can boil down your Storable problem, do put it in a separate Trac ticket. S -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 11:35:01 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 11:26:01 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.8997e52972f21a0c9f63bea6d9607a63@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: Type: bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: GHCi | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Changes (by simonmar): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 12:58:29 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 12:49:29 2008 Subject: [GHC] #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable In-Reply-To: <053.8442170ef9b4829325987986f707598b@localhost> References: <053.8442170ef9b4829325987986f707598b@localhost> Message-ID: <062.bd47968cec78fd685acba4d2f24d3e2d@localhost> #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: MacOS X | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: Good point. I'm fixing. S -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 13:55:09 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 13:46:09 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.5ab3b906cc5059a90177a7235a3eb210@localhost> #2416: Optimization defeated by merging module into main -----------------------+---------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -----------------------+---------------------------------------------------- Comment (by sedillard): Added new, smaller test case. MainOnly.hs, LibOnly.hs and MainAndLib.hs. The problem is definitely with the Storable instance. In MainAndLib none of the methods are inlined, in MainOnly they are. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 15:39:56 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 15:30:56 2008 Subject: [GHC] #2420: Multi-method classes are inlined/specialized better than single-method classes for strict types Message-ID: <048.3992ed493cb4d18feeaa36522408a406@localhost> #2420: Multi-method classes are inlined/specialized better than single-method classes for strict types --------------------------+------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Linux --------------------------+------------------------------------------------- Instances of single-method class are optimized better than instances of multi-method classes. Attached is a small example, {{{ class Square a where square :: a -> a }}} and a simple data type {{{ data Pair a = Pair !a !a instance Num a => Square (Pair a) where square (Pair a b) = Pair (a*a) (b*b) }}} and a specialized function {{{ squarepd :: Pair Double -> Pair Double squarepd = pair }}} Compiled as is, squarepd will turn into this {{{ Test.squarepd :: Test.Pair GHC.Float.Double -> Test.Pair GHC.Float.Double [GlobalId] [Arity 1 NoCafRefs Str: DmdType U(U(L)U(L))m] Test.squarepd = \ (eta_sgh :: Test.Pair GHC.Float.Double) -> case eta_sgh of wild_B1 { Test.Pair a_a60 b_a61 -> case a_a60 of wild1_agE { GHC.Float.D# x_agG -> case b_a61 of wild2_Xh2 { GHC.Float.D# x1_Xh7 -> Test.Pair @ GHC.Float.Double (GHC.Float.D# (GHC.Prim.*## x_agG x_agG)) (GHC.Float.D# (GHC.Prim.*## x1_Xh7 x1_Xh7)) }}} }}} Now if you add another method to class Square (anything at all), this happens {{{ Test.squarepd :: Test.Pair GHC.Float.Double -> Test.Pair GHC.Float.Double [GlobalId] [Arity 1 NoCafRefs Str: DmdType U(U(L)U(L))m] Test.squarepd = __inline_me (\ (ds_dgv :: Test.Pair GHC.Float.Double) -> case ds_dgv of wild_Xi { Test.Pair a_a5Y b_a5Z -> Test.$WPair @ GHC.Float.Double (GHC.Float.timesDouble a_a5Y a_a5Y) (GHC.Float.timesDouble b_a5Z b_a5Z) }) }}} Which also what you get when you remove the strictness annotations from 'Pair'. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 15:46:13 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 15:37:18 2008 Subject: [GHC] #2421: HSQL build reports exposed module as hidden, and fails Message-ID: <050.3dd63c14c5864d1033083a7ce5dd983d@localhost> #2421: HSQL build reports exposed module as hidden, and fails ----------------------------------+----------------------------------------- Reporter: volker-wysk | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 6.8.2 | Severity: normal Keywords: modules, exposure | Testcase: Architecture: x86 | Os: Linux ----------------------------------+----------------------------------------- Hello. I'm trying to install hsql-1.7, and it needs some library "old- time", which appears to be hidden. However, when exposing this library. the compiler and the HSQL build script disagree on whether old-time is exposed. Configure works: /tmp/hsql-1.7 $ runghc Setup.lhs configure Configuring hsql-1.7... Warning: No license-file field. Exposing old-time succeeds: /tmp/hsql-1.7 $ sudo bash /tmp/hsql-1.7 % ghc-pkg expose old-time Saving old package config file... done. Writing new package config file... done. /tmp/hsql-1.7 % ghc-pkg describe old-time | egrep exposed exposed: True exposed-modules: System.Time But the build process somehow gets the idea that old-time is hidden: /tmp/hsql-1.7 % runghc Setup.lhs build Preprocessing library hsql-1.7... Building hsql-1.7... Database/HSQL.hsc:66:7: Could not find module `System.Time': it is a member of package old-time-1.0.0.0, which is hidden -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 17:18:39 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 17:09:39 2008 Subject: [GHC] #2422: Unrelated instance foils optimizer Message-ID: <048.44d8fab6eafad69dae1f639aff0c37d2@localhost> #2422: Unrelated instance foils optimizer --------------------------+------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux --------------------------+------------------------------------------------- I have a type `(:.) a b` that I use for vectors, so a 4d vector is `a:.a:.a:.a:.()`. This is just a linked list, so I also have a packed representation for Doubles, `Vec4D` and a class that relates the two representations. The Storable instances for `(:.)` are inductive: if `a` and `(b:.c)` are Storable then so is `(a:.b:.c)`. So long as the source is a peek and the destination is a poke, the method calls optimize neatly and no `(:.)` values are allocated. Here's the weird part: If I use the Storable methods of `(:.)` and the pack/unpack methods to extend a `Storable` instance to `Vec4D`, then the optimization of ''the `(:.)` Storable methods'' fails. The `Vec4D` instances are not used at all, and yet they affect optimization of the `(:.)` instances. This is probably related to #2416. If I move the `Storable` instance for `(:.)` into `Main.hs`, then all optimization fails regardless of any instance for `Vec4D`. If I move the `Storable` instance for `Vec4D` into a different module than the instance for `(:.)`, then optimization works fine. The example is in two files. I tried to merge them into one but that's when I discovered #2416. Compiled with -O2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 17:27:45 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 17:19:04 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.5b9f366f6ade5ff0211a17d429d525c0@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by guest): Oh, come on. It's easy to generate the unique string for the instance by flattening the type. HBC did this 15 years ago. :) The linker error is a little obscure, but since ghc starts the linker it can filter the error messages and print a better one. (HBC didn't do that.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 17:31:11 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 17:22:47 2008 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.be3c9943c4c3d568b4d1097f4ba8e26b@localhost> #1346: bootstrap from HC files --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by shepheb): * cc: Braden.Shepherdson@gmail.com (added) Comment: The ArmLinuxGhc project would love to have bootstrapping working for 6.10 (or in 6.9), since the move to libffi makes 6.10 much easier to port than 6.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 23:47:57 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 23:39:03 2008 Subject: [GHC] #1823: GADTs and scoped type variables don't work right In-Reply-To: <046.981e6dd1b8fe0fafb375234b6a911fa1@localhost> References: <046.981e6dd1b8fe0fafb375234b6a911fa1@localhost> Message-ID: <055.da7fe45aa2d0e6ebb48c0c494c63a09c@localhost> #1823: GADTs and scoped type variables don't work right -------------------------------------+-------------------------------------- Reporter: simonpj | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: gadt/scoped.hs | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: This works now in the head (after replacing GADT refinements by equalities). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 4 23:59:09 2008 From: trac at galois.com (GHC) Date: Fri Jul 4 23:50:47 2008 Subject: [GHC] #1999: panic with GADT etc. In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost> References: <046.74c6dc616261a913ffd4180fb00731f0@localhost> Message-ID: <055.f2c647635fc0a5e08b8d90d8367dd376@localhost> #1999: panic with GADT etc. ----------------------+----------------------------------------------------- Reporter: jeltsch | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: Works with the new GADT machinery based on equalities. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 00:23:09 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 00:14:11 2008 Subject: [GHC] #1948: panic compiling associated type synonyms In-Reply-To: <044.901fcabfca30dda2950c2764ee7f0ad8@localhost> References: <044.901fcabfca30dda2950c2764ee7f0ad8@localhost> Message-ID: <053.9a4f9141376fe6ddba6441d5130eb2f3@localhost> #1948: panic compiling associated type synonyms --------------------------------+------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: duplicate Keywords: typefunction panic | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Changes (by chak): * status: new => closed * resolution: => duplicate Comment: The panic is fixed in the head. The program still doesn't work as superclass constraints don't work, but that is already tracked by bug #2102; hence, I mark this one as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 00:29:02 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 00:20:05 2008 Subject: [GHC] #1900: Type families with class constraints: type-checker loops In-Reply-To: <049.560239d640c515e64393974a17f250b4@localhost> References: <049.560239d640c515e64393974a17f250b4@localhost> Message-ID: <058.278eab95ed3b878c1525cd6093fde642@localhost> #1900: Type families with class constraints: type-checker loops -------------------------------------+-------------------------------------- Reporter: h.holtmann | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: Works now in the head. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 00:37:13 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 00:28:14 2008 Subject: [GHC] #1834: No instance for in ghci command line In-Reply-To: <044.2dbe27811cee51b70ea990c70970b1c5@localhost> References: <044.2dbe27811cee51b70ea990c70970b1c5@localhost> Message-ID: <053.580481e2356cd3f6df2ebf5ab16f7664@localhost> #1834: No instance for in ghci command line ------------------------------------------------------+--------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: fixed Keywords: type family function class instance ghci | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------------------+--------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: Works in the head. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 05:15:17 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 05:06:17 2008 Subject: [GHC] #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin Message-ID: <047.918ccc59a875951e79ffd2348c4375d6@localhost> #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin -------------------------+-------------------------------------------------- Reporter: jimwhite | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Trying to install GHC using macports (1.600). {{{ Bimini:~ jim$ sudo port install darcs ---> Fetching ghc ---> Verifying checksum(s) for ghc ---> Extracting ghc ---> Applying patches to ghc ---> Configuring ghc ---> Building ghc with target all Error: Target org.macports.build returned: shell command "env DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib make" returned error 2 Command output: cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ make -r && \ setup/Setup register --inplace; \ fi mv: rename GNUmakefile to GNUmakefile.tmp: No such file or directory Preprocessing library haskell-src-1.0.1.2... Generating Makefile haskell-src-1.0.1.2... GNUmakefile:71: dist/build/.depend: No such file or directory ../../compiler/stage1/ghc-inplace -M -optdep-f -optdepdist/build/.depend -optdep-s -optdepp -package-name haskell-src-1.0.1.2 -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package pretty-1.0.0.0 -package array-0.1.0.0 -package haskell98-1.0.1.0 -O -XCPP -idist/build -H16m -O -I/opt/local/include -L/opt/local/lib -O -Rghc- timing -fgenerics Language.Haskell.Lexer Language.Haskell.Parser Language.Haskell.ParseMonad Language.Haskell.Pretty Language.Haskell.Syntax Language.Haskell.ParseUtils <> for dir in dist/build/Language/Haskell/; do \ if test ! -d $dir; then mkdir -p $dir; fi \ done ../../compiler/stage1/ghc-inplace -package-name haskell-src-1.0.1.2 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package pretty-1.0.0.0 -package array-0.1.0.0 -package haskell98-1.0.1.0 -O -XCPP -idist/build -H16m -O -I/opt/local/include -L/opt/local/lib -O -Rghc-timing -fgenerics -c Language/Haskell/Syntax.hs -o dist/build/Language/Haskell/Syntax.o -ohi dist/build/Language/Haskell/Syntax.hi <> ../../compiler/stage1/ghc-inplace -package-name haskell-src-1.0.1.2 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package pretty-1.0.0.0 -package array-0.1.0.0 -package haskell98-1.0.1.0 -O -XCPP -idist/build -H16m -O -I/opt/local/include -L/opt/local/lib -O -Rghc-timing -fgenerics -c Language/Haskell/ParseMonad.hs -o dist/build/Language/Haskell/ParseMonad.o -ohi dist/build/Language/Haskell/ParseMonad.hi <> ../../compiler/stage1/ghc-inplace -package-name haskell-src-1.0.1.2 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package pretty-1.0.0.0 -package array-0.1.0.0 -package haskell98-1.0.1.0 -O -XCPP -idist/build -H16m -O -I/opt/local/include -L/opt/local/lib -O -Rghc-timing -fgenerics -c Language/Haskell/Lexer.hs -o dist/build/Language/Haskell/Lexer.o -ohi dist/build/Language/Haskell/Lexer.hi <> ../../compiler/stage1/ghc-inplace -package-name haskell-src-1.0.1.2 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package pretty-1.0.0.0 -package array-0.1.0.0 -package haskell98-1.0.1.0 -O -XCPP -idist/build -H16m -O -I/opt/local/include -L/opt/local/lib -O -Rghc-timing -fgenerics -c Language/Haskell/Pretty.hs -o dist/build/Language/Haskell/Pretty.o -ohi dist/build/Language/Haskell/Pretty.hi ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 for powerpc-apple-darwin): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> make[2]: *** [dist/build/Language/Haskell/Pretty.o] Error 1 make[1]: *** [make.library.haskell-src] Error 2 make: *** [stage1] Error 2 Error: The following dependencies failed to build: ghc Error: Status 1 encountered during processing. }}} System is PowerMac G5 (2x2.5GHz) The first time I got: {{{ Bimini:~ jim$ sudo port install darcs ---> Fetching ghc ---> Verifying checksum(s) for ghc ---> Extracting ghc ---> Applying patches to ghc ---> Configuring ghc ---> Building ghc with target all Error: Target org.macports.build returned: shell command "env DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib make" returned error 2 Command output: cmp -s GNUmakefile GNUmakefile.tmp && mv GNUmakefile.tmp GNUmakefile; \ make -r && \ setup/Setup register --inplace; \ fi mv: rename GNUmakefile to GNUmakefile.tmp: No such file or directory Preprocessing library haskell-src-1.0.1.2... Generating Makefile haskell-src-1.0.1.2... GNUmakefile:71: dist/build/.depend: No such file or directory ../../compiler/stage1/ghc-inplace -M -optdep-f -optdepdist/build/.depend -optdep-s -optdepp -package-name haskell-src-1.0.1.2 -hide-all-packages -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package pretty-1.0.0.0 -package array-0.1.0.0 -package haskell98-1.0.1.0 -O -XCPP -idist/build -H16m -O -I/opt/local/include -L/opt/local/lib -O -Rghc- timing -fgenerics Language.Haskell.Lexer Language.Haskell.Parser Language.Haskell.ParseMonad Language.Haskell.Pretty Language.Haskell.Syntax Language.Haskell.ParseUtils <> for dir in dist/build/Language/Haskell/; do \ if test ! -d $dir; then mkdir -p $dir; fi \ done ../../compiler/stage1/ghc-inplace -package-name haskell-src-1.0.1.2 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package pretty-1.0.0.0 -package array-0.1.0.0 -package haskell98-1.0.1.0 -O -XCPP -idist/build -H16m -O -I/opt/local/include -L/opt/local/lib -O -Rghc-timing -fgenerics -c Language/Haskell/Syntax.hs -o dist/build/Language/Haskell/Syntax.o -ohi dist/build/Language/Haskell/Syntax.hi <> ../../compiler/stage1/ghc-inplace -package-name haskell-src-1.0.1.2 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package pretty-1.0.0.0 -package array-0.1.0.0 -package haskell98-1.0.1.0 -O -XCPP -idist/build -H16m -O -I/opt/local/include -L/opt/local/lib -O -Rghc-timing -fgenerics -c Language/Haskell/ParseMonad.hs -o dist/build/Language/Haskell/ParseMonad.o -ohi dist/build/Language/Haskell/ParseMonad.hi <> ../../compiler/stage1/ghc-inplace -package-name haskell-src-1.0.1.2 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package pretty-1.0.0.0 -package array-0.1.0.0 -package haskell98-1.0.1.0 -O -XCPP -idist/build -H16m -O -I/opt/local/include -L/opt/local/lib -O -Rghc-timing -fgenerics -c Language/Haskell/Lexer.hs -o dist/build/Language/Haskell/Lexer.o -ohi dist/build/Language/Haskell/Lexer.hi <> ../../compiler/stage1/ghc-inplace -package-name haskell-src-1.0.1.2 -hide- all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.2.0 -package pretty-1.0.0.0 -package array-0.1.0.0 -package haskell98-1.0.1.0 -O -XCPP -idist/build -H16m -O -I/opt/local/include -L/opt/local/lib -O -Rghc-timing -fgenerics -c Language/Haskell/Pretty.hs -o dist/build/Language/Haskell/Pretty.o -ohi dist/build/Language/Haskell/Pretty.hi ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 for powerpc-apple-darwin): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> make[2]: *** [dist/build/Language/Haskell/Pretty.o] Error 1 make[1]: *** [make.library.haskell-src] Error 2 make: *** [stage1] Error 2 Error: The following dependencies failed to build: ghc Error: Status 1 encountered during processing. }}} I ran "clean" and tried again. This time it went quite a while longer then paniced. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 05:19:21 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 05:10:20 2008 Subject: [GHC] #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin In-Reply-To: <047.918ccc59a875951e79ffd2348c4375d6@localhost> References: <047.918ccc59a875951e79ffd2348c4375d6@localhost> Message-ID: <056.ffaff580f1c8e5d83bcbb67655edffb2@localhost> #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin -----------------------------+---------------------------------------------- Reporter: jimwhite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Comment (by jimwhite): The first log was supposed to be this (it's just duplicated above): {{{ Bimini:~ jim$ sudo port install darcs ---> Fetching pkgconfig ---> Attempting to fetch pkg-config-0.23.tar.gz from http://pkg- config.freedesktop.org/releases/ ... ---> Cleaning readline ---> Fetching ghc ---> Attempting to fetch ghc-6.8.3-src.tar.bz2 from http://haskell.org/ghc/dist/6.8.3/ ---> Attempting to fetch ghc-6.8.3-src-extralibs.tar.bz2 from http://haskell.org/ghc/dist/6.8.3/ ---> Attempting to fetch ghc-6.8.2-darwin-ppc-leopard-bootstrap.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/ ---> Verifying checksum(s) for ghc ---> Extracting ghc ---> Applying patches to ghc ---> Configuring ghc ---> Building ghc with target all Error: Target org.macports.build returned: shell command "env DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib make" returned error 2 Command output: <> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -L/opt/local/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -c ndpFlatten/FlattenInfo.hs -o stage1/ndpFlatten/FlattenInfo.o -ohi stage1/ndpFlatten/FlattenInfo.hi <> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -L/opt/local/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -c ndpFlatten/PArrAnal.hs -o stage1/ndpFlatten/PArrAnal.o -ohi stage1/ndpFlatten/PArrAnal.hi <> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -L/opt/local/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -c parser/LexCore.hs -o stage1/parser/LexCore.o -ohi stage1/parser/LexCore.hi <> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -L/opt/local/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -c parser/ParserCore.hs -o stage1/parser/ParserCore.o -ohi stage1/parser/ParserCore.hi <> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -L/opt/local/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -c simplCore/SATMonad.lhs -o stage1/simplCore/SATMonad.o -ohi stage1/simplCore/SATMonad.hi <> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -L/opt/local/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -c stranal/SaAbsInt.lhs -o stage1/stranal/SaAbsInt.o -ohi stage1/stranal/SaAbsInt.hi <> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -L/opt/local/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -c stranal/SaLib.lhs -o stage1/stranal/SaLib.o -ohi stage1/stranal/SaLib.hi <> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -L/opt/local/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -c stranal/StrictAnal.lhs -o stage1/stranal/StrictAnal.o -ohi stage1/stranal/StrictAnal.hi <> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/bin/ghc -optc-O -optc-I/opt/local/include -optc-Iparser -optc-I. -optc-O -H16m -O -I/opt/local/include -L/opt/local/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -c parser/cutils.c -o stage1/parser/cutils.o <> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/bin/ghc -optc-O -optc-I/opt/local/include -optc-Iparser -optc-I. -optc-O -H16m -O -I/opt/local/include -L/opt/local/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -c parser/hschooks.c -o stage1/parser/hschooks.o <> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/bin/ghc -o stage1/ghc-6.8.3 -H16m -O -I/opt/local/include -L/opt/local/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn- orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -package directory -package pretty -package containers -L../compat -lghccompat -no-link-chk -L/opt/local/lib stage1/basicTypes/BasicTypes.o stage1/basicTypes/DataCon.o stage1/basicTypes/Demand.o stage1/basicTypes/Id.o stage1/basicTypes/IdInfo.o stage1/basicTypes/Literal.o stage1/basicTypes/MkId.o stage1/basicTypes/Module.o stage1/basicTypes/Name.o stage1/basicTypes/NameEnv.o stage1/basicTypes/NameSet.o stage1/basicTypes/NewDemand.o stage1/basicTypes/OccName.o stage1/basicTypes/RdrName.o stage1/basicTypes/SrcLoc.o stage1/basicTypes/UniqSupply.o stage1/basicTypes/Unique.o stage1/basicTypes/Var.o stage1/basicTypes/VarEnv.o stage1/basicTypes/VarSet.o stage1/cmm/CLabel.o stage1/cmm/Cmm.o stage1/cmm/CmmBrokenBlock.o stage1/cmm/CmmCPS.o stage1/cmm/CmmCPSGen.o stage1/cmm/CmmCallConv.o stage1/cmm/CmmInfo.o stage1/cmm/CmmLex.o stage1/cmm/CmmLint.o stage1/cmm/CmmLive.o stage1/cmm/CmmOpt.o stage1/cmm/CmmParse.o stage1/cmm/CmmProcPoint.o stage1/cmm/CmmUtils.o stage1/cmm/Dataflow.o stage1/cmm/MachOp.o stage1/cmm/PprC.o stage1/cmm/PprCmm.o stage1/codeGen/Bitmap.o stage1/codeGen/CgBindery.o stage1/codeGen/CgCallConv.o stage1/codeGen/CgCase.o stage1/codeGen/CgClosure.o stage1/codeGen/CgCon.o stage1/codeGen/CgExpr.o stage1/codeGen/CgForeignCall.o stage1/codeGen/CgHeapery.o stage1/codeGen/CgHpc.o stage1/codeGen/CgInfoTbls.o stage1/codeGen/CgLetNoEscape.o stage1/codeGen/CgMonad.o stage1/codeGen/CgParallel.o stage1/codeGen/CgPrimOp.o stage1/codeGen/CgProf.o stage1/codeGen/CgStackery.o stage1/codeGen/CgTailCall.o stage1/codeGen/CgTicky.o stage1/codeGen/CgUtils.o stage1/codeGen/ClosureInfo.o stage1/codeGen/CodeGen.o stage1/codeGen/SMRep.o stage1/coreSyn/CoreFVs.o stage1/coreSyn/CoreLint.o stage1/coreSyn/CorePrep.o stage1/coreSyn/CoreSubst.o stage1/coreSyn/CoreSyn.o stage1/coreSyn/CoreTidy.o stage1/coreSyn/CoreUnfold.o stage1/coreSyn/CoreUtils.o stage1/coreSyn/ExternalCore.o stage1/coreSyn/MkExternalCore.o stage1/coreSyn/PprCore.o stage1/coreSyn/PprExternalCore.o stage1/cprAnalysis/CprAnalyse.o stage1/deSugar/Check.o stage1/deSugar/Coverage.o stage1/deSugar/Desugar.o stage1/deSugar/DsArrows.o stage1/deSugar/DsBinds.o stage1/deSugar/DsCCall.o stage1/deSugar/DsExpr.o stage1/deSugar/DsForeign.o stage1/deSugar/DsGRHSs.o stage1/deSugar/DsListComp.o stage1/deSugar/DsMonad.o stage1/deSugar/DsUtils.o stage1/deSugar/Match.o stage1/deSugar/MatchCon.o stage1/deSugar/MatchLit.o stage1/hsSyn/HsBinds.o stage1/hsSyn/HsDecls.o stage1/hsSyn/HsDoc.o stage1/hsSyn/HsExpr.o stage1/hsSyn/HsImpExp.o stage1/hsSyn/HsLit.o stage1/hsSyn/HsPat.o stage1/hsSyn/HsSyn.o stage1/hsSyn/HsTypes.o stage1/hsSyn/HsUtils.o stage1/iface/BinIface.o stage1/iface/BuildTyCl.o stage1/iface/IfaceEnv.o stage1/iface/IfaceSyn.o stage1/iface/IfaceType.o stage1/iface/LoadIface.o stage1/iface/MkIface.o stage1/iface/TcIface.o stage1/main/BreakArray.o stage1/main/CmdLineParser.o stage1/main/CodeOutput.o stage1/main/Config.o stage1/main/Constants.o stage1/main/DriverMkDepend.o stage1/main/DriverPhases.o stage1/main/DriverPipeline.o stage1/main/DynFlags.o stage1/main/ErrUtils.o stage1/main/Finder.o stage1/main/GHC.o stage1/main/HeaderInfo.o stage1/main/HscMain.o stage1/main/HscStats.o stage1/main/HscTypes.o stage1/main/InteractiveEval.o stage1/main/Main.o stage1/main/PackageConfig.o stage1/main/Packages.o stage1/main/ParsePkgConf.o stage1/main/PprTyThing.o stage1/main/StaticFlags.o stage1/main/SysTools.o stage1/main/TidyPgm.o stage1/nativeGen/AsmCodeGen.o stage1/nativeGen/GraphBase.o stage1/nativeGen/GraphColor.o stage1/nativeGen/GraphOps.o stage1/nativeGen/GraphPpr.o stage1/nativeGen/MachCodeGen.o stage1/nativeGen/MachInstrs.o stage1/nativeGen/MachRegs.o stage1/nativeGen/NCGMonad.o stage1/nativeGen/PositionIndependentCode.o stage1/nativeGen/PprMach.o stage1/nativeGen/RegAllocColor.o stage1/nativeGen/RegAllocInfo.o stage1/nativeGen/RegAllocLinear.o stage1/nativeGen/RegAllocStats.o stage1/nativeGen/RegArchBase.o stage1/nativeGen/RegArchX86.o stage1/nativeGen/RegCoalesce.o stage1/nativeGen/RegLiveness.o stage1/nativeGen/RegSpill.o stage1/nativeGen/RegSpillClean.o stage1/nativeGen/RegSpillCost.o stage1/ndpFlatten/FlattenInfo.o stage1/ndpFlatten/FlattenMonad.o stage1/ndpFlatten/Flattening.o stage1/ndpFlatten/NDPCoreUtils.o stage1/ndpFlatten/PArrAnal.o stage1/parser/Ctype.o stage1/parser/HaddockLex.o stage1/parser/HaddockParse.o stage1/parser/HaddockUtils.o stage1/parser/LexCore.o stage1/parser/Lexer.o stage1/parser/Parser.o stage1/parser/ParserCore.o stage1/parser/ParserCoreUtils.o stage1/parser/RdrHsSyn.o stage1/prelude/ForeignCall.o stage1/prelude/PrelInfo.o stage1/prelude/PrelNames.o stage1/prelude/PrelRules.o stage1/prelude/PrimOp.o stage1/prelude/TysPrim.o stage1/prelude/TysWiredIn.o stage1/profiling/CostCentre.o stage1/profiling/SCCfinal.o stage1/rename/RnBinds.o stage1/rename/RnEnv.o stage1/rename/RnExpr.o stage1/rename/RnHsDoc.o stage1/rename/RnHsSyn.o stage1/rename/RnNames.o stage1/rename/RnSource.o stage1/rename/RnTypes.o stage1/simplCore/CSE.o stage1/simplCore/FloatIn.o stage1/simplCore/FloatOut.o stage1/simplCore/LiberateCase.o stage1/simplCore/OccurAnal.o stage1/simplCore/SAT.o stage1/simplCore/SATMonad.o stage1/simplCore/SetLevels.o stage1/simplCore/SimplCore.o stage1/simplCore/SimplEnv.o stage1/simplCore/SimplMonad.o stage1/simplCore/SimplUtils.o stage1/simplCore/Simplify.o stage1/simplStg/SRT.o stage1/simplStg/SimplStg.o stage1/simplStg/StgStats.o stage1/specialise/Rules.o stage1/specialise/SpecConstr.o stage1/specialise/Specialise.o stage1/stgSyn/CoreToStg.o stage1/stgSyn/StgLint.o stage1/stgSyn/StgSyn.o stage1/stranal/DmdAnal.o stage1/stranal/SaAbsInt.o stage1/stranal/SaLib.o stage1/stranal/StrictAnal.o stage1/stranal/WorkWrap.o stage1/stranal/WwLib.o stage1/typecheck/FamInst.o stage1/typecheck/Inst.o stage1/typecheck/TcArrows.o stage1/typecheck/TcBinds.o stage1/typecheck/TcClassDcl.o stage1/typecheck/TcDefaults.o stage1/typecheck/TcDeriv.o stage1/typecheck/TcEnv.o stage1/typecheck/TcExpr.o stage1/typecheck/TcForeign.o stage1/typecheck/TcGadt.o stage1/typecheck/TcGenDeriv.o stage1/typecheck/TcHsSyn.o stage1/typecheck/TcHsType.o stage1/typecheck/TcInstDcls.o stage1/typecheck/TcMType.o stage1/typecheck/TcMatches.o stage1/typecheck/TcPat.o stage1/typecheck/TcRnDriver.o stage1/typecheck/TcRnMonad.o stage1/typecheck/TcRnTypes.o stage1/typecheck/TcRules.o stage1/typecheck/TcSimplify.o stage1/typecheck/TcTyClsDecls.o stage1/typecheck/TcTyDecls.o stage1/typecheck/TcTyFuns.o stage1/typecheck/TcType.o stage1/typecheck/TcUnify.o stage1/types/Class.o stage1/types/Coercion.o stage1/types/FamInstEnv.o stage1/types/FunDeps.o stage1/types/Generics.o stage1/types/InstEnv.o stage1/types/TyCon.o stage1/types/Type.o stage1/types/TypeRep.o stage1/types/Unify.o stage1/utils/Bag.o stage1/utils/Binary.o stage1/utils/BufWrite.o stage1/utils/Digraph.o stage1/utils/Encoding.o stage1/utils/FastMutInt.o stage1/utils/FastString.o stage1/utils/FastTypes.o stage1/utils/FiniteMap.o stage1/utils/IOEnv.o stage1/utils/ListSetOps.o stage1/utils/Maybes.o stage1/utils/OrdList.o stage1/utils/Outputable.o stage1/utils/Panic.o stage1/utils/Pretty.o stage1/utils/State.o stage1/utils/StringBuffer.o stage1/utils/UniqFM.o stage1/utils/UniqSet.o stage1/utils/Util.o stage1/vectorise/VectBuiltIn.o stage1/vectorise/VectCore.o stage1/vectorise/VectMonad.o stage1/vectorise/VectType.o stage1/vectorise/VectUtils.o stage1/vectorise/Vectorise.o stage1/parser/cutils.o stage1/parser/hschooks.o Undefined symbols: "_SrcLoc_L_con_in", referenced from: _sf0g_info in TcGenDeriv.o ld: symbol(s) not found collect2: ld returned 1 exit status <> make[1]: *** [stage1/ghc-6.8.3] Error 1 make: *** [stage1] Error 1 Error: The following dependencies failed to build: ghc Error: Status 1 encountered during processing. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 10:39:12 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 10:30:09 2008 Subject: [GHC] #2424: Error compiling Crypto-4.1.0 on ghc-6.8.3 Message-ID: <047.5175165ab642b3e70df2d2bcd3e5fe6e@localhost> #2424: Error compiling Crypto-4.1.0 on ghc-6.8.3 -------------------------+-------------------------------------------------- Reporter: kristall | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 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 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 11:31:07 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 11:22:04 2008 Subject: [GHC] #2281: properFraction implemented with modf primitive? In-Reply-To: <044.76024905950f1c976abf1516a4afff90@localhost> References: <044.76024905950f1c976abf1516a4afff90@localhost> Message-ID: <053.e23db49e1b6a579e9e6c967758a3daef@localhost> #2281: properFraction implemented with modf primitive? ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 11:36:39 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 11:27:47 2008 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.b3f14f09e7fbb52fe9ec38b23d256a0a@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.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 11:43:52 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 11:34:49 2008 Subject: [GHC] #2299: Haddock 2 library documentation not available In-Reply-To: <043.5ba8789d725e6cac9d84914b23770e98@localhost> References: <043.5ba8789d725e6cac9d84914b23770e98@localhost> Message-ID: <052.5819cfe9b16ca0dd10d7865712904c22@localhost> #2299: Haddock 2 library documentation not available ---------------------------+------------------------------------------------ Reporter: fons | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks, I've added your haddock2 tarball to the documentation page. I don't think that making haddock2 docs automatically is feasible until we make the move from haddock 0.8 to haddock 2, but hopefully we'll do that for GHC 6.10 anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 11:46:52 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 11:37:49 2008 Subject: [GHC] #2300: GHCi locks up on long input In-Reply-To: <042.b8baab5f9560c1bc1ba314b7db87b0d2@localhost> References: <042.b8baab5f9560c1bc1ba314b7db87b0d2@localhost> Message-ID: <051.c3b61fd71e191f19a8d25b045c968756@localhost> #2300: GHCi locks up on long input --------------------+------------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: I haven't seen this; has anyone else? There's a good chance that moving to editline in 6.10 will fix it anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 12:07:44 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 11:58:41 2008 Subject: [GHC] #2201: "ghc-pkg --user describe '*'" fails with empty user db In-Reply-To: <045.673a6cc9904f9063d50fb7c9230e5305@localhost> References: <045.673a6cc9904f9063d50fb7c9230e5305@localhost> Message-ID: <054.c6ce33ec1fc0333602e7c77ab2ef1cb6@localhost> #2201: "ghc-pkg --user describe '*'" fails with empty user db ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 12:35:39 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 12:26:36 2008 Subject: [GHC] #2326: Make configure check sockaddr.sa_len In-Reply-To: <044.969b2b3410986b0157b91f1ec2efd379@localhost> References: <044.969b2b3410986b0157b91f1ec2efd379@localhost> Message-ID: <053.811d7ca6a9023bf79c2f141766699197@localhost> #2326: Make configure check sockaddr.sa_len -------------------------------+-------------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/network | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the patch, we'll take a look -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 12:37:15 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 12:28:13 2008 Subject: [GHC] #2344: oddity with package prefixes for data constructors In-Reply-To: <044.af9be20076cbcfaeedab766401f29420@localhost> References: <044.af9be20076cbcfaeedab766401f29420@localhost> Message-ID: <053.55d2c8acd6a4d44cfb94e9c2211c4166@localhost> #2344: oddity with package prefixes for data constructors -----------------------------+---------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 13:28:14 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 13:19:18 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.eedeaa49f6da8baf71b595ea3ffbfc16@localhost> #2416: Optimization defeated by merging module into main -----------------------+---------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -----------------------+---------------------------------------------------- Comment (by sedillard): I've filed the original `Storable` weirdness as #2422. In trying to narrow it down some more I also discovered #2420, which may or may not be related. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 15:07:50 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 14:58:48 2008 Subject: [GHC] #2362: allow full import syntax in GHCi In-Reply-To: <051.a17c861cfc196911194c3abd0e428c4d@localhost> References: <051.a17c861cfc196911194c3abd0e428c4d@localhost> Message-ID: <060.a99dff739a42415bfbd325ccf9c57371@localhost> #2362: allow full import syntax in GHCi -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: ghci, import | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 15:13:47 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 15:04:45 2008 Subject: [GHC] #2370: num009 fails on OS X 10.5? In-Reply-To: <053.a1cda8d160d47acd1fc4d157514492c8@localhost> References: <053.a1cda8d160d47acd1fc4d157514492c8@localhost> Message-ID: <062.7e52ac073986938c594a8f0730ebeacc@localhost> #2370: num009 fails on OS X 10.5? -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: lib/Numirc/num009 | Architecture: x86_64 (amd64) Os: MacOS X | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Is it only the threaded2 way that fails? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 15:16:21 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 15:07:18 2008 Subject: [GHC] #2374: MutableByteArray# is slower than Addr# In-Reply-To: <044.46877f1bb530048ac22aec20e1b9d3f2@localhost> References: <044.46877f1bb530048ac22aec20e1b9d3f2@localhost> Message-ID: <053.0fd38f4032abc6b5783495119151fcdb@localhost> #2374: MutableByteArray# is slower than Addr# -------------------------------+-------------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (NCG) | Version: 6.8.2 Severity: minor | Resolution: Keywords: performance array | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 15:24:16 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 15:15:12 2008 Subject: [GHC] #2377: Building ghc-api with profiling fails during install In-Reply-To: <042.889e74131a43acb30fedce713d1f1022@localhost> References: <042.889e74131a43acb30fedce713d1f1022@localhost> Message-ID: <051.b006dcc2fccc86dd00dd74badeb77a0c@localhost> #2377: Building ghc-api with profiling fails during install ----------------------+----------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 15:27:27 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 15:18:24 2008 Subject: [GHC] #2381: :reload with non-existent module zeroes out prompt In-Reply-To: <043.d0f7478d3edab2858f756c0c9a2227a1@localhost> References: <043.d0f7478d3edab2858f756c0c9a2227a1@localhost> Message-ID: <052.5bc961132f649c4e6b6327446d0df6fd@localhost> #2381: :reload with non-existent module zeroes out prompt ---------------------+------------------------------------------------------ Reporter: lumi | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: It doesn't look like the modules are still loaded to me (with 6.8.2 and 6.8.3): {{{ Prelude> :t length length :: [a] -> Int Prelude> :r foo module does not exist > :t length :1:0: Not in scope: `length' > :m + Prelude Prelude> :t length length :: [a] -> Int Prelude> }}} but I that smells like a bug in itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 15:41:09 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 15:32:07 2008 Subject: [GHC] #2382: :reload with non-existent module keeps old bindings around and panics In-Reply-To: <043.8c1c4b6e362c80cea9d1a7e6c6e0f5dc@localhost> References: <043.8c1c4b6e362c80cea9d1a7e6c6e0f5dc@localhost> Message-ID: <052.dd7ec6d5e0e4bff7a6224a35da7ab93e@localhost> #2382: :reload with non-existent module keeps old bindings around and panics ---------------------+------------------------------------------------------ Reporter: lumi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: This is fixed in 6.8.3: {{{ Prelude> let x = 1 Prelude> :r foo module does not exist > :t x :1:0: Not in scope: `x' > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 15:43:31 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 15:34:38 2008 Subject: [GHC] #2388: GHC creates invalid test instruction for 64-bit code In-Reply-To: <056.33dc1f03d68892257923e7c03147f8f1@localhost> References: <056.33dc1f03d68892257923e7c03147f8f1@localhost> Message-ID: <065.97c693d461aacc5621ab9fd8fd6ce29d@localhost> #2388: GHC creates invalid test instruction for 64-bit code -------------------------------+-------------------------------------------- Reporter: MartinGrabmueller | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the report, we'll take a look at what's going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 16:40:14 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 16:31:18 2008 Subject: [GHC] #2375: RTS assertion failure on Vista with -DEBUG In-Reply-To: <043.34dc15d41b49327b2a6587cf172331a9@localhost> References: <043.34dc15d41b49327b2a6587cf172331a9@localhost> Message-ID: <052.635c6c03b45c4530c6e84404a9aeaa4a@localhost> #2375: RTS assertion failure on Vista with -DEBUG -----------------------------------------------+---------------------------- Reporter: dias | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: rts -DEBUG hashtables memory leak | Difficulty: Unknown Testcase: ghci/prog002 | Architecture: x86 Os: Windows | -----------------------------------------------+---------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Reproducible with a validate build where {{{ GhcDebugged=YES }}} is in `mk/validate.mk`: {{{ ghc.exe: internal error: ASSERTION FAILED: file Linker.c, line 1512 (GHC version 6.9.20080705 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 18:16:11 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 18:07:17 2008 Subject: [GHC] #2397: inclusion of Network.Curl causes compiler issues and coredumps In-Reply-To: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> References: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> Message-ID: <053.ab2ec8540d8fe8a5265d9fb90f511fbc@localhost> #2397: inclusion of Network.Curl causes compiler issues and coredumps -------------------------------+-------------------------------------------- Reporter: b7j0c | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 18:17:07 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 18:08:06 2008 Subject: [GHC] #2396: Default class method not inlined In-Reply-To: <048.a2f64c0eb30b8a114516784a80e7f6fb@localhost> References: <048.a2f64c0eb30b8a114516784a80e7f6fb@localhost> Message-ID: <057.c647e2be9ee6b8b11a407e9729008be4@localhost> #2396: Default class method not inlined -----------------------+---------------------------------------------------- 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: | Architecture: Unknown Os: Unknown | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the testcase; we'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 18:22:04 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 18:13:04 2008 Subject: [GHC] #2397: inclusion of Network.Curl causes compiler issues and coredumps In-Reply-To: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> References: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> Message-ID: <053.b65202314a05b92e62ce0fee0a7c1caa@localhost> #2397: inclusion of Network.Curl causes compiler issues and coredumps -------------------------------+-------------------------------------------- Reporter: b7j0c | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: curl, GC | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by dons): * keywords: => curl, GC * cc: dons@galois.com (added) Comment: {{{ $ ghc --make newspage.hs [1 of 1] Compiling Main ( newspage.hs, newspage.o ) Linking newspage ... $ ./newspage newspage: internal error: task 0xda5c30: main thread 1 has been GC'd (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort ./newspage }}} Now, the curl library uses finalisers and MVars to manage resources. I wonder if this is a finaliser issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 18:46:52 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 18:37:51 2008 Subject: [GHC] #2182: ghci session retains instances after :m -Module In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@localhost> References: <044.c09df8f4b72158c8c14035187a5540c9@localhost> Message-ID: <053.cbff641a9d60e55f1a03bc3dd5e0e0f8@localhost> #2182: ghci session retains instances after :m -Module ---------------------+------------------------------------------------------ Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Comment (by igloo): See also #2404 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 18:47:28 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 18:38:26 2008 Subject: [GHC] #2404: GHCi :r does not reset imported class instances In-Reply-To: <060.13e36cf44eb32fbda20596209d243a68@localhost> References: <060.13e36cf44eb32fbda20596209d243a68@localhost> Message-ID: <069.c630c57b7a3379f5c7f98a4ac84fdb55@localhost> #2404: GHCi :r does not reset imported class instances -----------------------------------+---------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | -----------------------------------+---------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: This is a duplicate of #2182 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 18:50:05 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 18:41:04 2008 Subject: [GHC] #2405: Panic when using gtk2hs from ghci In-Reply-To: <047.41535c8adbd9e2dcf8a550a77421cdc4@localhost> References: <047.41535c8adbd9e2dcf8a550a77421cdc4@localhost> Message-ID: <056.2e3e0e72a0d8384064c2b7d3bc182dac@localhost> #2405: Panic when using gtk2hs from ghci ----------------------+----------------------------------------------------- Reporter: wagstaff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > gtk2hs 0.9.13. Take the 'hello world' example that comes with it. Works > fine if compiled by ghc, but try running it from within GHCI: > > Loading package glib-0.9.13 ... : Unknown PEi386 section > name `.reloc' (while processing: C:/haskell/Gtk2Hs/HSglib.o) > : panic! (the 'impossible' happened) > (GHC version 6.8.3 for i386-unknown-mingw32): > loadObj: failed > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > I'll attach hello.hs and the output from a GHCI session. New description: gtk2hs 0.9.13. Take the 'hello world' example that comes with it. Works fine if compiled by ghc, but try running it from within GHCI: {{{ Loading package glib-0.9.13 ... : Unknown PEi386 section name `.reloc' (while processing: C:/haskell/Gtk2Hs/HSglib.o) : panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-mingw32): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'll attach hello.hs and the output from a GHCI session. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 18:50:51 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 18:41:47 2008 Subject: [GHC] #2405: Panic when using gtk2hs from ghci In-Reply-To: <047.41535c8adbd9e2dcf8a550a77421cdc4@localhost> References: <047.41535c8adbd9e2dcf8a550a77421cdc4@localhost> Message-ID: <056.8f28cac5d9a8790e50157be262b4fd8a@localhost> #2405: Panic when using gtk2hs from ghci ----------------------+----------------------------------------------------- Reporter: wagstaff | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 Comment: Thanks for the report; we'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 18:51:20 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 18:42:17 2008 Subject: [GHC] #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto-all' In-Reply-To: <045.6d20356736e6fa3c22e35dd97141b722@localhost> References: <045.6d20356736e6fa3c22e35dd97141b722@localhost> Message-ID: <054.a940dca33afb7f963d2fe3bab4f91aba@localhost> #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto- all' ----------------------+----------------------------------------------------- Reporter: pgavin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > Specifically, the failure happens while compiling > libraries/base/Data/Complex.hs: > > ------ compiler output -------- > /Users/pgavin/local/ghc-6.9/src/ghc-6.9/compiler/stage1/ghc-inplace > -package-name base-3.0 -hide-all-packages -split-objs -i -idist/build -i. > -idist/build/autogen -Idist/build -Iinclude -#include "HsBase.h" -odir > dist/build -hidir dist/build -stubdir dist/build -package ghc-prim-0.1 > -package integer-0.1 -package rts-1.0 -O -package-name base -XMagicHash > -XExistentialQuantification -XRank2Types -XScopedTypeVariables > -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes > -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances > -XPatternSignatures -XStandaloneDeriving -XPatternGuards -XCPP > -idist/build -prof -caf-all -auto-all -hisuf p_hi -hcsuf p_hc -osuf p_o > -H32m -O -H32m -O2 -O2 -Rghc-timing -XGenerics -O2 -Wall -fno-warn- > deprecated-flags -w -c Data/Complex.hs -o dist/build/Data/Complex.p_o > -ohi dist/build/Data/Complex.p_hi > > /var/folders/o2/o2fca1ekG9SKEu61XaHsjE+++TI/-Tmp-/ghc51695_0/ghc51695_0.split__108.s:1256:0: > FATAL:Symbol _base_DataziComplex_zeze_CAF_cc_ccs already defined. > ------------------------------- > > Compilation succeeds if the SPECIALIZE pragmas are removed from the > instance declarations for Num, Fractional, and Floating. New description: Specifically, the failure happens while compiling libraries/base/Data/Complex.hs: compiler output: {{{ /Users/pgavin/local/ghc-6.9/src/ghc-6.9/compiler/stage1/ghc-inplace -package-name base-3.0 -hide-all-packages -split-objs -i -idist/build -i. -idist/build/autogen -Idist/build -Iinclude -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package ghc-prim-0.1 -package integer-0.1 -package rts-1.0 -O -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XPatternSignatures -XStandaloneDeriving -XPatternGuards -XCPP -idist/build -prof -caf-all -auto-all -hisuf p_hi -hcsuf p_hc -osuf p_o -H32m -O -H32m -O2 -O2 -Rghc-timing -XGenerics -O2 -Wall -fno-warn- deprecated-flags -w -c Data/Complex.hs -o dist/build/Data/Complex.p_o -ohi dist/build/Data/Complex.p_hi /var/folders/o2/o2fca1ekG9SKEu61XaHsjE+++TI/-Tmp-/ghc51695_0/ghc51695_0.split__108.s:1256:0: FATAL:Symbol _base_DataziComplex_zeze_CAF_cc_ccs already defined. }}} Compilation succeeds if the SPECIALIZE pragmas are removed from the instance declarations for Num, Fractional, and Floating. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 18:52:19 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 18:43:15 2008 Subject: [GHC] #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto-all' In-Reply-To: <045.6d20356736e6fa3c22e35dd97141b722@localhost> References: <045.6d20356736e6fa3c22e35dd97141b722@localhost> Message-ID: <054.9747f03dfe3211237a9a971988bfa1d3@localhost> #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto- all' ----------------------+----------------------------------------------------- Reporter: pgavin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 Comment: Thanks for the report; we'll have a look at what's going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 19:25:41 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 19:16:39 2008 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.65d543ddc4a6b462f6a0e5cb45e80f06@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ----------------------+----------------------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: This is due to this case of `check'` in `deSugar/Check.lhs`: {{{ -- FIXME: hack to get view patterns through for now | otherwise = ([([],[])],emptyUniqSet) }}} (the `emptyUniqSet` means "the pattern is never used"). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 19:48:46 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 19:39:42 2008 Subject: [GHC] #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" In-Reply-To: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> References: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> Message-ID: <062.d7ea3f708c8af537aa76ae6cd2a0acc6@localhost> #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for a great testcase and explanation of the problem! We'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 5 20:26:24 2008 From: trac at galois.com (GHC) Date: Sat Jul 5 20:17:21 2008 Subject: [GHC] #2416: Optimization defeated by merging module into main In-Reply-To: <048.56959a6c70911c633555f1458314494a@localhost> References: <048.56959a6c70911c633555f1458314494a@localhost> Message-ID: <057.984fb6704056e758ed0add575c4b81da@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: | Architecture: x86_64 (amd64) Os: Linux | -----------------------+---------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 08:29:39 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 08:20:34 2008 Subject: [GHC] #2393: Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <044.a2eb2249d4c87d53c08ed2cb37607972@localhost> References: <044.a2eb2249d4c87d53c08ed2cb37607972@localhost> Message-ID: <053.7b9f8cb7152a6b8f8ce36ecb3104b2ff@localhost> #2393: Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/pretty | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by igloo): `HughesPJ.patch` has been applied -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 12:58:17 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 12:49:10 2008 Subject: [GHC] #2393: Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement In-Reply-To: <044.a2eb2249d4c87d53c08ed2cb37607972@localhost> References: <044.a2eb2249d4c87d53c08ed2cb37607972@localhost> Message-ID: <053.6d54d7fa9625b2354e5bd031d42c842f@localhost> #2393: Text.PrettyPrint.HughesPJ: Bug fixes, performance improvement ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/pretty | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed * milestone: => 6.10.1 Comment: And I've now applied the changes in `HughesPJ_2.patch`: {{{ Thu Jun 26 17:16:47 BST 2008 benedikt.huber@gmail.com * Adds a `zeroWidthText' primitive to the library, in order to create text which occupies no space (e.g. html or latex tags). Sun Jul 6 14:30:05 BST 2008 Ian Lynagh * Merge the rest of Benedikt Huber's "Fix bug #1337, #2391 1,2" Sun Jul 6 14:49:23 BST 2008 Ian Lynagh * Merge the rest of Benedikt Huber's "Fix HughesPJ developer documentation." Sun Jul 6 16:13:35 BST 2008 Ian Lynagh * Fix warnings and change a comment that was confusing haddock }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 12:59:13 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 12:50:07 2008 Subject: [GHC] #1217: Add zeroText to Text.PrettyPrint.HughesPJ In-Reply-To: <043.d55f62463ee03363d7e94d2b90cbcc28@localhost> References: <043.d55f62463ee03363d7e94d2b90cbcc28@localhost> Message-ID: <052.fac864a38bbec73e557424609f41c2a9@localhost> #1217: Add zeroText to Text.PrettyPrint.HughesPJ ------------------------------+--------------------------------------------- Reporter: neil | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/pretty | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * component: libraries/base => libraries/pretty * resolution: => fixed Comment: Fixed by {{{ Thu Jun 26 17:16:47 BST 2008 benedikt.huber@gmail.com * Adds a `zeroWidthText' primitive to the library, in order to create text which occupies no space (e.g. html or latex tags). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:01:07 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 12:52:01 2008 Subject: [GHC] #1337: Fix wrong indentation from Text.PrettyPrint.HughesPJ fill (fcat and fsep) In-Reply-To: <050.0d1c36f5d6cac580edd71d8a018225c6@localhost> References: <050.0d1c36f5d6cac580edd71d8a018225c6@localhost> Message-ID: <059.965ddbee0529471558e7c217e235eb9e@localhost> #1337: Fix wrong indentation from Text.PrettyPrint.HughesPJ fill (fcat and fsep) ------------------------------+--------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/pretty | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: Pp003 | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed * milestone: 6.10 branch => 6.10.1 Comment: Fixed as part of #2393. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:19:16 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:10:13 2008 Subject: [GHC] #1176: Infinite loop when printing error message In-Reply-To: <064.2f219b840bdf4c0010ac5cb2a55fa8db@localhost> References: <064.2f219b840bdf4c0010ac5cb2a55fa8db@localhost> Message-ID: <073.e58d69db9a597d2a9ae5e6a63311e003@localhost> #1176: Infinite loop when printing error message ---------------------------------------+------------------------------------ Reporter: Paul_Berry@alumni.hmc.edu | Owner: thorkilnaur Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail177 | Architecture: Multiple Os: Multiple | ---------------------------------------+------------------------------------ Comment (by igloo): OK, so I think this is fixed in the standalone pretty library (#2393). As Thorkil says, GHC should really use this rather than having its own copy. I haven't compared the two libraries, but the only thing I can think of that would be standing in the way of that is that we need the library to understand GHC's `FastString`s. I think that the missing piece of the puzzle is a utf8-bytestring library, which GHC could use itself (wrapping it in something to give it a uniq) and pretty would be able to accept (with its `PStr` constructor). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:24:30 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:15:27 2008 Subject: [GHC] #669: negative indentation in Text.PrettyPrint.HughesPJ In-Reply-To: <067.a4757cf71545173f1debde93261f7d5b@localhost> References: <067.a4757cf71545173f1debde93261f7d5b@localhost> Message-ID: <076.b83baa8df09038f6cca358a1b42aa6a6@localhost> #669: negative indentation in Text.PrettyPrint.HughesPJ ------------------------------------------+--------------------------------- Reporter: waldmann@imn.htwk-leipzig.de | Owner: thorkilnaur Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: libraries/pretty | Version: 6.4.1 Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: pp1 | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Marking this as invalid, as per #2393. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:29:08 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:20:09 2008 Subject: [GHC] #2340: Improve Template Haskell error recovery In-Reply-To: <046.869c20c62dd7ab567cd622b9021b6c1e@localhost> References: <046.869c20c62dd7ab567cd622b9021b6c1e@localhost> Message-ID: <055.ba4c107c213818b0b15f850bb08fc747@localhost> #2340: Improve Template Haskell error recovery ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:29:18 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:20:12 2008 Subject: [GHC] #2333: Emit a warning if an INLINE function is a loop breaker In-Reply-To: <046.23407b4f66367aefddc60efec387ceb9@localhost> References: <046.23407b4f66367aefddc60efec387ceb9@localhost> Message-ID: <055.5c35b0d4d78b70237d6c95a333f37613@localhost> #2333: Emit a warning if an INLINE function is a loop breaker -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:29:29 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:20:29 2008 Subject: [GHC] #2425: Crash constructing a ClockTime too far into the future Message-ID: <047.a9abcd98ff397aed55603869406274e9@localhost> #2425: Crash constructing a ClockTime too far into the future -------------------------+-------------------------------------------------- Reporter: wagstaff | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Per summary. Type this in to GHCi: `show (TOD 12312323123 0)` and it crashes. Similar bad behaviour with compiled code. Ah, looks like it goes wrong when the bits wrap. `(TOD 2147483647 0)` is OK, but `(TOD 2147483648 0)` falls apart. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:33:41 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:24:34 2008 Subject: [GHC] #2424: Error compiling Crypto-4.1.0 on ghc-6.8.3 In-Reply-To: <047.5175165ab642b3e70df2d2bcd3e5fe6e@localhost> References: <047.5175165ab642b3e70df2d2bcd3e5fe6e@localhost> Message-ID: <056.21df16e43fdffde015fa4940af2d8227@localhost> #2424: Error compiling Crypto-4.1.0 on ghc-6.8.3 ----------------------+----------------------------------------------------- Reporter: kristall | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Old description: > ghc-6.8.3: panic! (the 'impossible' happened) > (GHC version 6.8.3 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 New description: {{{ ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 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 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:38:05 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:28:59 2008 Subject: [GHC] #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin In-Reply-To: <047.918ccc59a875951e79ffd2348c4375d6@localhost> References: <047.918ccc59a875951e79ffd2348c4375d6@localhost> Message-ID: <056.28784302eeeaa1d821876f625e7b1993@localhost> #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin --------------------------+------------------------------------------------- Reporter: jimwhite | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:39:19 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:30:14 2008 Subject: [GHC] #2422: Unrelated instance foils optimizer In-Reply-To: <048.44d8fab6eafad69dae1f639aff0c37d2@localhost> References: <048.44d8fab6eafad69dae1f639aff0c37d2@localhost> Message-ID: <057.80374ddf037a39c48f3f542e02183ee5@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: | Architecture: x86 Os: Linux | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Good testcase, thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:39:51 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:30:45 2008 Subject: [GHC] #2421: HSQL build reports exposed module as hidden, and fails In-Reply-To: <050.3dd63c14c5864d1033083a7ce5dd983d@localhost> References: <050.3dd63c14c5864d1033083a7ce5dd983d@localhost> Message-ID: <059.0308aca7a7a48c4afb823e78dbba8a38@localhost> #2421: HSQL build reports exposed module as hidden, and fails -------------------------------+-------------------------------------------- Reporter: volker-wysk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 6.8.2 Severity: normal | Resolution: Keywords: modules, exposure | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > Hello. I'm trying to install hsql-1.7, and it needs some library "old- > time", which appears to be hidden. However, when exposing this library. > the compiler and the HSQL build script disagree on whether old-time is > exposed. > > Configure works: > /tmp/hsql-1.7 $ runghc Setup.lhs configure > Configuring hsql-1.7... > Warning: No license-file field. > > Exposing old-time succeeds: > > /tmp/hsql-1.7 $ sudo bash > /tmp/hsql-1.7 % ghc-pkg expose old-time > Saving old package config file... done. > Writing new package config file... done. > > /tmp/hsql-1.7 % ghc-pkg describe old-time | egrep exposed > exposed: True > exposed-modules: System.Time > > But the build process somehow gets the idea that old-time is hidden: > > /tmp/hsql-1.7 % runghc Setup.lhs build > Preprocessing library hsql-1.7... > Building hsql-1.7... > > Database/HSQL.hsc:66:7: > Could not find module `System.Time': > it is a member of package old-time-1.0.0.0, which is hidden New description: Hello. I'm trying to install hsql-1.7, and it needs some library "old- time", which appears to be hidden. However, when exposing this library. the compiler and the HSQL build script disagree on whether old-time is exposed. Configure works: {{{ /tmp/hsql-1.7 $ runghc Setup.lhs configure Configuring hsql-1.7... Warning: No license-file field. }}} Exposing old-time succeeds: {{{ /tmp/hsql-1.7 $ sudo bash /tmp/hsql-1.7 % ghc-pkg expose old-time Saving old package config file... done. Writing new package config file... done. /tmp/hsql-1.7 % ghc-pkg describe old-time | egrep exposed exposed: True exposed-modules: System.Time }}} But the build process somehow gets the idea that old-time is hidden: {{{ /tmp/hsql-1.7 % runghc Setup.lhs build Preprocessing library hsql-1.7... Building hsql-1.7... Database/HSQL.hsc:66:7: Could not find module `System.Time': it is a member of package old-time-1.0.0.0, which is hidden }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:41:41 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:32:37 2008 Subject: [GHC] #2421: HSQL build reports exposed module as hidden, and fails In-Reply-To: <050.3dd63c14c5864d1033083a7ce5dd983d@localhost> References: <050.3dd63c14c5864d1033083a7ce5dd983d@localhost> Message-ID: <059.a323025dbdad3f3f240dd5dd6c96f50e@localhost> #2421: HSQL build reports exposed module as hidden, and fails -------------------------------+-------------------------------------------- Reporter: volker-wysk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: modules, exposure | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: It sounds like the problem is that the `.cabal` file doesn't have a dependency on `old-time`. This is needed as Cabal hides all packages that aren't depended on. If that's not the problem, please reopen this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 13:53:00 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:43:53 2008 Subject: [GHC] #2420: Multi-method classes are inlined/specialized better than single-method classes for strict types In-Reply-To: <048.3992ed493cb4d18feeaa36522408a406@localhost> References: <048.3992ed493cb4d18feeaa36522408a406@localhost> Message-ID: <057.bef86aeccc5aaaa742e18bea3d406855@localhost> #2420: Multi-method classes are inlined/specialized better than single-method classes for strict types -----------------------+---------------------------------------------------- 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: | Architecture: Unknown Os: Linux | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report and a good testcase. We'll have a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 14:03:45 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:54:39 2008 Subject: [GHC] #2418: desugaring type function application to constraint makes bug disappear In-Reply-To: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> References: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> Message-ID: <053.9148da479c1a17974db9b6d95f617367@localhost> #2418: desugaring type function application to constraint makes bug disappear -------------------------------------+-------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: type families | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 14:08:04 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 13:58:57 2008 Subject: [GHC] #2417: using GADT syntax for an associated datatype causes GHC to panic In-Reply-To: <044.b2b50269f86bb871052f27e2bada0368@localhost> References: <044.b2b50269f86bb871052f27e2bada0368@localhost> Message-ID: <053.e5286a7896a2a9193c76364069d14aec@localhost> #2417: using GADT syntax for an associated datatype causes GHC to panic ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: You certainly shouldn't get a panic; thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 14:15:47 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 14:06:41 2008 Subject: [GHC] #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. In-Reply-To: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> References: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> Message-ID: <052.d11d6c8e701c3519fcf06cc236a762e0@localhost> #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: If you have any sort of testcase then that might help track down the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 14:18:29 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 14:09:25 2008 Subject: [GHC] #2403: caching for runghc (runhaskell) In-Reply-To: <043.9d7c5bf2b4bb2224d8bf54e38166489a@localhost> References: <043.9d7c5bf2b4bb2224d8bf54e38166489a@localhost> Message-ID: <052.3786ac097b3b0c8ef3b1b3f94d6f008f@localhost> #2403: caching for runghc (runhaskell) -----------------------------+---------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => _|_ Comment: Security is definitely a concern here. And you need to make sure that you have exactly the same source code, inlinings from imports, appropriate commandline flags, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 14:29:37 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 14:20:31 2008 Subject: [GHC] #2345: :browse limitations (browsing virtual namespaces, listing namespaces) In-Reply-To: <044.b5a5c824d7248b2cf228e752ae42706b@localhost> References: <044.b5a5c824d7248b2cf228e752ae42706b@localhost> Message-ID: <053.aa8df00907178d063fe450d1f05faa62@localhost> #2345: :browse limitations (browsing virtual namespaces, listing namespaces) -----------------------------+---------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 15:23:08 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 15:14:00 2008 Subject: [GHC] #2426: ghc-pkg should treat package.conf as UTF8 Message-ID: <044.52bda3c925309f2ed287ef35b894919b@localhost> #2426: ghc-pkg should treat package.conf as UTF8 -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- ghc-pkg should treat package.conf as UTF8. According to #2389 it doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 15:23:46 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 15:14:39 2008 Subject: [GHC] #2389: ghc-pkg can't use path with spaces. In-Reply-To: <047.a6573860c689d364f0ae864a46f4e6e9@localhost> References: <047.a6573860c689d364f0ae864a46f4e6e9@localhost> Message-ID: <056.ba807e560b679d85d47ceb26c9a2cf8f@localhost> #2389: ghc-pkg can't use path with spaces. ----------------------+----------------------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: I've opened #2426 for the UTF8 issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 15:34:39 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 15:25:36 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code In-Reply-To: <043.846fc3dda75c676953124f0b37d400e0@localhost> References: <043.846fc3dda75c676953124f0b37d400e0@localhost> Message-ID: <052.74e4ea8fb734b3a5652cca3049c84330@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code ----------------------+----------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: _|_ => 6.10.1 Comment: Here's `main/HeaderInfo.hs:getOptionsFromFile` with some extra debugging prints: {{{ getOptionsFromFile :: DynFlags -> FilePath -- input file -> IO [Located String] -- options, if any getOptionsFromFile dflags filename = Control.Exception.bracket (openBinaryFile filename ReadMode) (hClose) (\handle -> do buf <- hGetStringBufferBlock handle blockSize opts <- loop handle buf if showSDoc (ppr opts) == "[[-, X, C, P, P], [-, f, v, e, c, t, o, r, i, s, e]]" then do print ("B4", filename) print ("B5", lexemeToString buf (len buf)) putStrLn "B6" else return () return opts) where blockSize = 1024 loop handle buf | len buf == 0 = return [] | otherwise = do -- print ("B1", lexemeToString buf (len buf)) case getOptions' dflags buf filename of (Nothing, opts) -> do print ("B2", showSDoc (ppr opts)) return opts (Just buf', opts) -> do print ("B3", showSDoc (ppr opts)) nextBlock <- hGetStringBufferBlock handle blockSize newBuf <- appendStringBuffers buf' nextBlock if len newBuf == len buf then return opts else do opts' <- loop handle newBuf return (opts++opts') }}} and here's some output while compiling dph: {{{ V2 ("B3","[[-, X, C, P, P]]") ("B2","[[-, f, v, e, c, t, o, r, i, s, e]]") ("B4","./Data/Array/Parallel/Lifted/PArray.hs") ("B5","{-# LANGUAGE CPP #-}{-# OPTIONS -fvectorise #-}\nmodule Data.Array.Parallel.Prelude.Int (\n P.Int, (+), (-), (*), div, mod, intSquareRoot, enumFromToP, intSumP, \n (==), (/=), (<=), (<), (>=), (>)\n) where\n\nimport Data.Array.Parallel.Prelude.Base\nimport Data.Array.Parallel.Prelude.Base.Int\n\nimport qualified Prelude as P\nimport Prelude (Int)\n\ninfixl 7 *\ninfixl 6 +, -\ninfix 4 ==, /=, <, <=, >, >=\n\n(==), (/=), (<), (<=), (>), (>=) :: Int -> Int -> P.Bool\n(==) = eq\n(/=) = neq\n(<) = lt\n(<=) = le\n(>) = gt\n(>=) = ge\n\n(*) :: Int -> Int -> Int\n(*) = mult\n\n(+) :: Int -> Int -> Int\n(+) = plus\n\n(-) :: Int -> Int -> Int\n(-) = minus\n\ndiv:: Int -> Int -> Int\ndiv = intDiv\n\nmod:: Int -> Int -> Int\nmod = intMod\n?1\NUL\STX+\NUL\NUL\NULw\NUL\SOH\NUL\NUL\NUL\NUL\NUL\NUL!\NUL\STX+\NUL\NUL\t\NUL0\NUL\STX+\NUL\NULIz\NUL\SOH\NUL\NUL\NUL\NUL\n\NUL!\NUL\STX+\NUL\NUL\NUL\NUL]\NUL\NUL\NUL\NUL\NUL!\NUL!\NUL\STX+\NUL\NUL!\NUL\NUL\NUL\NUL\NUL\NUL\NUL@\NUL]\NUL\NUL\NUL\NUL\NULQ\NUL!\NUL\STX+\NUL\NUL9\NUL!\NUL\STX+\NUL\NUL\NUL\674\NUL\NUL\NUL\NUL\NULx\NUL!\NUL\STX+\NUL\NULi\NUL!\NUL\STX+\NUL\NUL\NUL\738\NUL\NUL\NUL\NUL\NULk#\NUL\STX+\NUL\NUL\EOT\NUL\NUL\NUL\NUL\NUL\NUL\NUL{\STX\NUL\NUL\NUL\NUL\NUL\NUL|\STX\NUL\NUL\NUL\NUL\NUL\NUL|1\NUL\STX+\NUL\NULI\NUL+\NUL\STX+\NUL\NUL\NUL\NUL!\NUL\STX+\NUL\NUL\NUL\802\NUL\NUL\NUL\NUL\NULk#\NUL\STX+\NUL\NUL\EOT\NUL\NUL\NUL\NUL\NUL\NUL\NUL\NUL\STX\NUL\NUL\NUL\NUL\NUL\NUL\NUL\738\NUL\NUL\NUL\NUL\NULk#\NUL\STX+\NUL\NUL\EOT\NUL\NUL\NUL\NUL\NUL\NUL\NUL|\STX\NUL\NUL\NUL\NUL\NUL\NUL}\STX\NUL\NUL\NUL\NUL\NUL\NUL\NUL1\NUL\STX+\NUL\NUL\NULy\NUL\SOH\NUL\NUL\NUL\NUL\NUL\NUL!\NUL\STX+\NUL\NUL\NULh1\NUL\STX+\NUL\NUL9z\NUL\SOH\NUL\NUL\NUL\NUL\NUL\NUL!\NUL\STX+\NUL\NUL)J1\NUL\STX+\NUL\NUL\NULw\NUL\SOH\NUL\NUL\NUL\NUL\NUL\NUL!\NUL") B6 }}} So we've tried to read `Data/Array/Parallel/Lifted/PArray.hs` but instead we have got `{-# LANGUAGE CPP #-}` followed by the contents of `Data/Array/Parallel/Prelude/Int.hs`. We don't know quite what's going on yet, but we're closer now, so I'm optimistically putting this bug back into the 6.10.1 milestone. I think it's likely that #2240 is caused by the same thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 6 16:29:01 2008 From: trac at galois.com (GHC) Date: Sun Jul 6 16:19:58 2008 Subject: [GHC] #2345: :browse limitations (browsing virtual namespaces, listing namespaces) In-Reply-To: <044.b5a5c824d7248b2cf228e752ae42706b@localhost> References: <044.b5a5c824d7248b2cf228e752ae42706b@localhost> Message-ID: <053.c44adb7d66d09323a010dbfb0f1078f9@localhost> #2345: :browse limitations (browsing virtual namespaces, listing namespaces) -----------------------------+---------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by claus): The new ghc-paths package provides a work-around for part 2a, at least: http://www.haskell.org/haskellwiki/GHC/GHCi#Package_and_documentation_lookup_in_GHCi .2C_via_ghc-paths -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 01:19:33 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 01:10:29 2008 Subject: [GHC] #2403: caching for runghc (runhaskell) In-Reply-To: <043.9d7c5bf2b4bb2224d8bf54e38166489a@localhost> References: <043.9d7c5bf2b4bb2224d8bf54e38166489a@localhost> Message-ID: <052.9093ae8dd6176c5298f793b2a44ba56d@localhost> #2403: caching for runghc (runhaskell) -----------------------------+---------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Comment (by jsnx): Replying to [comment:4 igloo]: > Security is definitely a concern here. And you need to make sure that you have exactly the same source code, inlinings from imports, appropriate commandline flags, etc. How much of this will `--make` actually handle? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 01:20:00 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 01:10:54 2008 Subject: [GHC] #2403: caching for runghc (runhaskell) In-Reply-To: <043.9d7c5bf2b4bb2224d8bf54e38166489a@localhost> References: <043.9d7c5bf2b4bb2224d8bf54e38166489a@localhost> Message-ID: <052.901d51390e5ea5b7cf5742391e91aaec@localhost> #2403: caching for runghc (runhaskell) -----------------------------+---------------------------------------------- Reporter: jsnx | Owner: jsnx Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by jsnx): * owner: => jsnx -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 01:36:59 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 01:27:55 2008 Subject: [GHC] #2417: using GADT syntax for an associated datatype causes GHC to panic In-Reply-To: <044.b2b50269f86bb871052f27e2bada0368@localhost> References: <044.b2b50269f86bb871052f27e2bada0368@localhost> Message-ID: <053.ce4ca3619c16bf397572e7f2519799dd@localhost> #2417: using GADT syntax for an associated datatype causes GHC to panic ----------------------+----------------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by chak): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 03:52:10 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 03:43:02 2008 Subject: [GHC] #2425: Crash constructing a ClockTime too far into the future In-Reply-To: <047.a9abcd98ff397aed55603869406274e9@localhost> References: <047.a9abcd98ff397aed55603869406274e9@localhost> Message-ID: <056.207462b3e262c238501321783474f687@localhost> #2425: Crash constructing a ClockTime too far into the future -------------------------------+-------------------------------------------- Reporter: wagstaff | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------------+-------------------------------------------- Comment (by wagstaff): Google suggests that System.Time may be deprecated (though this is not at all clear to me); and it turns out that I can do what I want with posixSecondsToUTCTime anyway. So this isn't important to me, and if System.Time really is deprecated then perhaps it's not important to anyone? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 04:43:25 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 04:34:17 2008 Subject: [GHC] #2370: num009 fails on OS X 10.5? In-Reply-To: <053.a1cda8d160d47acd1fc4d157514492c8@localhost> References: <053.a1cda8d160d47acd1fc4d157514492c8@localhost> Message-ID: <062.88b4ed875b49e39f23b30cf3502ad556@localhost> #2370: num009 fails on OS X 10.5? --------------------------------+------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: lib/Numeric/num009 | Architecture: x86_64 (amd64) Os: MacOS X | --------------------------------+------------------------------------------- Changes (by batterseapower): * testcase: lib/Numirc/num009 => lib/Numeric/num009 Comment: No, it fails in all ways. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 04:46:17 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 04:37:08 2008 Subject: [GHC] #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" In-Reply-To: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> References: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> Message-ID: <062.857a3fac3c5fc1d5bccf7d3b54c7b923@localhost> #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by simonpj): Thanks for the report. I've investigated a little, and I think I know what's going on. Needs more thought. Note to self: the write to `tcg_type_env_var` (line 783 in `TcRnDriver` is coming too late). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 06:12:45 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 06:03:38 2008 Subject: [GHC] #2396: Default class method not inlined In-Reply-To: <048.a2f64c0eb30b8a114516784a80e7f6fb@localhost> References: <048.a2f64c0eb30b8a114516784a80e7f6fb@localhost> Message-ID: <057.4a758a61c1c6ac3b441b242d8bf9becf@localhost> #2396: Default class method not inlined --------------------------------------+------------------------------------- Reporter: sedillard | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * type: bug => run-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 06:36:36 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 06:27:26 2008 Subject: [GHC] #2414: GHCi / GHC segfault : type checker problem In-Reply-To: <043.07db70092bd8811bd5934348939d4781@localhost> References: <043.07db70092bd8811bd5934348939d4781@localhost> Message-ID: <052.b0a7e55955ed16f19dee24047cb632a4@localhost> #2414: GHCi / GHC segfault : type checker problem -----------------------------------------+---------------------------------- Reporter: dons | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2414 | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T2414 * owner: => igloo * type: bug => merge Comment: Thank you for finding this. Very embarrassing, because it's such a simple program (no type classes, no functional dependencies, no type functions...). The extra complexity due to boxy types led to a missing occurs check. This is the patch: {{{ Mon Jul 7 11:32:01 BST 2008 simonpj@microsoft.com * Fix Trac #2414: occurrs check was missed }}} Merge to 6.8.4 if/when we release it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 06:37:25 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 06:28:15 2008 Subject: [GHC] #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable In-Reply-To: <053.8442170ef9b4829325987986f707598b@localhost> References: <053.8442170ef9b4829325987986f707598b@localhost> Message-ID: <062.31160eeee0ce876bdded1fc87badc5e4@localhost> #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Template Haskell | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: th/T2386 | Architecture: x86_64 (amd64) Os: MacOS X | ------------------------------+--------------------------------------------- Changes (by simonpj): * testcase: => th/T2386 * owner: simonpj => igloo * type: bug => merge Comment: Fixed by switching off data type pruning if `-XTemplateHaskell` is enabled. {{{ Mon Jul 7 11:29:41 BST 2008 simonpj@microsoft.com * Fix Trac #2386: exceesive trimming of data types with Template Haskell }}} Merge to 6.8.4 if/when we release it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 06:40:44 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 06:31:38 2008 Subject: [GHC] #1736: GHC doesn't spot OPTIONS_GHC pragmas after 1k of comments In-Reply-To: <044.d708ffe9ab9e53de96c4a2740c911bb4@localhost> References: <044.d708ffe9ab9e53de96c4a2740c911bb4@localhost> Message-ID: <053.b679783774fc02f38df16ca8ee0c7c72@localhost> #1736: GHC doesn't spot OPTIONS_GHC pragmas after 1k of comments -----------------------+---------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Driver | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: pragma001 | Architecture: Unknown Os: Unknown | -----------------------+---------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Mon Jul 7 10:58:36 BST 2008 Simon Marlow * FIX #1736, and probably #2169, #2240 appendStringBuffer was completely bogus - the arguments to copyArray were the wrong way around, which meant that corruption was very likely to occur by overwriting the end of the buffer in the first argument. This definitely fixes #1736. The other two bugs, #2169 and #2240 are harder to reproduce, but we can see how they could occur: in the case of #2169, the options parser is seeing the contents of an old buffer, and in the case of #2240, appendStringBuffer is corrupting an interface file in memory, since strng buffers and interface files are both allocated in the pinned region of memory. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 06:42:50 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 06:33:43 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code In-Reply-To: <043.846fc3dda75c676953124f0b37d400e0@localhost> References: <043.846fc3dda75c676953124f0b37d400e0@localhost> Message-ID: <052.dca63e59772cfc76c75dbc7320311240@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code ----------------------+----------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Thanks to Ian's investigations, I finally found the culprit. {{{ Mon Jul 7 10:58:36 BST 2008 Simon Marlow * FIX #1736, and probably #2169, #2240 appendStringBuffer was completely bogus - the arguments to copyArray were the wrong way around, which meant that corruption was very likely to occur by overwriting the end of the buffer in the first argument. This definitely fixes #1736. The other two bugs, #2169 and #2240 are harder to reproduce, but we can see how they could occur: in the case of #2169, the options parser is seeing the contents of an old buffer, and in the case of #2240, appendStringBuffer is corrupting an interface file in memory, since strng buffers and interface files are both allocated in the pinned region of memory. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 06:44:30 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 06:35:25 2008 Subject: [GHC] #2240: Random "interface file corrupt" while building In-Reply-To: <044.8830de44dcf6496f1725044215132bc4@localhost> References: <044.8830de44dcf6496f1725044215132bc4@localhost> Message-ID: <053.227ad72a4d6bb38433edc79c8dcdba49@localhost> #2240: Random "interface file corrupt" while building ----------------------+----------------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: The patch below very probably fixes this bug, so I'm optimistically closing it. {{{ Mon Jul 7 10:58:36 BST 2008 Simon Marlow * FIX #1736, and probably #2169, #2240 appendStringBuffer was completely bogus - the arguments to copyArray were the wrong way around, which meant that corruption was very likely to occur by overwriting the end of the buffer in the first argument. This definitely fixes #1736. The other two bugs, #2169 and #2240 are harder to reproduce, but we can see how they could occur: in the case of #2169, the options parser is seeing the contents of an old buffer, and in the case of #2240, appendStringBuffer is corrupting an interface file in memory, since strng buffers and interface files are both allocated in the pinned region of memory. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 12:19:12 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 12:10:04 2008 Subject: [GHC] #2427: Allow compilation of source from stdin Message-ID: <044.abbe9ae8909931700fcc95de3eb51afe@localhost> #2427: Allow compilation of source from stdin --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Hiya. So, as part of how the Hint library (a wrapper around the GHC API operates), it has to generate a file in /tmp containing module boilerplate and the supplied code of interesting, and it then evaluates it*. But for my mueval code (which uses Hint), I'd like to disable file creation entirely through resource limits, and so it would be much better for Hint if it could instead just create the string and pipe it right into GHC. This avoids any file creation (which may not be possible for any number of reasons besides resource limits, like LiveCDs or read-only disks). But in my experiments, and those of #haskell, GHC determinedly blocks any attempt - you can't simply pipe it in with |, you can't use /dev/stdin, can't use one of the file descriptors, etc. So what I would like is to be able to do: $ echo "import qualified Data.List\nmain = print $ Data.List.intersperse 'f' "ggggg" "fgfgfgfgfgfg" (Why can't I use ghc -e? Doesn't do imports of any kind, and if mueval is to replicate lambdabot's functionality, it needs to be able to import many libraries qualified.**) * It has to do this roundabout hackish thing because alas, the GHC API seems to allow functions from any module whatsoever to be called as long as they are named qualified, even if the appropriate module had not been allowed in. The magnitude of this as a security hole is obvious. ** Why qualified? Too many of the basic libraries have name collisions. Can't remove them, as it'd be silly to have only half the base libraries or whatever, but can't just blindly import them as you'll get conflicts. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 12:42:19 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 12:33:09 2008 Subject: [GHC] #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable In-Reply-To: <053.8442170ef9b4829325987986f707598b@localhost> References: <053.8442170ef9b4829325987986f707598b@localhost> Message-ID: <062.4d02329e9f2d3bdf4a8ee588922041a8@localhost> #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Template Haskell | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: th/T2386 | Architecture: x86_64 (amd64) Os: MacOS X | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 12:44:12 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 12:35:02 2008 Subject: [GHC] #2414: GHCi / GHC segfault : type checker problem In-Reply-To: <043.07db70092bd8811bd5934348939d4781@localhost> References: <043.07db70092bd8811bd5934348939d4781@localhost> Message-ID: <052.cdaec6795835eea83f5efbcbac1f8324@localhost> #2414: GHCi / GHC segfault : type checker problem -----------------------------------------+---------------------------------- Reporter: dons | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.8 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2414 | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 14:32:06 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 14:22:59 2008 Subject: [GHC] #2428: bad error message for multiple modules in the same file Message-ID: <051.032da37103557c880f77cd3249b27a59@localhost> #2428: bad error message for multiple modules in the same file -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- consider this file: {{{ module MyMod where foo :: Int foo = 3 module Main (main) where import MyMod (foo) main :: IO () main = print foo }}} The layout rule dictates that this parses properly (the first module clause ends when the second "module" gives a parse error, just like "in" ends a "let"); this gets the same error: {{{ module MyMod where { foo :: Int; foo = 3 } module Main (main) where { import MyMod (foo); main :: IO (); main = print foo } }}} The Haskell98 report doesn't say anything about how modules are expected to be laid out in files, so I had assumed it would work. The error is {{{ parse error on input `module' }}} (except if Main comes before `MyMod`, ''and'' --make is used with ghc, we get {{{ Could not find module `MyMod': Use -v to see a list of the files searched for. }}} even though `MyMod` is clearly (to a human) in that very file.) It took me a long time to figure out what was wrong and what I had to do. Admittedly I'm only slightly interested in GHC implementing support to allow this, since if multiple files are involved at all it causes module- finding trouble (obviously to me now); mostly I just want a good error message, maybe something like "Each file must contain exactly one module. Any module intended to be imported must be in an appropriately named file, e.g. module `Module.Name' goes in `Module/Name.hs'." ( This happened to me a long time ago... but I was reminded by #2427 ) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 14:33:22 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 14:24:15 2008 Subject: [GHC] #2427: Allow compilation of source from stdin In-Reply-To: <044.abbe9ae8909931700fcc95de3eb51afe@localhost> References: <044.abbe9ae8909931700fcc95de3eb51afe@localhost> Message-ID: <053.6f18fe7ce49756486cd75f83f1f538ec@localhost> #2427: Allow compilation of source from stdin --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Changes (by Isaac Dupree): * cc: id@isaac.cedarswampstudios.org (added) Comment: I ran into this before too. I think it was when I was trying to run QuickCheck stuff with some script... Anyway, that could work fine for a single module, but GHC doesn't allow multiple modules in the same file, if you want to allow executing anything fancy like that using only stdin ( reminding me to put #2428 ). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 7 16:14:07 2008 From: trac at galois.com (GHC) Date: Mon Jul 7 16:05:00 2008 Subject: [GHC] #2427: Allow compilation of source from stdin In-Reply-To: <044.abbe9ae8909931700fcc95de3eb51afe@localhost> References: <044.abbe9ae8909931700fcc95de3eb51afe@localhost> Message-ID: <053.e482e97304f536a16a016f302c5f5904@localhost> #2427: Allow compilation of source from stdin --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by guest): Actually, I just remembered - this could be useful in Darcs as well. Currently Darcs's configure script generates a bunch of files with different module & FFI imports (corresponding to various functionalities to enable/disable) and sees whether they compile; if GHC returned a non- zero exit code on failed compilation of stdin, then that would simplify things a little bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 00:51:43 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 00:42:40 2008 Subject: [GHC] #1772: GHC doesn't like 'inline' type function applications In-Reply-To: <049.17d3971582a0f9ef03fef648f597cd91@localhost> References: <049.17d3971582a0f9ef03fef648f597cd91@localhost> Message-ID: <058.02667cb52a75bcba44e609e874ff7352@localhost> #1772: GHC doesn't like 'inline' type function applications -------------------------------------+-------------------------------------- Reporter: jpbernardy | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: Works now in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 00:57:40 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 00:48:32 2008 Subject: [GHC] #2417: using GADT syntax for an associated datatype causes GHC to panic In-Reply-To: <044.b2b50269f86bb871052f27e2bada0368@localhost> References: <044.b2b50269f86bb871052f27e2bada0368@localhost> Message-ID: <053.c505d6b4072f7f601f391148ffadeb96@localhost> #2417: using GADT syntax for an associated datatype causes GHC to panic ----------------------+----------------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => duplicate Comment: Duplicate of #1968. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 02:17:32 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 02:08:24 2008 Subject: [GHC] #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families In-Reply-To: <043.4e7d20bb20215044f4485928ab1623de@localhost> References: <043.4e7d20bb20215044f4485928ab1623de@localhost> Message-ID: <052.e81e2bd5f4e724c0ca7c1e689813b685@localhost> #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families -------------------------------------+-------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Comment (by chak): Another example from #2418: {{{ {-# OPTIONS_GHC -fglasgow-exts #-} class Blah f a where blah :: a -> T f f a class A f where type T f :: (* -> *) -> * -> * -- wrapper :: forall a f tf . (Blah f a,T f~tf) => a -> tf f a wrapper :: forall a f . (Blah f a) => a -> T f f a wrapper x = blah x }}} Add both examples to the test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 02:18:30 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 02:09:21 2008 Subject: [GHC] #2418: desugaring type function application to constraint makes bug disappear In-Reply-To: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> References: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> Message-ID: <053.3be2e4efa9c14821881d143bb58fcc9e@localhost> #2418: desugaring type function application to constraint makes bug disappear -------------------------------------+-------------------------------------- Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: type families | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => duplicate Comment: This is actually a duplicate of #2146 (which more accurately pinpoints the underlying problem). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 05:13:56 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 05:04:53 2008 Subject: [GHC] #2418: desugaring type function application to constraint makes bug disappear In-Reply-To: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> References: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> Message-ID: <053.96392632d3962dd160e029f5f7f13f00@localhost> #2418: desugaring type function application to constraint makes bug disappear -------------------------------------+-------------------------------------- Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: type families | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by claus): Replying to [comment:3 chak]: > This is actually a duplicate of #2146 (which more accurately pinpoints the underlying problem). How so? I had some trouble reconstructing the intended example in #2146, but given the implicit constraints (higher-kinded & ignores first parameter), I assume it is something like: {{{ {-# LANGUAGE TypeFamilies #-} type family F a :: * -> * type instance F a = (,) String foo :: (F Int a ~ F Int [a]) => a -> [a] foo = undefined foo' :: (F Int a ~ F Bool [a]) => a -> [a] foo' = undefined }}} for which `GHCi, version 6.9.20080514` (a version that fails the desugaring test) gives the expected errors {{{ C:\Documents and Settings\cr3\Desktop\F.hs:6:0: Occurs check: cannot construct the infinite type: a = [a] When generalising the type(s) for `foo' C:\Documents and Settings\cr3\Desktop\F.hs:9:0: Occurs check: cannot construct the infinite type: a = [a] When generalising the type(s) for `foo'' Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 05:15:47 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 05:06:41 2008 Subject: [GHC] #650: Improve interaction between mutable arrays and GC In-Reply-To: <047.44b951cd4b5aa8536d862412c8d86597@localhost> References: <047.44b951cd4b5aa8536d862412c8d86597@localhost> Message-ID: <056.46469a064d832b74b11baeeb9d241b0f@localhost> #650: Improve interaction between mutable arrays and GC --------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * type: task => run-time performance bug * milestone: 6.10 branch => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 05:49:21 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 05:40:13 2008 Subject: [GHC] #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families In-Reply-To: <043.4e7d20bb20215044f4485928ab1623de@localhost> References: <043.4e7d20bb20215044f4485928ab1623de@localhost> Message-ID: <052.3a89fe9def1ed48ed67f23e4b9319135@localhost> #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families -------------------------------------+-------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Comment (by claus): What exactly is the intended example here? The implicit assumption seems to be "`F` is higher-kinded and ignores its first parameter, since `F`'s result is a type constructor, mismatches in `F`'s second parameter should be reported", so I tried: {{{ {-# LANGUAGE TypeFamilies #-} type family F a :: * -> * type instance F a = (,) String -- type instance F a = (,) a foo :: (F Int a ~ F Int [a]) => a -> [a] foo = undefined foo2 :: (F Int a ~ F Bool [a]) => a -> [a] foo2 = undefined -- foo3 :: (F Int ~ fi, F Bool ~ fb, fi a ~ fb [a]) => a -> [a] -- foo3 = undefined foo4 :: (Int,a) ~ (Bool,[a]) => a foo4 = undefined }}} but that gives the intended "occurs check" error messages for `foo1` and `foo2` (`GHCi, version 6.9.20080514`). As a variation, I switched the two instances, and then the `Int ~ Bool` mismatch hides the "occurs check" error in `foo2`, but that also happens in `foo4`, with no higher kinds. If it wasn't for this odd masking effect, I'd expect the "occurs check" error in `foo2` to be reported even without instances, but as it stands, the instances can make a difference, so it isn't entirely surprising that eliminating the instances removes/masks the error for `foo2` - it doesn't look right, but it doesn't seem limited to type families. In fact, I can get the same effect without type families or `~`: {{{ {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleContexts, FlexibleInstances, MultiParamTypeClasses #-} class EQ a b | a->b,b->a instance EQ a a foo4b :: EQ (Int,a) (Bool,[a]) => a foo4b = undefined }}} To investigate further, I did what I usually do - desugar the type family applications (uncomment foo3), but that simply bombs: {{{ : panic! (the 'impossible' happened) (GHC version 6.9.20080514 for i386-unknown-mingw32): Coercion.splitCoercionKindOf ghc-prim:GHC.Prim.left{(w) tc 34B} $co${tc aXw} [tv] fi{tv aXp} [sk] ~ fb{tv aXq} [sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I take this as further indication that #2418 is not quite the same issue as this one. Here is another variation: {{{ {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleContexts, FlexibleInstances, MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} type family F a :: * -> * -- type instance F a = (,) String -- type instance F a = (,) a class EQ a b | a->b,b->a instance EQ a a foo2b :: ((F Int) ~ fi,(F Bool) ~ fb, EQ (fi a) (fb [a])) => a -> [a] foo2b = undefined }}} no error on loading into GHCi, but {{{ *Main> foo2b :1:0: Occurs check: cannot construct the infinite type: a = [a] Expected type: F Bool [a] Inferred type: F Int a When using functional dependencies to combine EQ a a, arising from the instance declaration at C:\Documents and Settings\cr3\D esktop\F.hs:21:0 EQ (F Int a) (F Bool [a]), arising from a use of `foo2b' at :1:0-4 When generalising the type(s) for `it' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 11:58:26 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 11:49:15 2008 Subject: [GHC] #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. In-Reply-To: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> References: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> Message-ID: <052.4fdea48a86460c9677d9a4ce499ad6d3@localhost> #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by sclv): Ok. So I've narrowed down a relatively simple test case. It crashes even at -N1 but crashes much more immediately at -N4. The backtrace is the same as above. From this test case its pretty clear that there's an issue either with catchSTM or directly with RaiseAsync.c or with their interaction, and in fact unsafePerformIO and unsafeIOToSTM are nowhere to be found in this code. This test case can probably be distilled down to something even simpler that doesn't use any of the typeclass toys I was playing with that ended up here in the first place. But I've taken it about as far as I can today. As far as I know though, this is only triggered during validation during GC, which is the only time stop_at_atomically is set. So one question I have is why a thread which is already hit by an asynchronous exception should *then* be treated as invalid as well and subject to an attempt to roll back during scheduleDoGC. So it may be that there are two different mechanisms (one for exception handling via catchSTM and one for validation) that end up stepping on one another's toes. Just spinning a theory though. I should note this bug occurs in 6.8.3 up through HEAD as far as I know. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 18:57:40 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 18:48:30 2008 Subject: [GHC] #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families In-Reply-To: <043.4e7d20bb20215044f4485928ab1623de@localhost> References: <043.4e7d20bb20215044f4485928ab1623de@localhost> Message-ID: <052.0577750b096f8eba58f0f0c3b949c85f@localhost> #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families -------------------------------------+-------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Comment (by claus): I just noticed that `GHCi, version 6.9.20080514` accepts partially applied type families, which would permit `foo2`'s type equality to succeed: {{{ {-# LANGUAGE TypeFamilies #-} type family F a :: * -> * type instance F Int = [] type instance F Bool = Id type family Id a :: * type instance Id a = a foo2 :: (F Int a ~ F Bool [a]) => a -> [a] foo2 = undefined }}} (note the partially applied `Id`) I thought this was covered in #2157, but both that ticket and its summary at TypeFunctionsStatus only talk about partially applied type synonyms, assuming that partially applied type families are already impossible. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 20:11:33 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 20:02:19 2008 Subject: [GHC] #2429: error building full dll name to be loaded in ghci Message-ID: <042.4bf17899c73d8aa74b87acbd8588af1e@localhost> #2429: error building full dll name to be loaded in ghci ------------------------+--------------------------------------------------- Reporter: jvl | Owner: Type: bug | Status: new Priority: normal | Component: Driver Version: 6.8.2 | Severity: normal Keywords: dll | Testcase: Architecture: Unknown | Os: Windows ------------------------+--------------------------------------------------- problem encountered ghc 6.8.2 on windows XP. This problem was identified whilst trying to load the wxHaskell dll into ghci. The wxHaskell dll is named wxc-msw2.6.4-0.10.3.dll and will not load into ghci, the following error is encountered {{{ >ghci -fglasgow-exts -lwxc-msw2.6.4-0.10.3 GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (dynamic) wxc-msw2.6.4-0.10.3 ... failed. Dynamic linker error message was: addDLL: unknown error Whilst trying to load: (dynamic) wxc-msw2.6.4-0.10.3 Directories to search are: : user specified .o/.so/.DLL could not be loaded. }}} yet if we rename the dll {{{ >ghci -fglasgow-exts -lwxc-msw2.6.4-0.10 GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (dynamic) wxc-msw2.6.4-0.10 ... done final link ... done Prelude> }}} i.e. the final .3.dll causes the problem, exceeding some limit? There appears to be an error in the parsing and construction of the full dll name. i.e. ghci postfix's a .dll adds the path etc, to the base name, but in the above, it can't handle the extra ".3" in the name. ghc in compile mode does not have this error. The above can be verified by constructibe a dummy dll using the following c file, then renaming it appropriately, file wxc.cpp: {{{ #define ROBEXP __declspec(dllexport) void ROBEXP foo_addref(int* f){ } void ROBEXP foo_release(int* f){ } }}} as follows {{{ >cl /LD /MD wxc.cpp >ghci -fglasgow-exts -lwxc GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (dynamic) wxc ... done final link ... done }}} rename and test {{{ >rename wxc.dll wxc-msw2.6.4-0.10.3.dll >ghci -fglasgow-exts -lwxc-msw2.6.4-0.10.3 GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (dynamic) wxc-msw2.6.4-0.10.3 ... failed. Dynamic linker error message was: addDLL: unknown error Whilst trying to load: (dynamic) wxc-msw2.6.4-0.10.3 Directories to search are: : user specified .o/.so/.DLL could not be loaded. }}} again the same load error A number of other points ... * dll load error messages * dll load name stuffing == error messages == The same error message "addDLL: unknown error" will apear regardless of whether the error is a genuine "unknown" error or not. The load error reporting should at least distinguish between not being able to locate the dll and other errors, for example, lets give the load a spurious name {{{ >ghci -fglasgow-exts -lwxc-msw2.6.4-X GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (dynamic) wxc-msw2.6.4-X ... failed. Dynamic linker error message was: addDLL: unknown error Whilst trying to load: (dynamic) wxc-msw2.6.4-X Directories to search are: : user specified .o/.so/.DLL could not be loaded. }}} OK, now lets create a bad dll {{{ >cp wxc.cpp wxc-msw2.6.4-X.dll }}} {{{ >ghci -fglasgow-exts -lwxc-msw2.6.4-X GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (dynamic) wxc-msw2.6.4-X ... failed. Dynamic linker error message was: addDLL: unknown error Whilst trying to load: (dynamic) wxc-msw2.6.4-X Directories to search are: : user specified .o/.so/.DLL could not be loaded. }}} so we can't even distinguish between a missing dll and a bad one ! == name stuffing == Also, if possible wouldn't it be better for ghci to display the same behaviour as gcc in treatment of dll names i.e. it will postfix .dll, but if that fails it will try the supplied name without any extension, so something like the following will work. {{{ ghci -lsomelib.dll }}} a somewhat related issue #1883 can be treated in the same way, i.e. generate a set of possible target dll full names, by prefixing, postfixing, or in pseudo haskell in the list monad {{{ names base = do prefix <- all_possible_prefix_including_null postfix <- all_possible_postfix_including_null return (prefix++base++postfix) }}} then test each one for load, (gcc does something very similar when searching for .a libraries) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 22:41:08 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 22:32:01 2008 Subject: [GHC] #2418: desugaring type function application to constraint makes bug disappear In-Reply-To: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> References: <044.eaa9c0a2eea9fd2435e9f9d1b5497f42@localhost> Message-ID: <053.8c18b98c4c6488789b11f25d73b19c3d@localhost> #2418: desugaring type function application to constraint makes bug disappear -------------------------------------+-------------------------------------- Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: type families | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by chak): Replying to [comment:4 claus]: > Replying to [comment:3 chak]: > > This is actually a duplicate of #2146 (which more accurately pinpoints the underlying problem). > > How so? `T` is a unary type synonym family, so in {{{ wrapper :: forall a f . (Blah f a) => a -> T f f a }}} you should read the result type as `(T f) f a`, where `T f` is the ''family application,'' whereas the application of `(T f)` to the second `f` and to `a` are vanilla type applications. The bug is that GHC mistakenly takes the whole of `T f f a` as tertiary family application. (If it ''were'' a tertiary family application, the signature would be ambiguous and the error message would be correct - but it's unary, so GHC is wrong in rejecting the program.) This also explains why what you call the desugared variant works: {{{ wrapper :: forall a f tf . (Blah f a,T f~tf) => a -> tf f a }}} Here `tf f a` syntactically contains no type family. So, GHC correctly takes this to be vanilla type applications. The place in the type checker where things go wrong is in the implementation of what we call the ''decomposition rule'' (see our forthcoming ICFP'08 paper for details on the type checking algorithm). That's exactly what #2146 is about. (In any case, I will also add the example of the present ticket to the testsuite when I fix the bug.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 8 23:07:51 2008 From: trac at galois.com (GHC) Date: Tue Jul 8 22:58:40 2008 Subject: [GHC] #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families In-Reply-To: <043.4e7d20bb20215044f4485928ab1623de@localhost> References: <043.4e7d20bb20215044f4485928ab1623de@localhost> Message-ID: <052.086158ef2878014c9ac231dbf92ff51a@localhost> #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families -------------------------------------+-------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Comment (by chak): Replying to [comment:3 claus]: > What exactly is the intended example here? {{{ type family F a :: * -> * foo :: (F Int a ~ F Bool [a]) => a -> [a] foo = undefined }}} Does not give rise to an error, but should, as it must be equivalent to the following according to the ''decomposition rule'': {{{ type family F a :: * -> * foo :: (F Int ~ F Bool, a ~ [a]) => a -> [a] foo = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 01:54:48 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 01:45:41 2008 Subject: [GHC] #1900: Type families with class constraints: type-checker loops In-Reply-To: <049.560239d640c515e64393974a17f250b4@localhost> References: <049.560239d640c515e64393974a17f250b4@localhost> Message-ID: <058.69f6d381c7290448c38bec27fa49b0b1@localhost> #1900: Type families with class constraints: type-checker loops -------------------------------------+-------------------------------------- Reporter: h.holtmann | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T1900 | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by chak): * testcase: => T1900 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 03:00:05 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 02:51:29 2008 Subject: [GHC] #1999: panic with GADT etc. In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost> References: <046.74c6dc616261a913ffd4180fb00731f0@localhost> Message-ID: <055.fe5256d27ccd00c27c23508771782e81@localhost> #1999: panic with GADT etc. ----------------------+----------------------------------------------------- Reporter: jeltsch | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T1999 | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by chak): * testcase: => T1999 * status: closed => reopened * resolution: fixed => Comment: I spoke too early. Reopened. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 03:04:06 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 02:55:28 2008 Subject: [GHC] #1999: panic with GADT etc. In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost> References: <046.74c6dc616261a913ffd4180fb00731f0@localhost> Message-ID: <055.daf83ed1fccf9aed54ab275bbda18f80@localhost> #1999: panic with GADT etc. ----------------------+----------------------------------------------------- Reporter: jeltsch | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T1999 | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by chak): More precisely, the error only occurs with -dcore-lint (which is why I at first thought it was fixed). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 04:56:33 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 04:47:27 2008 Subject: [GHC] #738: ghc can't load files with selinux Enforcing In-Reply-To: <065.24a0770a4c910c3e35b946b29e1c1608@localhost> References: <065.24a0770a4c910c3e35b946b29e1c1608@localhost> Message-ID: <074.dbd2b847848f5ee5d30cae6a23647538@localhost> #738: ghc can't load files with selinux Enforcing ----------------------------------------+----------------------------------- Reporter: jon.fairbairn@cl.cam.ac.uk | Owner: Type: feature request | Status: reopened Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: selinux | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: Unknown => Moderate (1 day) * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 05:15:47 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 05:06:37 2008 Subject: [GHC] #1619: The RTS chokes on SIGPIPE (happens with runInteractiveCommand) In-Reply-To: <044.b1c078255d6a68ad73f85282a9d62782@localhost> References: <044.b1c078255d6a68ad73f85282a9d62782@localhost> Message-ID: <053.69ff022563e19a62e8ebcf64dac0b942@localhost> #1619: The RTS chokes on SIGPIPE (happens with runInteractiveCommand) ----------------------------+----------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: SIGPIPE already causes an exception to be raised, because it occurs as a side-effect of a `write()` which returns `EPIPE`. So I've come around on this one and decided we should be just ignoring `SIGPIPE`. {{{ Wed Jul 9 09:49:16 BST 2008 Simon Marlow * FIX part of #2301, and #1619 2301: Control-C now causes the new exception (AsyncException UserInterrupt) to be raised in the main thread. The signal handler is set up by GHC.TopHandler.runMainIO, and can be overriden in the usual way by installing a new signal handler. The advantage is that now all programs will get a chance to clean up on ^C. When UserInterrupt is caught by the topmost handler, we now exit the program via kill(getpid(),SIGINT), which tells the parent process that we exited as a result of ^C, so the parent can take appropriate action (it might want to exit too, for example). One subtlety is that we have to use a weak reference to the ThreadId for the main thread, so that the signal handler doesn't prevent the main thread from being subject to deadlock detection. 1619: we now ignore SIGPIPE by default. Although POSIX says that a SIGPIPE should terminate the process by default, I wonder if this decision was made because many C applications failed to check the exit code from write(). In Haskell a failed write due to a closed pipe will generate an exception anyway, so the main difference is that we now get a useful error message instead of silent program termination. See #1619 for more discussion. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 05:25:38 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 05:16:24 2008 Subject: [GHC] #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH In-Reply-To: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> References: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> Message-ID: <060.b9e0f8764f5e0bf3c38267462463bc20@localhost> #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- Comment (by simonmar): I think it's acceptable to require `#!/usr/bin/env`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 07:13:26 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 07:04:12 2008 Subject: [GHC] #1198: Windows: hWaitForInput returns False for file handles, and doesn't work properly for consoles In-Reply-To: <044.c5199e3f203093561a83dbca73bb5395@localhost> References: <044.c5199e3f203093561a83dbca73bb5395@localhost> Message-ID: <053.f137debe986d2e595a4bc87fd5a13eaa@localhost> #1198: Windows: hWaitForInput returns False for file handles, and doesn't work properly for consoles -------------------------------------+-------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 6.10.1 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: readwrite002, hReady001 | Architecture: Unknown Os: Windows | -------------------------------------+-------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Ok, I believe I've fixed this now. {{{ Tue Jul 8 14:42:54 GMT Daylight Time 2008 Simon Marlow * FIX #1198: hWaitForInput on Windows Now we do the appropriate magic in fdReady() to detect when there is real input available, as opposed to uninteresting console events. Wed Jul 9 12:10:08 GMT Daylight Time 2008 Simon Marlow * Make threadWaitRead/threadWaitWrite partially useable on Windows They work with -threaded by calling fdReady() in a separate thread. "threadWaitRead 0" also works without -threaded (because we happen to know it's virtually equivalent to "hWaitForInput stdin (-1)"). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 08:16:33 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 08:07:22 2008 Subject: [GHC] #1103: Japanese Unicode In-Reply-To: <047.1b624b52c8e7f3189b55a2a1d4184482@localhost> References: <047.1b624b52c8e7f3189b55a2a1d4184482@localhost> Message-ID: <056.9e942cca78553b819551a31d8a6aebee@localhost> #1103: Japanese Unicode -----------------------------------------------------+---------------------- Reporter: humasect | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Parser) | Version: 6.6 Severity: major | Resolution: fixed Keywords: japanese unicode lexical -fglasgow-exts | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -----------------------------------------------------+---------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I did as Ross suggested and made the "Letter, Other" class behave as lower-case. {{{ Wed Jul 9 10:12:52 BST 2008 Simon Marlow * Treat the Unicode "Letter, Other" class as lowercase letters (#1103) This is an arbitrary choice, but it's strictly more useful than the current situation, where these characters cannot be used in identifiers at all. In Haskell' we may revisit this decision (it's on my list of things to discuss), but for now this is an improvement for those using caseless languages. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 08:17:47 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 08:08:33 2008 Subject: [GHC] #1357: warning for possible missing & in foreign import In-Reply-To: <047.5a76a33964c884c16a44cbd61629cb04@localhost> References: <047.5a76a33964c884c16a44cbd61629cb04@localhost> Message-ID: <056.7c8a8bcd2c7b67b85b3ec919c36ac952@localhost> #1357: warning for possible missing & in foreign import -----------------------------+---------------------------------------------- Reporter: Frederik | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: reopened => closed * resolution: => fixed Comment: Warning added, and documented: {{{ Wed Jul 9 11:21:43 BST 2008 Simon Marlow * add -fwarn-dodgy-foreign-imports (see #1357) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 08:19:28 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 08:10:14 2008 Subject: [GHC] #1205: ghci reports functions not in scope after loading a .hs, if there is a .o present In-Reply-To: <044.bd60efe42aee3f1abdd3292b0526501b@localhost> References: <044.bd60efe42aee3f1abdd3292b0526501b@localhost> Message-ID: <053.1fe3355a99729ef11787b3133c8db804@localhost> #1205: ghci reports functions not in scope after loading a .hs, if there is a .o present -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: high | Milestone: 6.10 branch Component: GHCi | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Wed Jul 9 12:08:30 BST 2008 Simon Marlow * #1205: ':load foo.hs' in GHCi always compiles to bytecode So now :load foo.hs loads bytecode for foo.hs, even if foo.o exists :load foo is just shorthand for :load foo.hs :load M loads a module M, as object code if possible (no change here) :set -fobject-code :load foo.hs loads foo.hs as object code; an existing foo.o can be used. This turned out to be very straightforward: when building the ModSummary for a file (summariseFile) we just ignore the object file unless -fobject-code is on. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 09:08:20 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 08:59:09 2008 Subject: [GHC] #1019: X11 package puts path to X libraries in ld-options rather than library-dirs, so ghci can't find it In-Reply-To: <047.9713acbe044d0e5a8b713ede559866bb@localhost> References: <047.9713acbe044d0e5a8b713ede559866bb@localhost> Message-ID: <056.3547140c6b480f612135fd17574924e0@localhost> #1019: X11 package puts path to X libraries in ld-options rather than library- dirs, so ghci can't find it -------------------------------+-------------------------------------------- Reporter: wolfgang | Owner: Type: bug | Status: closed Priority: low | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: No longer an extralib, so closing the bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 09:09:03 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 08:59:49 2008 Subject: [GHC] #1019: X11 package puts path to X libraries in ld-options rather than library-dirs, so ghci can't find it In-Reply-To: <047.9713acbe044d0e5a8b713ede559866bb@localhost> References: <047.9713acbe044d0e5a8b713ede559866bb@localhost> Message-ID: <056.5b0cffe3b5b992f176667b891814cb2a@localhost> #1019: X11 package puts path to X libraries in ld-options rather than library- dirs, so ghci can't find it -------------------------------+-------------------------------------------- Reporter: wolfgang | Owner: Type: bug | Status: closed Priority: low | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by igloo): Oh, BTW: I've forwarded the bug to Don, the X11 maintainer. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 09:22:37 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 09:13:25 2008 Subject: [GHC] #1441: Evaluating undefined should return line number and module of location of undefined In-Reply-To: <056.b9992601c5c6a0bcc306354ab7350e57@localhost> References: <056.b9992601c5c6a0bcc306354ab7350e57@localhost> Message-ID: <065.144e9e30c9730e358f64d73cb5ad349f@localhost> #1441: Evaluating undefined should return line number and module of location of undefined -------------------------------+-------------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: Duplicate of #960 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 09:22:49 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 09:13:53 2008 Subject: [GHC] #960: Lexical call site string In-Reply-To: <057.da5a7918d3a237f53bbf07bfe2771af6@localhost> References: <057.da5a7918d3a237f53bbf07bfe2771af6@localhost> Message-ID: <066.3d31f430911e87537807b2bd0685a3fd@localhost> #960: Lexical call site string --------------------------------+------------------------------------------- Reporter: paul@cogito.org.uk | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Comment (by igloo): See also #1441 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 09:25:06 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 09:15:51 2008 Subject: [GHC] #676: Write a performance checker for collections. In-Reply-To: <049.613922827808729c77aef2a86f21f44a@localhost> References: <049.613922827808729c77aef2a86f21f44a@localhost> Message-ID: <058.93375a51dbb4fa7d8ffea1e8a890f7d3@localhost> #676: Write a performance checker for collections. -------------------------------+-------------------------------------------- Reporter: jpbernardy | Owner: Alson Kemp Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries (other) | Version: 6.4.1 Severity: normal | Resolution: Keywords: collections | Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * component: libraries/base => libraries (other) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 09:28:16 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 09:19:01 2008 Subject: [GHC] #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH In-Reply-To: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> References: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> Message-ID: <060.8d722ea6ebd32ba7f771816c19aa3a67@localhost> #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * owner: => igloo * milestone: 6.10 branch => 6.10.1 Comment: OK, let's do this then. So runhaskell will become a shell script that calls the GHC that it comes with. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 09:43:38 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 09:34:22 2008 Subject: [GHC] #742: HGL broken on Windows In-Reply-To: <044.fc9b4f41bbf30d3c8c927f426da8c204@localhost> References: <044.fc9b4f41bbf30d3c8c927f426da8c204@localhost> Message-ID: <053.1f975e6b4b0c0a6d2377d6b7640af619@localhost> #742: HGL broken on Windows ---------------------------+------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/HGL | Version: 6.4.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => invalid Comment: No longer an extralib, so closing the bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 09:43:58 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 09:34:43 2008 Subject: [GHC] #1081: HGL indefinite pause with "thread blocked indefinitely" message In-Reply-To: <046.1eb10ab0d90274f6d318e59e9c32cce9@localhost> References: <046.1eb10ab0d90274f6d318e59e9c32cce9@localhost> Message-ID: <055.35ca8096723945145c860907a65794a3@localhost> #1081: HGL indefinite pause with "thread blocked indefinitely" message ---------------------------------+------------------------------------------ Reporter: calvins | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/HGL | Version: 6.6 Severity: normal | Resolution: fixed Keywords: hgl thread deadlock | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: No longer an extralib, so closing the bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 09:45:06 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 09:35:51 2008 Subject: [GHC] #2286: HGL library do not compile In-Reply-To: <054.4215bab50789703cf266b7917f1289de@localhost> References: <054.4215bab50789703cf266b7917f1289de@localhost> Message-ID: <063.614a7ceaf32cee81f71f61e15fd5ca74@localhost> #2286: HGL library do not compile -----------------------------+---------------------------------------------- Reporter: rgarciapariente | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/HGL | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: No longer an extralib, so closing the bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 09:46:14 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 09:36:57 2008 Subject: [GHC] #471: Windows HGL Thread problems In-Reply-To: <047.084594660854c89aa832f5f3539197a2@localhost> References: <047.084594660854c89aa832f5f3539197a2@localhost> Message-ID: <056.48ee71e6a6d48b21e24bcc9458636c24@localhost> #471: Windows HGL Thread problems ---------------------------+------------------------------------------------ Reporter: mjthomas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/HGL | Version: 6.4.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: None => invalid Comment: No longer an extralib, so closing the bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 09:57:58 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 09:48:43 2008 Subject: [GHC] #309: ObjectIO-Lib: Problem scrolling compund control In-Reply-To: <046.cd7bf781ede68da73dc24b106ed27ce2@localhost> References: <046.cd7bf781ede68da73dc24b106ed27ce2@localhost> Message-ID: <055.ae5fb72193a9cd22baee4eff3ce628ae@localhost> #309: ObjectIO-Lib: Problem scrolling compund control -------------------------------+-------------------------------------------- Reporter: brassel | Owner: krasimir Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: None => invalid Comment: No longer an extralib, so closing the bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 10:08:35 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 09:59:23 2008 Subject: [GHC] #1071: The Graphics.X11 library for windows using Cygwin/X In-Reply-To: <044.dc06e9aa22d8d9d91e0688396df4bbed@localhost> References: <044.dc06e9aa22d8d9d91e0688396df4bbed@localhost> Message-ID: <053.457b84fede20efff426c76ad17579724@localhost> #1071: The Graphics.X11 library for windows using Cygwin/X -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: invalid Keywords: X11 binding | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: No longer an extralib, so closing the bug. I haven't forwarded this one to Don (X11 maintainer), as in a suitable build environment (i.e. with suitable libraries available) I think it would Just Work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 10:12:21 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 10:03:06 2008 Subject: [GHC] #988: X11: refine types for improved type safety In-Reply-To: <043.fed46a26009b069496f774b689d602a3@localhost> References: <043.fed46a26009b069496f774b689d602a3@localhost> Message-ID: <052.deef9497b76910283129f8ef53196007@localhost> #988: X11: refine types for improved type safety -------------------------------+-------------------------------------------- Reporter: ross | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: No longer an extralib, so closing the bug. I've forwarded it to Don. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 10:14:59 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 10:05:56 2008 Subject: [GHC] #720: Map/Set range function In-Reply-To: <049.e0a8d7729ecd2ef2ee4e25e6fb8a6039@localhost> References: <049.e0a8d7729ecd2ef2ee4e25e6fb8a6039@localhost> Message-ID: <058.851846037b7ea10c85600c5cb7b08d7c@localhost> #720: Map/Set range function -----------------------------+---------------------------------------------- Reporter: jpbernardy | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: wontfix Keywords: collections | Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: Please follow the library submissions process if you'd like to propose these changes: http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 10:18:09 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 10:08:57 2008 Subject: [GHC] #667: Efficient Map <-> Set conversions In-Reply-To: <049.9cbebdcde0e44f9fd9606d60e62aed5b@localhost> References: <049.9cbebdcde0e44f9fd9606d60e62aed5b@localhost> Message-ID: <058.06d8181d7ec312897431b7b35e97b9e2@localhost> #667: Efficient Map <-> Set conversions --------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: jpbernardy Type: feature request | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: wontfix Keywords: Data Map Set collections | Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * status: assigned => closed * resolution: => wontfix Comment: The conversion functions should be proposed with the library submissions process: http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 10:21:16 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 10:12:02 2008 Subject: [GHC] #1985: IntSet.deleteMin doesn't agree with Set.deleteMin In-Reply-To: <047.5a3c908303a81d833e8535fa59db8e2e@localhost> References: <047.5a3c908303a81d833e8535fa59db8e2e@localhost> Message-ID: <056.513418615d533e62d69ab7e44a5c7ca5@localhost> #1985: IntSet.deleteMin doesn't agree with Set.deleteMin -------------------------------+-------------------------------------------- Reporter: dbenbenn | Owner: Type: bug | Status: closed Priority: high | Milestone: Not GHC Component: libraries (other) | Version: 6.8.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: Needs a proposal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 10:22:01 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 10:12:52 2008 Subject: [GHC] #1732: Proposal: Rename haskell@ to haskell-announce@ In-Reply-To: <043.bb58f5b9948256d588e8ad4b7a636f93@localhost> References: <043.bb58f5b9948256d588e8ad4b7a636f93@localhost> Message-ID: <052.255a7527d340c46405f7c42fb2ebb0c1@localhost> #1732: Proposal: Rename haskell@ to haskell-announce@ ----------------------+----------------------------------------------------- Reporter: neil | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: None | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * type: task => proposal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 10:34:46 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 10:25:31 2008 Subject: [GHC] #1603: a miscompilation of (`rem` 0x40000000)::Int with -O -fvia-C In-Reply-To: <051.236bdfc382b4b8b333be4e1f7b023bf9@localhost> References: <051.236bdfc382b4b8b333be4e1f7b023bf9@localhost> Message-ID: <060.e6a498a6ae84c4460a9831d4df4620ab@localhost> #1603: a miscompilation of (`rem` 0x40000000)::Int with -O -fvia-C --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: numeric/1603 | Architecture: Multiple Os: Multiple | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: Not GHC => 6.10.1 Comment: gcc looks fixed now: {{{ $ cat q.c #include int f(unsigned int x) { printf("%x %d\n", x, (int)x); return ((int)x) % 4; } int main(int argc, char *argv[]) { printf("%d\n", f((unsigned int)(-1))); return 0; } $ gcc-4.1 q.c -Wall -o q && ./q ffffffff -1 3 $ gcc-4.2 q.c -Wall -o q && ./q ffffffff -1 -1 $ gcc-4.2 --version gcc-4.2 (GCC) 4.2.4 20080512 (prerelease) (Debian 4.2.3-6) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. }}} We should confirm the test passes with ghc and stop skipping it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 10:42:12 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 10:33:14 2008 Subject: [GHC] #960: Lexical call site string In-Reply-To: <057.da5a7918d3a237f53bbf07bfe2771af6@localhost> References: <057.da5a7918d3a237f53bbf07bfe2771af6@localhost> Message-ID: <066.a9777901a113ce4a9a1f190b9893df37@localhost> #960: Lexical call site string --------------------------------+------------------------------------------- Reporter: paul@cogito.org.uk | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Changes (by Isaac Dupree): * cc: id@isaac.cedarswampstudios.org (added) Comment: `undefined` could use a hack like `assert` currently does, but as soon as we want to start annotating things like `fromJust`, we'll need somewhat of a general mechanism. Potentially ''so'' worth it though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 10:52:18 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 10:43:02 2008 Subject: [GHC] #1557: Enum/Ord derivations for System.Posix.Resource.Resource In-Reply-To: <044.25aa2eed111d72cbb74e64af933dd9c2@localhost> References: <044.25aa2eed111d72cbb74e64af933dd9c2@localhost> Message-ID: <053.f751784202b40cdc6fe90e9874755d43@localhost> #1557: Enum/Ord derivations for System.Posix.Resource.Resource -----------------------------+---------------------------------------------- Reporter: Eelis | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.6.1 Severity: minor | Resolution: wontfix Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 10:54:16 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 10:45:11 2008 Subject: [GHC] #1548: printf bugs In-Reply-To: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> References: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> Message-ID: <060.c6c7609ccc5d63d651bb0d1e340c7e09@localhost> #1548: printf bugs ----------------------------+----------------------------------------------- Reporter: l.mai@web.de | Owner: lennart@augustsson.net Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: In the absence of a maintainer, please follow the library submissions process for these patches: http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 10:56:59 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 10:47:45 2008 Subject: [GHC] #1506: Case-insensitive char/string comparison In-Reply-To: <044.51ed6a4a3d2546d6d546abe6346e2150@localhost> References: <044.51ed6a4a3d2546d6d546abe6346e2150@localhost> Message-ID: <053.f032e464a7922024d9412b2c6453e963@localhost> #1506: Case-insensitive char/string comparison -----------------------------+---------------------------------------------- Reporter: Eelis | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: Please follow the library submissions process for this: http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 12:48:20 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 12:39:08 2008 Subject: [GHC] #1452: Modules omitted from a .cabal file are not reported, but result in a non-functional library In-Reply-To: <044.c09d3e23bb0f7284210e46d5889ced3f@localhost> References: <044.c09d3e23bb0f7284210e46d5889ced3f@localhost> Message-ID: <053.dd169ca028af3fa615ef54fce91e312a@localhost> #1452: Modules omitted from a .cabal file are not reported, but result in a non- functional library -------------------------------+-------------------------------------------- Reporter: guest | Owner: guest Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6.1 Severity: normal | Resolution: invalid Keywords: Cabal | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * status: assigned => closed * resolution: => invalid Comment: This is covered by these Cabal bugs: http://hackage.haskell.org/trac/hackage/ticket/128 http://hackage.haskell.org/trac/hackage/ticket/15 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 13:19:35 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 13:10:18 2008 Subject: [GHC] #988: X11: refine types for improved type safety In-Reply-To: <043.fed46a26009b069496f774b689d602a3@localhost> References: <043.fed46a26009b069496f774b689d602a3@localhost> Message-ID: <052.d1c2d769524fef7a99abccd10be2a5b9@localhost> #988: X11: refine types for improved type safety -------------------------------+-------------------------------------------- Reporter: ross | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by dons): A more richly typed wrapper would be a welcome addition (or separate library). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 13:22:04 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 13:12:49 2008 Subject: [GHC] #2003: The Data.Time.Format parser should be more liberal In-Reply-To: <054.afa516df5a0125b80d39ff7f1a5eecb2@localhost> References: <054.afa516df5a0125b80d39ff7f1a5eecb2@localhost> Message-ID: <063.0fa5a09e8edc83898a7875587100740e@localhost> #2003: The Data.Time.Format parser should be more liberal -------------------------------+-------------------------------------------- Reporter: BjornBuckwalter | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: Please follow the library submissions process for this: http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 13:24:35 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 13:15:31 2008 Subject: [GHC] #1846: under MAC OS X package dependencies are not satified by the user database In-Reply-To: <044.561761a8b653807576756b892df0bcb3@localhost> References: <044.561761a8b653807576756b892df0bcb3@localhost> Message-ID: <053.35f364e489697df4b2e811c52f6c8d1c@localhost> #1846: under MAC OS X package dependencies are not satified by the user database --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: Build System | Version: 6.8.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: So I think this wasn't a bug after all. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 13:29:25 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 13:20:16 2008 Subject: [GHC] #1019: X11 package puts path to X libraries in ld-options rather than library-dirs, so ghci can't find it In-Reply-To: <047.9713acbe044d0e5a8b713ede559866bb@localhost> References: <047.9713acbe044d0e5a8b713ede559866bb@localhost> Message-ID: <056.a97669479282faaf7685278244528a26@localhost> #1019: X11 package puts path to X libraries in ld-options rather than library- dirs, so ghci can't find it -------------------------------+-------------------------------------------- Reporter: wolfgang | Owner: Type: bug | Status: closed Priority: low | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by dons): Works for me, send a patch if this is still an issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 16:26:43 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 16:17:30 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.7b4fb69fe6b66f2b238970bf03ea1897@localhost> #2337: Data.Array documentation utterly broken ---------------------------+------------------------------------------------ Reporter: japple | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => invalid Comment: This is http://trac.haskell.org/haddock/ticket/24 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 16:26:53 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 16:17:41 2008 Subject: [GHC] #1269: Haddock: no documentation for entities re-exported from another package In-Reply-To: <045.31bcbac641d2d6a678bea927e92baf56@localhost> References: <045.31bcbac641d2d6a678bea927e92baf56@localhost> Message-ID: <054.5a2c27006c63f0a6d8d41dc0a4d0ea2d@localhost> #1269: Haddock: no documentation for entities re-exported from another package ---------------------------+------------------------------------------------ Reporter: sorear | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: Documentation | Version: 6.6 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => invalid Comment: This is http://trac.haskell.org/haddock/ticket/24 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 16:48:44 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 16:39:30 2008 Subject: [GHC] #1403: System.Posix.Types.UserID and others missing from Windows distribution In-Reply-To: <057.3a94b22cd8e476de844e8fcd845efe1e@localhost> References: <057.3a94b22cd8e476de844e8fcd845efe1e@localhost> Message-ID: <066.2b141c518f98db804d8951075d4f7f1b@localhost> #1403: System.Posix.Types.UserID and others missing from Windows distribution --------------------------------+------------------------------------------- Reporter: jgbailey@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: None | Version: 6.6.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Bug forwarded to Bjorn, the unix-compat maintainer. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 17:19:18 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 17:10:06 2008 Subject: [GHC] #2374: MutableByteArray# is slower than Addr# In-Reply-To: <044.46877f1bb530048ac22aec20e1b9d3f2@localhost> References: <044.46877f1bb530048ac22aec20e1b9d3f2@localhost> Message-ID: <053.5b010e2215063cd54f8e38c8b0603606@localhost> #2374: MutableByteArray# is slower than Addr# -------------------------------+-------------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (NCG) | Version: 6.8.2 Severity: minor | Resolution: Keywords: performance array | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Comment (by dolio): I've attached a new version of the MutableByteArray# benchmark I discovered while playing around with the static argument transform. It appears that, for me at least, performing SAT on the array argument of this benchmark causes GHC to produce significantly slower code via the NCG (via-C isn't much affected). Using this version of the benchmark appears to put Addr# and MBA# at about the same speed (Addr# may still be slightly faster, but I can probably forgive 0.5 seconds on 2.5 billion array accesses). So, you may feel free to close this bug if you deem it appropriate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 17:28:46 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 17:19:31 2008 Subject: [GHC] #2271: floor, ceiling, round :: Double -> Int are awesomely slow In-Reply-To: <043.845265305898c52232b3689d70d3b99c@localhost> References: <043.845265305898c52232b3689d70d3b99c@localhost> Message-ID: <052.f4a4322d9621ac51cbf25db1bb435b24@localhost> #2271: floor, ceiling, round :: Double -> Int are awesomely slow ---------------------------------------+------------------------------------ Reporter: dons | Owner: dons@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: performance, math, double | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------------+------------------------------------ Changes (by igloo): * component: Compiler => libraries/base -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 17:29:03 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 17:19:47 2008 Subject: [GHC] #2270: gcd is specialised only for Int In-Reply-To: <043.b1b4c47bccdeb536ea28564b64a56127@localhost> References: <043.b1b4c47bccdeb536ea28564b64a56127@localhost> Message-ID: <052.183f26dd5584c83360acac65c22723c0@localhost> #2270: gcd is specialised only for Int ----------------------------+----------------------------------------------- Reporter: dons | Owner: dons@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * component: Compiler => libraries/base -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 17:50:05 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 17:40:51 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.b8fe519318b29cceafd487908a3efd0d@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: high | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * component: Compiler => libraries/base -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 18:53:10 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 18:44:03 2008 Subject: [GHC] #1548: printf bugs In-Reply-To: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> References: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> Message-ID: <060.a80f151312df8bf22dfb0c538abb9ff2@localhost> #1548: printf bugs ----------------------------+----------------------------------------------- Reporter: l.mai@web.de | Owner: lennart@augustsson.net Type: bug | Status: reopened Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by guest): * status: closed => reopened * resolution: wontfix => Comment: The two first bugs were fixed a long time ago. I'm not sure where the new version of printf has gone, but I'll attach it here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 19:18:14 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 19:09:05 2008 Subject: [GHC] #1548: printf bugs In-Reply-To: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> References: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> Message-ID: <060.6ea348d0fd0450f4b1123480b1185a62@localhost> #1548: printf bugs ----------------------------+----------------------------------------------- Reporter: l.mai@web.de | Owner: lennart@augustsson.net Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: Not GHC => 6.10.1 Comment: Replying to [comment:4 guest]: > The two first bugs were fixed a long time ago. I'm not sure where the new version of printf has gone, but I'll attach it here. The above was from Lennart Augustsson. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 20:49:04 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 20:39:48 2008 Subject: [GHC] #1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs In-Reply-To: <044.a916af5b8c38ab63a7239d33e71dfb3b@localhost> References: <044.a916af5b8c38ab63a7239d33e71dfb3b@localhost> Message-ID: <053.4924c8c0abaacc872234b459ff03f20c@localhost> #1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs ---------------------+------------------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: hsc2hs | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 9 20:49:28 2008 From: trac at galois.com (GHC) Date: Wed Jul 9 20:40:15 2008 Subject: [GHC] #913: instance Ord (StableName a) In-Reply-To: <047.0416f6faa91e0e6311d64f6160f1532a@localhost> References: <047.0416f6faa91e0e6311d64f6160f1532a@localhost> Message-ID: <056.cc2ffe617ea595a52db46b9f8692f1a3@localhost> #913: instance Ord (StableName a) -----------------------------+---------------------------------------------- Reporter: ekarttun | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: Please follow the library submissions process for this: http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 01:53:38 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 01:44:23 2008 Subject: [GHC] #2430: Fix bug 1985 Message-ID: <047.9b5bc10cea52198550e3d65f8d7c196b@localhost> #2430: Fix bug 1985 -------------------------+-------------------------------------------------- Reporter: dbenbenn | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Multiple -------------------------+-------------------------------------------------- Proposal: fix bug 1985 (http://hackage.haskell.org/trac/ghc/ticket/1985) Time scale: Well, it's already been 6 months, so why not 6 more months? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 01:54:24 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 01:45:06 2008 Subject: [GHC] #1985: IntSet.deleteMin doesn't agree with Set.deleteMin In-Reply-To: <047.5a3c908303a81d833e8535fa59db8e2e@localhost> References: <047.5a3c908303a81d833e8535fa59db8e2e@localhost> Message-ID: <056.207c377a6811b27deb805d1397119dc6@localhost> #1985: IntSet.deleteMin doesn't agree with Set.deleteMin -------------------------------+-------------------------------------------- Reporter: dbenbenn | Owner: Type: bug | Status: closed Priority: high | Milestone: Not GHC Component: libraries (other) | Version: 6.8.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Comment (by dbenbenn): Replying to [comment:3 igloo]: > Needs a proposal http://hackage.haskell.org/trac/ghc/ticket/2430 filed as a proposal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 06:23:13 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 06:13:58 2008 Subject: [GHC] #2431: allow empty case analysis Message-ID: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> #2431: allow empty case analysis ------------------------------------+--------------------------------------- Reporter: RalfHinze | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: minor Keywords: empty case analysis | Testcase: Architecture: Unknown | Os: Unknown ------------------------------------+--------------------------------------- Using -XEmptyDataDecls I can declare an (almost) empty data type. data Void However, I can't use an empty case to discriminate values of the empty type. This does not work: get :: Void -> a Only the type signature, but no body. [This would be useful also in other circumstances.] get :: Void -> a get v = case v of { } An empty case in the body. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 06:40:00 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 06:30:41 2008 Subject: [GHC] #2431: allow empty case analysis In-Reply-To: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> References: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> Message-ID: <057.157d57f2de7a1e3246cee949a47c7458@localhost> #2431: allow empty case analysis ---------------------------------+------------------------------------------ Reporter: RalfHinze | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: empty case analysis | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Old description: > Using -XEmptyDataDecls I can declare an (almost) empty data type. > data Void > However, I can't use an empty case to discriminate values of the > empty type. > > This does not work: > get :: Void -> a > Only the type signature, but no body. [This would be useful also > in other circumstances.] > get :: Void -> a > get v = case v of { } > An empty case in the body. New description: Using -XEmptyDataDecls I can declare an (almost) empty data type. {{{ data Void }}} However, I can't use an empty case to discriminate values of the empty type. This does not work: {{{ get :: Void -> a }}} Only the type signature, but no body. [This would be useful also in other circumstances.] {{{ get :: Void -> a get v = case v of { } }}} An empty case in the body. Comment: Why is this useful? The only value of type `Void` is bottom. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 06:57:34 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 06:48:19 2008 Subject: [GHC] #2431: allow empty case analysis In-Reply-To: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> References: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> Message-ID: <057.7b1dca2f53500bbc3f88db030f7fc360@localhost> #2431: allow empty case analysis ---------------------------------+------------------------------------------ Reporter: RalfHinze | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: empty case analysis | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Comment (by NeilMitchell): This would be somewhat useful for the Derive tool (http://www.cs.york.ac.uk/fp/darcs/derive), and in general for program generation. Consider the automatically derived instance for Show, on an empty data type. What you are likely to get is: {{{ instance Show Void where }}} i.e. the complete absense of anything. If you changed the generator to make a case statement, you could get: {{{ instance Show Void where show x = case x of {} }}} Which is a more accurate reflection of what was intended, and I think the point Ralf is trying to make. Derive probably goes wrong with empty data types, but if it didn't, this extension would be helpful. I tried to construct an empty case with Template Haskell, and crashed GHC: {{{ C:\Neil\Temp>ghci -fth GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m Language.Haskell.TH Prelude Language.Haskell.TH> $(caseE (litE $ CharL 'a') []) : panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-mingw32): readFilledBox t_a1b5{tv} [box] 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 Jul 10 09:00:59 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 08:51:54 2008 Subject: [GHC] #2431: allow empty case analysis In-Reply-To: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> References: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> Message-ID: <057.2a6020767a968fb082df477a7e264a62@localhost> #2431: allow empty case analysis ---------------------------------+------------------------------------------ Reporter: RalfHinze | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: empty case analysis | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Changes (by Isaac Dupree): * cc: id@isaac.cedarswampstudios.org (added) Comment: Of course, with the correct warning flags enabled, empty case of a non- empty type will produce an "incomplete pattern match" warning: exactly when we want a warning for using this construct. I suppose the effect is to throw a pattern-match error that is independent of the case'd value, as consistent with all patterns of any other case statement failing? (rather than using it if it's _|_, as of course it will be if it's an empty type: because, unlike in GHC Core, source-Haskell 'case' does not introduce strictness) +1, I've occasionally wanted this to be possible -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 10:04:59 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 09:56:11 2008 Subject: [GHC] #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma In-Reply-To: <047.0b0f638b3610964bc1921eacae64b292@localhost> References: <047.0b0f638b3610964bc1921eacae64b292@localhost> Message-ID: <056.0f3c83415ec8bdb1af99190426a893a8@localhost> #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma -----------------------------+---------------------------------------------- Reporter: mnislaih | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by simonmar): * difficulty: Unknown => Moderate (1 day) * os: MacOS X => Multiple * architecture: x86 => Multiple Comment: I looked into doing this. It's almost possible without major changes, but there's a sticking point: mutually recursive modules. The core restriction is that pbject code can only link to other object code. This is because byte-code resides in the heap and may move around and be GC'd, so if we allowed object-code to point to byte-code the GC would have to track pointers from object-code to byte-code, which it doesn't (that would be possible). Also object-code itself currently never gets GC'd, because in order to do that the GC would have to track pointers into object-code, which include info pointers. Info pointers are not currently tracked as GC pointers, so this is hard. In short, it's really hard to lift this restriction - we thought about it at the time we designed GHCi, and concluded that it wasn't worth it. So the tricky bit about allowing `-fbyte-code` at the module level is that if it occurs within a mutually-recursive group of modules, it has to apply to the whole group. That makes this a bit more than a local change, so I gave up for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 11:18:00 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 11:09:13 2008 Subject: [GHC] #2387: Optimizer misses unboxing opportunity In-Reply-To: <044.f6f12d90c4b64de9fb4d129e27bf4881@localhost> References: <044.f6f12d90c4b64de9fb4d129e27bf4881@localhost> Message-ID: <053.35bdbd5c11bc12bb3b08eb4ad2381933@localhost> #2387: Optimizer misses unboxing opportunity --------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: optimizer unbox box | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | --------------------------------------+------------------------------------- Changes (by simonmar): * type: bug => run-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 11:21:17 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 11:11:58 2008 Subject: [GHC] #1218: Add sortNub and sortNubBy to Data.List In-Reply-To: <043.ff9032e500fd9c14d06a05d463884228@localhost> References: <043.ff9032e500fd9c14d06a05d463884228@localhost> Message-ID: <052.1499d46e271c6db6daefaf881dce93a4@localhost> #1218: Add sortNub and sortNubBy to Data.List ----------------------------+----------------------------------------------- Reporter: neil | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 11:29:14 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 11:19:58 2008 Subject: [GHC] #2432: type family panic: Coercion.splitCoercionKindOf Message-ID: <044.419fb1a60288d8516aab35dbc1443539@localhost> #2432: type family panic: Coercion.splitCoercionKindOf ------------------------+--------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- as seen in #2146#comment:5, confirmed with `GHCi, version 6.9.20080709` {{{ {-# LANGUAGE TypeFamilies #-} type family F a :: * -> * foo3 :: (F Int ~ fi, F Bool ~ fb, fi a ~ fb a) => a foo3 = undefined }}} {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 6.9.20080709 for i386-unknown-mingw32): Coercion.splitCoercionKindOf ghc-prim:GHC.Prim.left{(w) tc 34B} $co${tc a7j} [tv] fi{tv a6W} [sk] ~ fb{tv a6X} [sk] 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 Jul 10 12:19:26 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 12:10:18 2008 Subject: [GHC] #1238: ByteString based datagram communication In-Reply-To: <046.77810ed8a03560140b54117cb93b9713@localhost> References: <046.77810ed8a03560140b54117cb93b9713@localhost> Message-ID: <055.153f4fbc56687d4cfdfe9c26db1a86c8@localhost> #1238: ByteString based datagram communication -------------------------------+-------------------------------------------- Reporter: robreim | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.6 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 12:20:43 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 12:11:24 2008 Subject: [GHC] #1249: Data.Map.map should be deprecated/removed In-Reply-To: <054.6463384687d9c372b2aa4e98b6648fd0@localhost> References: <054.6463384687d9c372b2aa4e98b6648fd0@localhost> Message-ID: <063.bfef44f98a8217f632812248ed3d5cc6@localhost> #1249: Data.Map.map should be deprecated/removed -----------------------------+---------------------------------------------- Reporter: ajb@spamcop.net | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6 Severity: minor | Resolution: wontfix Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 12:46:36 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 12:37:17 2008 Subject: [GHC] #2433: standalone deriving Typeable shouldn't need data constructors in scope? Message-ID: <044.c3db89885eba9cc62656744d598e567c@localhost> #2433: standalone deriving Typeable shouldn't need data constructors in scope? ------------------------+--------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- customary artificial example: {{{ {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE DeriveDataTypeable #-} import Data.Typeable(Typeable1) import qualified Prelude() import Prelude(Maybe) deriving instance Typeable1 Maybe }}} `GHCi, version 6.9.20080709`: {{{ DTR.hs:8:0: The data constructors of `Maybe' are not all in scope so you cannot derive an instance for it In the stand-alone deriving instance for `Typeable1 Maybe' Failed, modules loaded: none. }}} Does `Typeable` really need access to the '''data''' constructors? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 12:51:18 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 12:48:48 2008 Subject: [GHC] #1266: Make Data.Graph.Inductive.NodeMap handle slightly messy input without crashing In-Reply-To: <057.1b08d7ede359f08c5581760019fe39a9@localhost> References: <057.1b08d7ede359f08c5581760019fe39a9@localhost> Message-ID: <066.3fb2a9592246f1613db6ab85087d90ee@localhost> #1266: Make Data.Graph.Inductive.NodeMap handle slightly messy input without crashing --------------------------------+------------------------------------------- Reporter: jyasskin@gmail.com | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:05:54 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 14:56:54 2008 Subject: [GHC] #2434: Spurious timer_create() configure test failure. Message-ID: <045.b0c92ecf2e46a74462d7e6763a458995@localhost> #2434: Spurious timer_create() configure test failure. ---------------------------------------+------------------------------------ Reporter: Eelis- | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.3 | Severity: normal Keywords: timer_create configure | Testcase: Architecture: x86_64 (amd64) | Os: Unknown ---------------------------------------+------------------------------------ On my system, the timer_create() config test fails, but I believe the test program is to blame, not my system. This is the program in question, as it appears in aclocal.m4: {{{ #include #ifdef HAVE_STDLIB_H #include #endif #ifdef HAVE_TIME_H #include #endif #ifdef HAVE_SIGNAL_H #include #endif #ifdef HAVE_UNISTD_H #include #endif static volatile int tock = 0; static void handler(int i) { tock = 1; } static void timeout(int i) { // timer_settime() has been known to hang, so just in case // we install a 1-second timeout (see #2257) exit(99); } int main(int argc, char *argv[]) { struct sigevent ev; timer_t timer; struct itimerspec it; struct sigaction action; int m,n,count = 0; ev.sigev_notify = SIGEV_SIGNAL; ev.sigev_signo = SIGVTALRM; action.sa_handler = handler; action.sa_flags = 0; sigemptyset(&action.sa_mask); if (sigaction(SIGVTALRM, &action, NULL) == -1) { fprintf(stderr,"SIGVTALRM problem\n"); exit(3); } action.sa_handler = timeout; action.sa_flags = 0; sigemptyset(&action.sa_mask); if (sigaction(SIGALRM, &action, NULL) == -1) { fprintf(stderr,"SIGALRM problem\n"); exit(3); } alarm(1); if (timer_create(CLOCK_PROCESS_CPUTIME_ID, &ev, &timer) != 0) { fprintf(stderr,"No CLOCK_PROCESS_CPUTIME_ID timer\n"); exit(1); } it.it_value.tv_sec = 0; it.it_value.tv_nsec = 1; it.it_interval = it.it_value; if (timer_settime(timer, 0, &it, NULL) != 0) { fprintf(stderr,"settime problem\n"); exit(4); } tock = 0; for(n = 3; n < 20000; n++){ for(m = 2; m <= n/2; m++){ if (!(n%m)) count++; if (tock) goto out; } } out: if (!tock) { fprintf(stderr,"no CLOCK_PROCESS_CPUTIME_ID signal\n"); exit(5); } timer_delete(timer); if (timer_create(CLOCK_REALTIME, &ev, &timer) != 0) { fprintf(stderr,"No CLOCK_REALTIME timer\n"); exit(2); } it.it_value.tv_sec = 0; it.it_value.tv_nsec = 1000000; it.it_interval = it.it_value; if (timer_settime(timer, 0, &it, NULL) != 0) { fprintf(stderr,"settime problem\n"); exit(4); } tock = 0; usleep(300); if (!tock) { fprintf(stderr,"no CLOCK_REALTIME signal\n"); exit(5); } timer_delete(timer); exit(0); } }}} On my system, it outputs "no CLOCK_REALTIME signal". However, notice that CLOCK_REALTIME-bound timer is set to expire in a million nanoseconds (one millisecond), while usleep is subsequently used to sleep for only 300 microseconds (0.3 milliseconds), which is simply too short. Consequently, tock is not set. If I bump the usleep to 3000 microseconds (3 milliseconds), tock is set and the test succeeds. I care about the result of this test because if it fails, ghc apparently falls back on using SIGVTALRM instead, which interferes with my application. Apologies if I've misunderstood the test program. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:20:30 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 15:11:41 2008 Subject: [GHC] #1417: Add pseudoterminal support to the unix package In-Reply-To: <057.da33875de43e810fe55f4c7d0f97ea47@localhost> References: <057.da33875de43e810fe55f4c7d0f97ea47@localhost> Message-ID: <066.2fd0c565c7724ff5c299be1882de2a37@localhost> #1417: Add pseudoterminal support to the unix package --------------------------------+------------------------------------------- Reporter: bos@serpentine.com | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:21:09 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 15:11:50 2008 Subject: [GHC] #1460: Problem with Monoid instance of Data.Map In-Reply-To: <051.14fc774a6009986dddf4bde26633711e@localhost> References: <051.14fc774a6009986dddf4bde26633711e@localhost> Message-ID: <060.6eb428697e56bb94fc8913b08580827e@localhost> #1460: Problem with Monoid instance of Data.Map -----------------------------+---------------------------------------------- Reporter: ahey@iee.org | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: Data.Map Monoid | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:23:23 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 15:14:21 2008 Subject: [GHC] #1274: Add a MonadState instance for the Parsec monad In-Reply-To: <042.549d4792a164effb8ff35a0ca0f2b643@localhost> References: <042.549d4792a164effb8ff35a0ca0f2b643@localhost> Message-ID: <051.f20bd677470007eaa2d97b1363e3866d@localhost> #1274: Add a MonadState instance for the Parsec monad -------------------------------+-------------------------------------------- Reporter: mux | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: minor | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:23:56 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 15:14:39 2008 Subject: [GHC] #1274: Add a MonadState instance for the Parsec monad In-Reply-To: <042.549d4792a164effb8ff35a0ca0f2b643@localhost> References: <042.549d4792a164effb8ff35a0ca0f2b643@localhost> Message-ID: <051.d7368cf02df80201c0f9779ffc6db851@localhost> #1274: Add a MonadState instance for the Parsec monad -------------------------------+-------------------------------------------- Reporter: mux | Owner: Type: proposal | Status: reopened Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: closed => reopened * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:24:19 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 15:15:02 2008 Subject: [GHC] #1274: Add a MonadState instance for the Parsec monad In-Reply-To: <042.549d4792a164effb8ff35a0ca0f2b643@localhost> References: <042.549d4792a164effb8ff35a0ca0f2b643@localhost> Message-ID: <051.4323412d51d329c83c362571a8f05929@localhost> #1274: Add a MonadState instance for the Parsec monad -------------------------------+-------------------------------------------- Reporter: mux | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: minor | Resolution: wontfix Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:25:47 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 15:16:29 2008 Subject: [GHC] #1516: Add Data.Stream, a library for manipulating infinite lists, to base In-Reply-To: <054.43339e3ad8d3603497be5b7524d3c3b1@localhost> References: <054.43339e3ad8d3603497be5b7524d3c3b1@localhost> Message-ID: <063.163d4165bd39dc51601b9e5a2f76f433@localhost> #1516: Add Data.Stream, a library for manipulating infinite lists, to base -------------------------------------+-------------------------------------- Reporter: WouterSwierstra | Owner: WouterSwierstra Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: streams, infinite lists | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:26:07 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 15:17:23 2008 Subject: [GHC] #1590: Libraries proposal: Add System.Info.isWindows In-Reply-To: <043.2b3b12fca6e8aaefc45387d4677126f3@localhost> References: <043.2b3b12fca6e8aaefc45387d4677126f3@localhost> Message-ID: <052.746f6902cbeccd45b5bacae355356692@localhost> #1590: Libraries proposal: Add System.Info.isWindows ----------------------------+----------------------------------------------- Reporter: neil | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:34:28 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 15:25:10 2008 Subject: [GHC] #1632: Test.HUnit documentation In-Reply-To: <044.8fcf7017003a72ffad0b6da6c98b6015@localhost> References: <044.8fcf7017003a72ffad0b6da6c98b6015@localhost> Message-ID: <053.8557cda67776bb826f288bb655db082d@localhost> #1632: Test.HUnit documentation -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Closing the ticket as suggested. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:35:18 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 15:26:06 2008 Subject: [GHC] #1732: Proposal: Rename haskell@ to haskell-announce@ In-Reply-To: <043.bb58f5b9948256d588e8ad4b7a636f93@localhost> References: <043.bb58f5b9948256d588e8ad4b7a636f93@localhost> Message-ID: <052.516fd7fce193764d716aabcebd0bd368@localhost> #1732: Proposal: Rename haskell@ to haskell-announce@ ----------------------+----------------------------------------------------- Reporter: neil | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: None | Version: Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:36:05 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 15:27:02 2008 Subject: [GHC] #1802: proposal: fix comparison operations for base:Data.Version.Version In-Reply-To: <068.1dd21a3ede57ae11143c96353900b005@localhost> References: <068.1dd21a3ede57ae11143c96353900b005@localhost> Message-ID: <077.03de2432af782311808f236c1d574891@localhost> #1802: proposal: fix comparison operations for base:Data.Version.Version -------------------------------------------+-------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------------+-------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 15:37:41 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 15:28:53 2008 Subject: [GHC] #1816: Add Data.Set.mapMaybe In-Reply-To: <044.a98c6e7448b21f9b2eab83da6fa39f62@localhost> References: <044.a98c6e7448b21f9b2eab83da6fa39f62@localhost> Message-ID: <053.799b896911c49bb3218e3a0f6e2d046e@localhost> #1816: Add Data.Set.mapMaybe ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 21:34:27 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 21:25:09 2008 Subject: [GHC] #2426: ghc-pkg should treat package.conf as UTF8 In-Reply-To: <044.52bda3c925309f2ed287ef35b894919b@localhost> References: <044.52bda3c925309f2ed287ef35b894919b@localhost> Message-ID: <053.0b657e15eeab09e4f05538d791617306@localhost> #2426: ghc-pkg should treat package.conf as UTF8 ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by duncan): This is easy. Just use `readUTF8File` from `Distribution.Simple.Utils` rather than `readFile` in ghc-pkg. Though for reading from stdin it's slightly harder as we need to put stdin into binary mode first and then use `fromUTF8`. The slightly trickier part is testing. We should at least check that invalid UTF-8 is rejected appropriately (the parsing should do that for us) and that valid multi-byte UTF-8 is round-tripped correctly. I'm not sure what to do for `ghc-pkg describe` when it's going to a console that isn't utf-8. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 21:57:38 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 21:48:16 2008 Subject: [GHC] #2435: Qualified name required when defining type family instance in instance declaration Message-ID: <041.497191dfe597e8898c23dfb8fea641e6@localhost> #2435: Qualified name required when defining type family instance in instance declaration ------------------------+--------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- With these two modules, GHC gives the following error: {{{ Bar.hs:3:30: Not in scope: type constructor or class `T' }}} I have to use Foo.T in the instance definition. This is inconsistent with method definitions which must use unqualified names. {{{ module Foo where class C a where type T a }}} {{{ module Bar where import qualified Foo instance Foo.C Int where type T Int = Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 10 22:04:02 2008 From: trac at galois.com (GHC) Date: Thu Jul 10 21:54:40 2008 Subject: [GHC] #2436: Bad warning when exporting data families Message-ID: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> #2436: Bad warning when exporting data families ------------------------+--------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- {{{ module Foo ( T ) where data family T a }}} {{{ module Bar ( T(..), module Foo ) where import Foo data instance T Int = TInt }}} GHC issues the following warning: {{{ Bar.hs:1:20: Warning: `T' is exported by `module Foo' and `T(..)' }}} However, that's the only way to export both module Foo and TInt from Bar. I don't think GHC should warn here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 04:52:49 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 04:43:29 2008 Subject: [GHC] #2437: More accurate package dependencies Message-ID: <047.68fd28011c214b441523af716564e799@localhost> #2437: More accurate package dependencies ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Moderate (1 day) | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------+------------------------------------------ The problem we want to solve here is that there is currently no distinction between compile-time package dependencies and link-time package dependencies. Often a compile-time dependency is also a link-time dependency, but there are two instances in which it might not be: * Template Haskell: some packages might be required for executing TH code at compile-time, but the compiled code doesn't require those packages to be linked in. * Attributes: we're considering allowing arbitrary attributes to be attached to declarations, where the attributes are compile-time Haskell expressions. The same issue as with TH crops up again here. Currently we figure out which packages to link by looking at the (transitive closure of the) imports. It would be better to look at the external references of the compiled code; some of the packages referred to by imports may not need to be linked. Similarly, we should figure out the dependencies of a ``package`` by taking the union of the link-time dependencies of its compiled modules. This means a small changes to Cabal. None of this is particularly hard, and doesn't need any changes to the interface file format or package database: we just record fewer package dependencies than before. The only tricky bit is traversing the code to figure out what the package dependencies should be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 06:24:08 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 06:14:47 2008 Subject: [GHC] #2381: :reload with non-existent module zeroes out prompt In-Reply-To: <043.d0f7478d3edab2858f756c0c9a2227a1@localhost> References: <043.d0f7478d3edab2858f756c0c9a2227a1@localhost> Message-ID: <052.9a00d26bd0841b28541be637a7785d87@localhost> #2381: :reload with non-existent module zeroes out prompt ---------------------+------------------------------------------------------ Reporter: lumi | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 07:10:03 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 07:00:43 2008 Subject: [GHC] #2381: :reload with non-existent module zeroes out prompt In-Reply-To: <043.d0f7478d3edab2858f756c0c9a2227a1@localhost> References: <043.d0f7478d3edab2858f756c0c9a2227a1@localhost> Message-ID: <052.ef1f9e0eb7b7848126af9ffa62e55805@localhost> #2381: :reload with non-existent module zeroes out prompt ---------------------+------------------------------------------------------ Reporter: lumi | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri Jul 11 11:18:39 BST 2008 Simon Marlow * FIX #2381, and improve the fix for #1565 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 08:15:23 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 08:06:02 2008 Subject: [GHC] #1903: Meta-Proposal: Documentation should be required to say when exports were introduced In-Reply-To: <044.da6cd86fa5c3ad437f9d7f61ff8d23d0@localhost> References: <044.da6cd86fa5c3ad437f9d7f61ff8d23d0@localhost> Message-ID: <053.9b48701ab3cc1149e4349b4621d060a4@localhost> #1903: Meta-Proposal: Documentation should be required to say when exports were introduced ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: Consensus was to wait for tool support -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 08:16:36 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 08:07:14 2008 Subject: [GHC] #1951: Add "writer" Monad instance (, ) o to Control.Monad.Instances In-Reply-To: <044.d983d9ad1795cf879541d88d3708e6e6@localhost> References: <044.d983d9ad1795cf879541d88d3708e6e6@localhost> Message-ID: <053.ac3f8d2d086880ae2272d3608e5322d3@localhost> #1951: Add "writer" Monad instance (,) o to Control.Monad.Instances ----------------------------+----------------------------------------------- Reporter: conal | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 08:18:55 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 08:09:33 2008 Subject: [GHC] #1952: Max and Min for Monoid In-Reply-To: <044.1b83eeaeebb32eb932d16a30464c2990@localhost> References: <044.1b83eeaeebb32eb932d16a30464c2990@localhost> Message-ID: <053.d7bf531c27661d23514507f0b831b4c9@localhost> #1952: Max and Min for Monoid ----------------------------+----------------------------------------------- Reporter: conal | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 08:19:44 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 08:10:22 2008 Subject: [GHC] #1953: Add Bounded instance for IntSet In-Reply-To: <047.7cdd2f7243fdf02fedceb5b12b5b50ce@localhost> References: <047.7cdd2f7243fdf02fedceb5b12b5b50ce@localhost> Message-ID: <056.60b5bba5abfcf666315dae4ee7e7e65c@localhost> #1953: Add Bounded instance for IntSet -------------------------------+-------------------------------------------- Reporter: dbenbenn | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 08:22:58 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 08:13:36 2008 Subject: [GHC] #1960: Add Applicative and Monoid instances for STM In-Reply-To: <044.27a2327a98dc1a1cd8d85ed41bd79a60@localhost> References: <044.27a2327a98dc1a1cd8d85ed41bd79a60@localhost> Message-ID: <053.67b890bb6ba0b99bc51a8dc630536f9a@localhost> #1960: Add Applicative and Monoid instances for STM ----------------------------+----------------------------------------------- Reporter: conal | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 08:24:02 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 08:14:40 2008 Subject: [GHC] #1979: Add variants of tails and inits not returning empty lists In-Reply-To: <042.eee84c189971ebc491448af82b5b6e8c@localhost> References: <042.eee84c189971ebc491448af82b5b6e8c@localhost> Message-ID: <051.0da179c65812dc4fe8c9808c7023251a@localhost> #1979: Add variants of tails and inits not returning empty lists ----------------------------+----------------------------------------------- Reporter: mux | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 08:59:23 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 08:50:01 2008 Subject: [GHC] #2371: `ghci` prints confusing error message if using ":m +" instead of ":load" In-Reply-To: <042.6d6fecd723db25e5988b42fab7d3915f@localhost> References: <042.6d6fecd723db25e5988b42fab7d3915f@localhost> Message-ID: <051.02e14960cf8bb522da4d6f6a9452fd9b@localhost> #2371: `ghci` prints confusing error message if using ":m +" instead of ":load" ---------------------+------------------------------------------------------ Reporter: bos | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I added the above explanation (more or less) to the docs. {{{ Fri Jul 11 13:00:46 BST 2008 Simon Marlow * #2371: try to explain the difference between :module and :load }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 08:59:49 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 08:50:27 2008 Subject: [GHC] #2201: "ghc-pkg --user describe '*'" fails with empty user db In-Reply-To: <045.673a6cc9904f9063d50fb7c9230e5305@localhost> References: <045.673a6cc9904f9063d50fb7c9230e5305@localhost> Message-ID: <054.efcd5e88170bf60ee75c7ea62b5c36a5@localhost> #2201: "ghc-pkg --user describe '*'" fails with empty user db ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: ghc-pkg dump implemented: {{{ Fri Jul 11 13:17:39 BST 2008 Simon Marlow * add "ghc-pkg dump" (fixes #2201) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 09:04:55 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 08:55:36 2008 Subject: [GHC] #2438: memory performance problem when compiling lots of derived instances in a single file Message-ID: <044.ea581854aeddeff62675b30ef35f5bfc@localhost> #2438: memory performance problem when compiling lots of derived instances in a single file ---------------------------------------------+------------------------------ Reporter: claus | Owner: Type: compile-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------------------+------------------------------ I'm playing with deriving `Data/Typeable` for the GHC AST types (you'll need a recent HEAD for the standalone deriving fixes #2378, and I've got to use the generics-internal CPP tricks to work around #2433). After getting the first compiler-complaint-free version of the instances source, self-same compiler went away and tried to get all the memory it could find (I had to kill the process). After splitting the source into two, one importing the other, there is no problem loading them anymore. - `Instances.hs` imports `Instances0.hs`: loading `Instances` into `GHCi, version 6.9.20080709` works fine. - `All.hs` merges the source of `Instances` and `Instances0` into a single module: trying to load `All` into `GHCi, version 6.9.20080709` consumes memory like crazy. Compiling `All.hs` shouldn't behave like this in the first place, but if just splitting the file into two helps, the compiler should be able to do the split implicitly (sparing me the manual dependency analysis). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 09:12:58 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 09:03:36 2008 Subject: [GHC] #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 In-Reply-To: <046.25be20912976f68417223aab5966cd22@localhost> References: <046.25be20912976f68417223aab5966cd22@localhost> Message-ID: <055.74df2eaa809d99a3c87c9e4f1966a957@localhost> #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: simonpj Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by simonmar): * priority: normal => high * milestone: 6.10 branch => 6.10.1 Comment: Sounds like this is important to fix in 6.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 09:17:43 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 09:08:20 2008 Subject: [GHC] #2042: Add concatMapM to Control.Monad In-Reply-To: <045.29d0c149fb4003aa216c4f2f5995cca5@localhost> References: <045.29d0c149fb4003aa216c4f2f5995cca5@localhost> Message-ID: <054.cda5a716affff6cb580523d56188d6c2@localhost> #2042: Add concatMapM to Control.Monad ----------------------------+----------------------------------------------- Reporter: twanvl | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 09:18:59 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 09:09:37 2008 Subject: [GHC] #2048: Add split and splitWith to Data.List In-Reply-To: <045.7155003e42a360739f457ed29bf408d6@localhost> References: <045.7155003e42a360739f457ed29bf408d6@localhost> Message-ID: <054.2875f239a5ef6f665660deba0bf22d94@localhost> #2048: Add split and splitWith to Data.List ----------------------------+----------------------------------------------- Reporter: twanvl | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 09:23:17 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 09:13:55 2008 Subject: [GHC] #2322: cmath library broken with -fvia-C In-Reply-To: <047.4f5ed74e9c0974e832a64d783dd3e20d@localhost> References: <047.4f5ed74e9c0974e832a64d783dd3e20d@localhost> Message-ID: <056.a1b899ad3e09998a9a74c611bac7ae32@localhost> #2322: cmath library broken with -fvia-C ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 09:23:19 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 09:14:01 2008 Subject: [GHC] #2095: add new forms of unsafePerformIO and unsafeInterleaveIO In-Reply-To: <045.5095ff0368131dd388cc57b0746afe94@localhost> References: <045.5095ff0368131dd388cc57b0746afe94@localhost> Message-ID: <054.f54a7f0f8f88febdebaa775039c004a9@localhost> #2095: add new forms of unsafePerformIO and unsafeInterleaveIO ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 09:27:47 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 09:18:58 2008 Subject: [GHC] #2099: Storable instance for Complex In-Reply-To: <047.c8eaa83814b0476331366f6ca4bff701@localhost> References: <047.c8eaa83814b0476331366f6ca4bff701@localhost> Message-ID: <056.63677695bcb23b9c5dd3d9102f16601d@localhost> #2099: Storable instance for Complex ----------------------------+----------------------------------------------- Reporter: jedbrown | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This proposal seems to be abandoned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 09:28:39 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 09:19:18 2008 Subject: [GHC] #2284: Stack-hack optimization causes much re-computation in GUI callbacks In-Reply-To: <048.962fc54d8c39b16cf1f38c360fbbf18e@localhost> References: <048.962fc54d8c39b16cf1f38c360fbbf18e@localhost> Message-ID: <057.186bf7bc9d36e3800374f741341f7eb1@localhost> #2284: Stack-hack optimization causes much re-computation in GUI callbacks -----------------------+---------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -----------------------+---------------------------------------------------- Changes (by simonmar): * milestone: 6.10 branch => _|_ Comment: _|_, since it's a duplicate of #1168 and we have no short term plans to fix that -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 09:39:12 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 09:29:55 2008 Subject: [GHC] #2430: Fix bug 1985 In-Reply-To: <047.9b5bc10cea52198550e3d65f8d7c196b@localhost> References: <047.9b5bc10cea52198550e3d65f8d7c196b@localhost> Message-ID: <056.7cf2075b8374955c3c6321b629cfafa4@localhost> #2430: Fix bug 1985 -------------------------------+-------------------------------------------- Reporter: dbenbenn | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * cc: libraries@haskell.org (removed) * difficulty: => Unknown * milestone: => Not GHC Comment: I don't think there is any need to drag things out that long. I'd suggest 2 weeks should be fine for this proposal. You also need to send a message to libraries@ describing the proposed change (with the details in the message rather than just a URL is best) and referencing this ticket, and will need to summarise the discussion in this ticket when it's over. Please see http://www.haskell.org/haskellwiki/Library_submissions for more info. I think the CC to libraries@haskell.org failed because the list doesn't think that trac is a subscriber. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 09:43:12 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 09:33:50 2008 Subject: [GHC] #2278: Inconsistent behaviour between -odir and -hidir options In-Reply-To: <044.da2157b8bb277561bb6fe2b75576c141@localhost> References: <044.da2157b8bb277561bb6fe2b75576c141@localhost> Message-ID: <053.34a552a1c355a9e36094d1062c1dfe86@localhost> #2278: Inconsistent behaviour between -odir and -hidir options ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 10:19:19 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 10:09:59 2008 Subject: [GHC] #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs In-Reply-To: <046.59221d2fec02e33b156d46e404241b5d@localhost> References: <046.59221d2fec02e33b156d46e404241b5d@localhost> Message-ID: <055.50d92347b91678f3018a848b70e2d0bf@localhost> #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs ----------------------+----------------------------------------------------- Reporter: oboudry | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: reopened => new * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 11:48:25 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 11:39:11 2008 Subject: [GHC] #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 In-Reply-To: <046.25be20912976f68417223aab5966cd22@localhost> References: <046.25be20912976f68417223aab5966cd22@localhost> Message-ID: <055.1e58a0eebc5f1ef6560afc938f9d190b@localhost> #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: simonpj Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Comment (by maeder): probably related to #955 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 11:55:39 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 11:46:17 2008 Subject: [GHC] #2439: Missed optimisation with dictionaries and loops Message-ID: <041.4a9e022e22f0d06a0023c060ae99c7bb@localhost> #2439: Missed optimisation with dictionaries and loops -----------------------------------------+---------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- {{{ {-# LANGUAGE BangPatterns #-} module Foo (sum') where foldl' :: (a -> b -> a) -> a -> [b] -> a {-# INLINE foldl' #-} foldl' f !z xs = loop z xs where loop !z [] = z loop !z (x:xs) = loop (f z x) xs sum' :: Num a => [a] -> a sum' xs = foldl' (+) 0 xs }}} This is the code before !LiberateCase: {{{ Foo.sum' = \ (@ a_a9T) ($dNum_aa1 [ALWAYS Just L] :: GHC.Num.Num a_a9T) -> let { lit_scm [ALWAYS Just L] :: a_a9T [Str: DmdType] lit_scm = case $dNum_aa1 of tpl_B1 [ALWAYS Just A] { GHC.Num.:DNum tpl_B2 [ALWAYS Just A] tpl_B3 [ALWAYS Just A] tpl_B4 [ALWAYS Just A] tpl_B5 [ALWAYS Just A] tpl_B6 [ALWAYS Just A] tpl_B7 [ALWAYS Just A] tpl_B8 [ALWAYS Just A] tpl_B9 [ALWAYS Just A] tpl_Ba [ALWAYS Just C(S)] -> tpl_Ba lvl_sbH } } in letrec { loop_sck [ALWAYS LoopBreaker Nothing] :: a_a9T -> [a_a9T] -> a_a9T [Arity 2 Str: DmdType SS] loop_sck = \ (z_a6Y :: a_a9T) (ds_db7 :: [a_a9T]) -> case z_a6Y of z_X7h [ALWAYS Just L] { __DEFAULT -> case ds_db7 of wild_B1 [ALWAYS Just A] { [] -> z_a6Y; : x_a72 [ALWAYS Just L] xs_a74 [ALWAYS Just S] -> case $dNum_aa1 of tpl_Xl [ALWAYS Just A] { GHC.Num.:DNum tpl_B2 [ALWAYS Just A] tpl_B3 [ALWAYS Just A] tpl_B4 [ALWAYS Just C(C(S))] tpl_B5 [ALWAYS Just A] tpl_B6 [ALWAYS Just A] tpl_B7 [ALWAYS Just A] tpl_B8 [ALWAYS Just A] tpl_B9 [ALWAYS Just A] tpl_Ba [ALWAYS Just A] -> loop_sck (tpl_B4 z_a6Y x_a72) xs_a74 } } }; } in \ (xs_a76 :: [a_a9T]) -> loop_sck lit_scm xs_a76 }}} Note that the Num dictionary is scrutinised in the loop even though sum' is actually strict in the dictionary (by virtue of being strict in lit_scm) and it would make sense to take it apart before entering the loop. !LiberateCase does nail this but only if the loop is small enough and at the expense of code size. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 11:57:31 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 11:48:08 2008 Subject: [GHC] #2440: Bad code with type families Message-ID: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> #2440: Bad code with type families -----------------------------------------+---------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- {{{ {-# LANGUAGE TypeFamilies, ScopedTypeVariables #-} module Foo (foo) where import Control.Monad.ST import Data.STRef class V v where type M v :: * -> * rd :: v -> Int -> M v Int data Vec s = Vec (STRef s Int) instance V (Vec s) where type M (Vec s) = ST s rd (Vec r) n = do m <- readSTRef r return (m+n) foo :: forall s. Vec s -> Int -> ST s Int foo v n = go n where go 0 = return 0 go n = do m <- rd v n -- :: ST s Int go m }}} ghc -O2 generates rather bad code for this (look at $wfoo). If I uncomment the type signature in the second to last line, the code becomes much better. It would be nice if this worked without the signature since I can't add it in the real code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 11 19:12:31 2008 From: trac at galois.com (GHC) Date: Fri Jul 11 19:03:44 2008 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.e0f0d8b746a169e0b79ac80d4690751e@localhost> #1346: bootstrap from HC files --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by ajd): * cc: alexander.dunlap@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 06:44:36 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 06:35:12 2008 Subject: [GHC] #2441: Ghc-pkg cannot unregister/expose/hide packages in non-first package databases Message-ID: <053.1e7052fd8e6f933efbd3d50f72491d93@localhost> #2441: Ghc-pkg cannot unregister/expose/hide packages in non-first package databases -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- I was in this situation: {{{ $ ghc-pkg list /usr/local/lib/ghc-6.8.2/package.conf: Cabal-1.2.3.0, Cabal-1.5.1, Finance-Quote-Yahoo-0.4.1, GLUT-2.1.1.1, HTTP-3001.0.4, HTTP-Simple-0.1, HUnit-1.2.0.0, OpenAL-1.3.1.1, QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.1.0, binary-0.4.1, bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.1, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, hxt-7.4, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, plugins-1.0, plugins-1.1, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, unix-2.3.0.0, xhtml-3000.0.2.1, zlib-0.4.0.4 /Users/mbolingbroke/.ghc/i386-darwin-6.8.2/package.conf: Cabal-1.4.0.0, GLUT-2.1.1.1, HDBC-1.1.4, MaybeT-0.1.1, MonadRandom-0.1.1, OpenGL-2.2.1.1, Stream-0.2.3, arrows-0.4, category-extras-0.53.4, haddock-2.1.0 }}} And from there I can do this: {{{ $ ../../../../ghc.plugins/utils/ghc-pkg/ghc-pkg-inplace describe pan- plugin-annotations name: pan-plugin-annotations version: 1.0 license: BSD3 copyright: (c) Sean Seefried 2008 maintainer: sseefried@cse.unsw.edu.au stability: stable homepage: ... }}} But not this! {{{ $ ../../../../ghc.plugins/utils/ghc-pkg/ghc-pkg-inplace expose pan-plugin- annotations-1.0 ghc-pkg-inplace: cannot find package pan-plugin-annotations-1.0 }}} Or this: {{{ $ ../../../../ghc.plugins/utils/ghc-pkg/ghc-pkg-inplace hide pan-plugin- annotations-1.0 ghc-pkg-inplace: cannot find package pan-plugin-annotations-1.0 }}} The reason is that ghc-pkgs modifyPackage function only looks in the FIRST package database in the list. In my opinion, it should look in all databases and either: 1. Perform the modification requested by the user to the first database that contains the relevant package 2. Show a smart error message indicating to the user that they need to use some flags to bring that package to the front of the package stack if they want to do that, rather than just saying "not found" I've attached a patch that implements behaviour 1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 10:40:53 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 10:31:28 2008 Subject: [GHC] #1657: throwTo + unsafeInterleaveIO oddness In-Reply-To: <044.21440a48538e444ebfd4d18aeba61e97@localhost> References: <044.21440a48538e444ebfd4d18aeba61e97@localhost> Message-ID: <053.23a89db35651fbe6c18eaf872897e72b@localhost> #1657: throwTo + unsafeInterleaveIO oddness ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 10:41:28 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 10:32:04 2008 Subject: [GHC] #418: throwTo to a thread inside 'block' In-Reply-To: <044.bf7a58746fbda955e298abdfd4e1a463@localhost> References: <044.bf7a58746fbda955e298abdfd4e1a463@localhost> Message-ID: <053.a933838996a80c0e2af92cc4c6d92cb3@localhost> #418: throwTo to a thread inside 'block' ----------------------------+----------------------------------------------- Reporter: remit | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 10:42:20 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 10:32:54 2008 Subject: [GHC] #1963: Pressing ^C at the right moment can trash GHC's package list In-Reply-To: <044.fe68034f1a304106efaa8e4a323fded8@localhost> References: <044.fe68034f1a304106efaa8e4a323fded8@localhost> Message-ID: <053.750c804b4ec9870c2ef745e9050086e4@localhost> #1963: Pressing ^C at the right moment can trash GHC's package list ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: reopened => new * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 11:37:13 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 11:27:53 2008 Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of range. In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost> References: <044.2f007075e8a3e652be5aa7c77056c714@localhost> Message-ID: <053.86df6fa1b841fba38ac60cb16dfa0b03@localhost> #2013: ghci crash on startup: R_X86_64_32S relocation out of range. ---------------------+------------------------------------------------------ Reporter: mboes | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ---------------------+------------------------------------------------------ Changes (by igloo): * status: closed => reopened * resolution: fixed => * milestone: 6.8.3 => 6.10.1 Comment: This still needs to be fixed in the 6.10 branch, right? And see also #2351. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 11:37:33 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 11:28:28 2008 Subject: [GHC] #2351: NetBSD defines ELF_ST_TYPE In-Reply-To: <043.48a409a4ca4cc55c3e518b567c9a2f02@localhost> References: <043.48a409a4ca4cc55c3e518b567c9a2f02@localhost> Message-ID: <052.d8fe2f5b81edeae39d1ce3fa434a785c@localhost> #2351: NetBSD defines ELF_ST_TYPE ----------------------------+----------------------------------------------- Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: NetBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: igloo => Comment: This is part of #2013. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 12:43:10 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 12:33:45 2008 Subject: [GHC] #1140: Use ccall for OpenAL on Windows (was part of #918) In-Reply-To: <050.05b204e0ec3bd6a7e024453253e68c3e@localhost> References: <050.05b204e0ec3bd6a7e024453253e68c3e@localhost> Message-ID: <059.ae3504a34f8410b919d83a3b1320f149@localhost> #1140: Use ccall for OpenAL on Windows (was part of #918) -------------------------------+-------------------------------------------- Reporter: thorkilnaur | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.4.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: N/A | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Patch applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 13:02:10 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 12:52:45 2008 Subject: [GHC] #1578: darcs-all work around for darcs Issue 467 In-Reply-To: <050.82dc7750448592d9a1100bb73641b191@localhost> References: <050.82dc7750448592d9a1100bb73641b191@localhost> Message-ID: <059.3cf28d0032a18c3310dc1d4210fd2b42@localhost> #1578: darcs-all work around for darcs Issue 467 --------------------------+------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * owner: igloo => * milestone: 6.10 branch => _|_ Comment: None of these give the right answer on Windows: {{{ use Cwd; use File::Spec; $x = File::Spec->rel2abs("."); print "$x\n"; print cwd(), "\n"; print getcwd(), "\n"; print fastgetcwd(), "\n"; }}} and cygwin's `pwd` program doesn't either. If someone knows how to portably get the current working directory with perl then this is easy to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 13:53:42 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 13:44:16 2008 Subject: [GHC] #1578: darcs-all work around for darcs Issue 467 In-Reply-To: <050.82dc7750448592d9a1100bb73641b191@localhost> References: <050.82dc7750448592d9a1100bb73641b191@localhost> Message-ID: <059.ad134eeb627873795c74679295def347@localhost> #1578: darcs-all work around for darcs Issue 467 --------------------------+------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Comment (by claus): if you can use cygwin's `pwd`, you can use its `cygpath`, but if you don't want to depend on cygwin, how about: {{{ $ ghc -e System.Directory.getCurrentDirectory "C:\\cygwin\\home\\cr3" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 14:13:00 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 14:03:34 2008 Subject: [GHC] #1578: darcs-all work around for darcs Issue 467 In-Reply-To: <050.82dc7750448592d9a1100bb73641b191@localhost> References: <050.82dc7750448592d9a1100bb73641b191@localhost> Message-ID: <059.efc74af9318ebd714eaada836e6c23bb@localhost> #1578: darcs-all work around for darcs Issue 467 --------------------------+------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Comment (by igloo): Replying to [comment:6 claus]: > if you can use cygwin's `pwd`, you can use its `cygpath`, but if you don't want to depend on cygwin, how about: It has to work everywhere people build GHC. > {{{ > $ ghc -e System.Directory.getCurrentDirectory > "C:\\cygwin\\home\\cr3" > }}} This only works on platforms that support GHCi, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 17:10:20 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 17:00:57 2008 Subject: [GHC] #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception In-Reply-To: <044.6fa473611ed5d150325a47086f85da68@localhost> References: <044.6fa473611ed5d150325a47086f85da68@localhost> Message-ID: <053.e730c5a130384300980f387d3e5144ed@localhost> #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by spookylukey): I have the same thing, trying to install on CentOS 4.5 This should really be a wontfix, not invalid. Also, it would be nice to know *before* downloading etc that it isn't going to work. The download page for GHC should at least have a message stating the requirements for the binary. CentOS 4.5 has glibc 2.3.4, BTW. This may seem ancient, but in lots of shared hosting environments, this kind of thing is typical -- hosts like stability and don't care for the latest versions of everything. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 18:20:40 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 18:11:13 2008 Subject: [GHC] #1824: Make an extension flag for postfix operators In-Reply-To: <044.3feac532d20baf671d78343c6784773a@localhost> References: <044.3feac532d20baf671d78343c6784773a@localhost> Message-ID: <053.88ea504006cec25e60cefc56bf8146f8@localhost> #1824: Make an extension flag for postfix operators -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Parser) | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Sat Jul 12 21:37:25 BST 2008 Ian Lynagh * Add PostfixOperators flag for (e op) postfix operators; fixes trac #1824 -fglasgow-exts also turns it on. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 12 22:06:21 2008 From: trac at galois.com (GHC) Date: Sat Jul 12 21:56:55 2008 Subject: [GHC] #2442: Heuristics to improve error messages for badly referenced things Message-ID: <053.d96b74737451be892238b37815ca44b6@localhost> #2442: Heuristics to improve error messages for badly referenced things -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- I propose the implementation of fuzzy-matching heuristics so we can get errors like this: {{{ Prelude> fsa :1:0: Not in scope: `fsa' Maybe you meant `fst' Prelude> import Data.Lits Could not find module `Data.Lits': Use -v to see a list of the files searched for. Maybe you meant `Data.Bits' or `Data.List' Prelude> }}} And a heuristic such that when resolution of an unqualified name fails it can suggest a qualified alternative: {{{ module Main where import qualified Char main = print (isSpace ' ') }}} {{{ $ stage2/ghc-inplace --make Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:4:14: Not in scope: `isSpace' Maybe you meant `Char.isSpace' }}} I believe both of these represent an improvement to the compiler user experience. If you wish to implement this feature in GHC, I have implemented, documented and tested it already and the patches are attached. It is under flag control: use -fno-helpful-errors to disable it. This is turned by default for the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 00:24:58 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 00:15:39 2008 Subject: [GHC] #2435: Qualified name required when defining type family instance in instance declaration In-Reply-To: <041.497191dfe597e8898c23dfb8fea641e6@localhost> References: <041.497191dfe597e8898c23dfb8fea641e6@localhost> Message-ID: <050.e729e71cc37c145045e8bc3ebe5546dc@localhost> #2435: Qualified name required when defining type family instance in instance declaration -------------------------+-------------------------------------------------- Reporter: rl | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Changes (by chak): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 00:26:17 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 00:16:53 2008 Subject: [GHC] #2436: Bad warning when exporting data families In-Reply-To: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> References: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> Message-ID: <050.f17abced99f071386cf81e533b283f88@localhost> #2436: Bad warning when exporting data families -------------------------+-------------------------------------------------- Reporter: rl | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Changes (by chak): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 06:02:04 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 05:52:37 2008 Subject: [GHC] #1578: darcs-all work around for darcs Issue 467 In-Reply-To: <050.82dc7750448592d9a1100bb73641b191@localhost> References: <050.82dc7750448592d9a1100bb73641b191@localhost> Message-ID: <059.42328e1aaba5999e35bbd9931325eeb1@localhost> #1578: darcs-all work around for darcs Issue 467 --------------------------+------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Comment (by Isaac Dupree): perhaps `ghc -e -fobject-code` or the upcoming ghci-working-everywhere... but if we're staying compatible back to 6.4, really, why not just compile a binary from {{{ import System.Directory(getCurrentDirectory) main = print =<< getCurrentDirectory }}} and run it? I've never understood why the ghci-capability should be required for anything but the fancier things that ghci, template-haskell etc. do... even the basic functionality of GHCi could, it seems, be achieved with nothing but object code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 07:27:55 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 07:18:28 2008 Subject: [GHC] #2443: @EnableWin32DLLs@ in mk/config.mk Message-ID: <045.5cbd6ee8b0d9740b3306b11c8e19da4a@localhost> #2443: @EnableWin32DLLs@ in mk/config.mk -----------------------+---------------------------------------------------- Reporter: rurban | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Multiple -----------------------+---------------------------------------------------- @EnableWin32DLLs@ should be temp. disabled also. [EnableWin32DLLs.patch rurban@x-ray.at**20080713112530] hunk ./mk/config.mk.in 410 -DLLized=@EnableWin32DLLs@ +#temp. disabled. was @EnableWin32DLLs@ +DLLized=NO -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 07:34:54 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 07:25:27 2008 Subject: [GHC] #2443: @EnableWin32DLLs@ in mk/config.mk In-Reply-To: <045.5cbd6ee8b0d9740b3306b11c8e19da4a@localhost> References: <045.5cbd6ee8b0d9740b3306b11c8e19da4a@localhost> Message-ID: <054.a8f2c647b6c0265ed1edb6b063835d91@localhost> #2443: @EnableWin32DLLs@ in mk/config.mk -----------------------------+---------------------------------------------- Reporter: rurban | Owner: rurban Type: bug | Status: assigned Priority: normal | Milestone: Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Multiple -----------------------------+---------------------------------------------- Changes (by rurban): * status: new => assigned * owner: => rurban -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 10:22:32 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 10:13:06 2008 Subject: [GHC] #2424: Error compiling Crypto-4.1.0 on ghc-6.8.3 In-Reply-To: <047.5175165ab642b3e70df2d2bcd3e5fe6e@localhost> References: <047.5175165ab642b3e70df2d2bcd3e5fe6e@localhost> Message-ID: <056.a402e80295ca63c8e19027fce3adfaba@localhost> #2424: Error compiling Crypto-4.1.0 on ghc-6.8.3 ----------------------+----------------------------------------------------- Reporter: kristall | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by igloo): Doesn't happen on amd64/Linux. Turns out the problem is caused by large literal Integers (or more precisely, presumably the expressions GHC generates to build the large Integer out of words): {{{ $ ghc -fforce-recomp -O --make q [1 of 1] Compiling Main ( q.hs, q.o ) ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 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 }}} `q.hs`: {{{ i :: Integer i = 0xe79701ff44ecfe5a7e97306a9c93791a2b4a6948e0aa06797f7cc8cbfbf1e82bdf7edbc7ecea19c604a62237475cc3487bca95b9b1d1c89025c91e0d67183ae0b8031b9ab7c4e4623ddcdee985aabfa0903d2d28c7677e09e312c2a80ad703733acdcb5feb9fe794f0e26b669fa5f6883149377c6c93b04e7fffba822d57ca4b2d85f2fed1a6abc5e75fd198dd74ef692896bd9fe57de7c6c137108517c017d059d2995eb1feb75ee8fc1966864032ac3bcdc6787d4eaad97363cc981239736a865dc769d3d293c5bc614ab7e43048b733965bef7b2e82ef5b2af4a264ea64817bce84067e48c8642b356c753d6db8f4d79883ec2644f6704335928d56fc747d01ccd81dfc88dda2fc208887da1e0ac9f17c4657c8b98ec4f12cad4030972bc6e0ffcc9793bb5ae6f9cca4d5036cc7a047e9ac18a7b4d2542db54ea33ae210c4e010675a8c09c89ae8decb47ff7f76e0a388be180b5e4b86c17b7c9ebc06abe0c8a7b24f2f99ad25920102c5187e9ff1cb01833d3edf80c373243f19fd2b8480626bb35ec39494efbfdb53379491cb3b87fb0370875ef9740d599ffc4677240e74057470922102603614c585bce28026a11f479a2d033fff55c1a52fdf1512f0c71cfd6be26981e0c1556097d896491adf1456a179f8d9ce1405589a102bd69023595439fc9498d726462d5530d8ab7f0b82396fb3624f4711ccc12621e2f954506483c028c9d0ad2e8e33a80bce30bdeb13f6ea236c2ad416bfe6b9596102a615e492eaad30afcaa1d57b76b3a05f3c486d97fc103bf1dce986d13c01d179ed3b82879dd5f2bf9647c50ba96e77c064e938238cc4fa2cc753c88a986159e6908be56cc3e637887ae804ed27857bdc9e981da38185cf64fc1c2d17b3c122d2f9cab54843292691dc4b3a29da40d33a501bc31ec59ce21fe50c5f82776953c58fc39c2405e6e862253910c5a8e6a863e43bd49c3f515ce8e9eb03d3cba01545ba3d4007f165a483be7a2dcb7bc121ddc0c0f526d7eb65447080c41096b090dce2ff49f9efed837d0dd63b423a1767324e72d0c275b424bde2944743c2dfeb116fd26003e7c7add67c15df33cd31a1e9f4190d7b01f2c2daa8ef377336764f6cc97e2d2bc13c491972fec3a51b57f88b1c7c545663ee672328593aa9dabce37659cb577b659280cb575a8fa00ed0949f2d644b5d84f03921cb9af8ec96fbd0b6858187fbbb11797692f1eb2d8de69cad8f999d974a3f635bf9791b4452793db5b66764b2ac035da18d8b7d5281df383ea9e3f00c9e250b5a1bc048b9f68053f9554697a81eae53d5aff0f019d00492d9e50aedc569e85aa4973529546a56390cc8e6c7e5fa5c849960e7ea8a639dcf06aad53bc991d177c3d7a1661c96431876790f9d7229531775083a13ac22f21a4d610d822000288a3f41cba71a639118bdce89c05692db35f10faf1587f54a9937707a6cd39c35bd9e3f7d9354b786606b311bda991c3e0696de0f9523c5ef744b40e49fe94f3f366a387dd2d47c6c1907098f9044b1c2b1ebdb213e897827d4113913c36aff901d2a94940da298896a1abeab8c5d38b15f796fafb5c0f83be112c3cf815f966e9b67ba8aecc4f5267c2bb83876ef985137c6027fa5d02b73c2d547df81cffb22d8a814271644798a77c25efdf5ffbbeb625cfd5bb4c2fb16a0e32b0c6ac216f4fb75093334290eff82681ac4b29788c607c3c6098a9d4f6ea2c2d91ee440cf2b2c560175ed7c9bcbc5a3535355bee72c4f81c751d0690ec1f1fcb7dd99520e1195d464b6ea44073769fe7273857dc063622067fd2e2e2258b4192f102effbbec5b769bbed2893c8b96feddeceadbfbb467280dd34bf5727b149fa8814e50be05a9c50c554e54210f732dfd862de08167861f239dd0c5e67139188af69f4bffa4a548204306ac9e0b29123a09f69438c4e98f102164a766844a0b3c38c9fa671177873f4fa1999bc6df35fd3cec000913b5ff3c28b0a2dafa6f01280f7565dc93480ad243c8230089be1face8b82bdc9b15f80f795cbe2a1cd281b5424b934773405a3fe52253b59cee57b1d5021d9aa52f01f1de0f033f3298134b9bf28c91fa86fef0fe5830a347966572cb71df29792ba24a1d717aff84ec3f52e01358a06d437e4b5511c2b0d2dfd25992ad78735f326382ff2b2a5359f48e32da55005e179e63bab4f612c584f025ccf15ff05f9f6ccd014ce51c23fbd8875451618bb23fc033a4e1ae27cba6f2e635b22f50d48000672fcc465658b0c1b31e0dde01832cd07971a5e20aa8800c9efb9bc49fbc4b16b97546f7e2d8c1d798f9d5756abb27f7ba88c83ac1465a67d48675c7e5fe49d84c3984a0c88d7641c04e72cecf41785d8053125d568b7c2a103e07df2a82bf6ca7e44ce80e5e1628b383ad9037fd672952394bf4d0612d7eda8b1bb57730f8fa53df6777be32ebb3f7024c63abd73c84b9a23aa638afb78bbbd577f0d3f03babd6919df6dff33b0b163117f132b73e953cf6a81c955d60783a84e43947aacfa6ba61b50d7a884f57987ad8dfd485b685639e5dfeef52716ee0002a38da46fd1486b9796396d96fc0034455d89929ec7bb60021f34f78319433b1119494ac0d1dc300afa13bcee26ee1f657828a8b28a0be85bca3bcb6ea13bd0061f67dc447e8f89d206e714ff288b9faa685ae94b21b0295f5b73ef4e2120653e1059e77f29eadfa94734144e53614b70a8a0e2ad1150a9995d7dd1a63ba94135a6afeab58666b7ed358b29504a279954b39b036cfb65ff765aaa211b332f1a995cca549bf69b891a4c4cd2a97f170fc30399ea1f22588192ad994bf1aa3a57b57d49c3a70cf1f9bd05f99ebe64e81548333e051838b0d65af0bbb0de23536f36b2aea64b3bf250420d21ec138df35050ace7c30c90f7745bbe920e3510f2e78987597b1d061543559c56492d7cc13778eb37c250eda4d20151bca2ab15a1571a55dac080ede339446df7448093ea413d689e7179813175e8648c1c8483d71485b8c3050b65e4a8aaec955c9175d6e3facf9c6f0b1e35e66d6180ea75fe1cc6482a72b7310082280582b0fff4950fb64d6ab20979f72a8a2cd35b8ad3d6ead2de259a658640542dc0dababd0e640d3eb1d46fdf4aae780793244c7c42c0b9d0b4247a7e7fa7d320795f4302638547c3a497366ef1c6b6b53cff044d372e023666b1c390819977b6ab8aca6e885b580bb22d961703b25f3986ade36c25816c7a6267e61a30b7ba46c3e7c15fe168a67d56f21f95f513e9fb1ccb9a57926d51133391629a016523574ee0b864f33fcb7effaf233a4a4ddf704bd279adf24448a766c8b98e78344b7ec910200c52333fa7389f519277c2b84fa05d01bde9a8cb9d58985b6619a78b13bef088c473056b7c8e5d1b2d12350cdfc6b5e335dcfd426b956ae8cf4a217abc9d0c631bea08d7756d62f0688e0735b70b876e7450c455a8b9dab2189e5482dfefce3f710bc02c18524b71e35fabcb4bfb4c2417c9907dcb124277e09a934c0423a08e626ccda1dbd961001c1ba54625227ea48ebbe413495b4c8a95a3702ebfd54dd07 main :: IO () main = print i }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 11:26:33 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 11:17:14 2008 Subject: [GHC] #2388: GHC creates invalid test instruction for 64-bit code In-Reply-To: <056.33dc1f03d68892257923e7c03147f8f1@localhost> References: <056.33dc1f03d68892257923e7c03147f8f1@localhost> Message-ID: <065.be0113e7059305b0737ff1eb2dcbca84@localhost> #2388: GHC creates invalid test instruction for 64-bit code -------------------------------+-------------------------------------------- Reporter: MartinGrabmueller | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Comment (by igloo): Small testcase: {{{ module Q where import Data.Bits import Data.Word splitBytes :: Word32 -> Char splitBytes w | w .&. 0x80000000 /= 0 = 'a' splitBytes _ = 'b' }}} {{{ ghc-inplace --make -O q [1 of 1] Compiling Q ( q.hs, q.o ) /tmp/ghc10020_0/ghc10020_0.s: Assembler messages: /tmp/ghc10020_0/ghc10020_0.s:28:0: Error: suffix or operands invalid for `test' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From david.waern at gmail.com Sun Jul 13 09:49:42 2008 From: david.waern at gmail.com (David Waern) Date: Sun Jul 13 11:29:03 2008 Subject: [GHC] #2436: Bad warning when exporting data families In-Reply-To: References: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> <050.f17abced99f071386cf81e533b283f88@localhost> Message-ID: 2008/7/13 David Waern : > 2008/7/13 GHC : >> #2436: Bad warning when exporting data families >> -------------------------+-------------------------------------------------- >> Reporter: rl | Owner: chak >> Type: bug | Status: new >> Priority: normal | Milestone: >> Component: Compiler | Version: 6.9 >> Severity: normal | Resolution: >> Keywords: | Testcase: >> Architecture: Unknown | Os: Unknown >> -------------------------+-------------------------------------------------- >> Changes (by chak): >> >> * owner: => chak >> >> -- >> Ticket URL: >> GHC >> The Glasgow Haskell Compiler >> _______________________________________________ >> Glasgow-haskell-bugs mailing list >> Glasgow-haskell-bugs@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs >> >> > > Correct me if I'm wrong, but shouldn't GHC report here that data > instances can't be exported? Or can they be exported? When > implementing Type Family support in Haddock, I could see no way to > export type/data instances using the GHC AST. > > David > With exported, I mean explicitly exported, of course. David From trac at galois.com Sun Jul 13 11:42:25 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 11:32:56 2008 Subject: [GHC] #2442: Heuristics to improve error messages for badly referenced things In-Reply-To: <053.d96b74737451be892238b37815ca44b6@localhost> References: <053.d96b74737451be892238b37815ca44b6@localhost> Message-ID: <062.3347ab03dba02059025032e8d749db5e@localhost> #2442: Heuristics to improve error messages for badly referenced things -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Comment (by batterseapower): I've played with this a bit more and there is a small bug in the part of the patch that suggests qualified alternatives. If you are interested in merging the patch, let me know and I will take the time to fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 13:25:06 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 13:15:37 2008 Subject: [GHC] #2266: validate requires haddock to be installed In-Reply-To: <050.c15637911c8b86321b0fb91e30218ecb@localhost> References: <050.c15637911c8b86321b0fb91e30218ecb@localhost> Message-ID: <059.47bc01ec4d4e33d21980e8df06be5701@localhost> #2266: validate requires haddock to be installed -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We now do tell Cabal where to find haddock, and this means we can fail early if we can't find it. This ticket is therefore fixed by: {{{ Sun Jul 13 17:53:05 BST 2008 Ian Lynagh * If HADDOCK_DOCS is YES, then fail the build early if we couldn't find haddock This fixes trac #2266. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 13:48:43 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 13:39:21 2008 Subject: [GHC] #2265: GHC 6.8 (STABLE) autoconf version requirements issue In-Reply-To: <046.cca200a2c8f3c0dc4698eeb862b6f329@localhost> References: <046.cca200a2c8f3c0dc4698eeb862b6f329@localhost> Message-ID: <055.8aa591c358d2b8bbf323721e373c6fcc@localhost> #2265: GHC 6.8 (STABLE) autoconf version requirements issue --------------------------+------------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: OK, so as far as I can tell from the logs, 2.62 is just complaining more, but behaving the same. The build is failing with readline path problems, but we don't use readline any more, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 15:27:37 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 15:18:09 2008 Subject: [GHC] #2441: Ghc-pkg cannot unregister/expose/hide packages in non-first package databases In-Reply-To: <053.1e7052fd8e6f933efbd3d50f72491d93@localhost> References: <053.1e7052fd8e6f933efbd3d50f72491d93@localhost> Message-ID: <062.ee6387f8d1b78dcdfbc3db41f917a63c@localhost> #2441: Ghc-pkg cannot unregister/expose/hide packages in non-first package databases -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Comment (by duncan): Similarly we notice in #haskell that frequently people are very confused by `ghc-plg list` saying that a package is installed but then unregistering fails (because they do not understand the `--user` issue). This confusion is on the rise because `cabal-install` now does per-user installs by default which means there are more people with per-user packages registered and since they never had to use the `--user` flag in the first place they are unaware of the whole concept of global vs user package dbs.. Either different default behaviour or a better error message would be an improvement. For example at least the error message should note that the package is in the `--user` db and that if they should use that flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 21:01:50 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 20:52:39 2008 Subject: [GHC] #1395: let ./configure check for a GNUreadline framework In-Reply-To: <052.068bc0f583c08a182f51a06ad4864715@localhost> References: <052.068bc0f583c08a182f51a06ad4864715@localhost> Message-ID: <061.500b7fd108777f74346f0b051abd4b45@localhost> #1395: let ./configure check for a GNUreadline framework -----------------------------+---------------------------------------------- Reporter: maeder@tzi.de | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.8 branch Component: Build System | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: MacOS X | -----------------------------+---------------------------------------------- Comment (by add): http://www.cheap-wrought-iron.cn http://www.china-made-door.com.cn -- Ticket URL: GHC The Glasgow Haskell Compiler From david.waern at gmail.com Sun Jul 13 09:46:20 2008 From: david.waern at gmail.com (David Waern) Date: Sun Jul 13 21:21:33 2008 Subject: [GHC] #2436: Bad warning when exporting data families In-Reply-To: <050.f17abced99f071386cf81e533b283f88@localhost> References: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> <050.f17abced99f071386cf81e533b283f88@localhost> Message-ID: 2008/7/13 GHC : > #2436: Bad warning when exporting data families > -------------------------+-------------------------------------------------- > Reporter: rl | Owner: chak > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 6.9 > Severity: normal | Resolution: > Keywords: | Testcase: > Architecture: Unknown | Os: Unknown > -------------------------+-------------------------------------------------- > Changes (by chak): > > * owner: => chak > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > Correct me if I'm wrong, but shouldn't GHC report here that data instances can't be exported? Or can they be exported? When implementing Type Family support in Haddock, I could see no way to export type/data instances using the GHC AST. David From trac at galois.com Sun Jul 13 21:36:55 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 21:27:31 2008 Subject: [GHC] #1434: Slow conversion from Double to Int In-Reply-To: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> References: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> Message-ID: <073.b42f166f277035ed722ce81b53ec280d@localhost> #1434: Slow conversion from Double to Int ---------------------------------------+------------------------------------ Reporter: ghc@henning-thielemann.de | Owner: dons Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: rules | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ---------------------------------------+------------------------------------ Comment (by add): http://www.cheap-wrought-iron.cn http://www.china-made-door.com.cn -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 13 22:24:19 2008 From: trac at galois.com (GHC) Date: Sun Jul 13 22:15:10 2008 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@localhost> References: <046.37416aee19ee095c9a6e98285b215b72@localhost> Message-ID: <055.ba67fc892332db9576a91687b9550b5f@localhost> #915: Implement list fusion using streams instead of foldr/build ----------------------------+----------------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.8 Severity: normal | Resolution: Keywords: fusion | Difficulty: Project (> 1 week) Testcase: N/A | Architecture: Multiple Os: Unknown | ----------------------------+----------------------------------------------- Comment (by add): http://www.cheap-wrought-iron.cn http://www.china-made-door.com.cn -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 05:39:41 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 05:30:13 2008 Subject: [GHC] #2278: Inconsistent behaviour between -odir and -hidir options In-Reply-To: <044.da2157b8bb277561bb6fe2b75576c141@localhost> References: <044.da2157b8bb277561bb6fe2b75576c141@localhost> Message-ID: <053.239b114e83c924818f60c7d14716863c@localhost> #2278: Inconsistent behaviour between -odir and -hidir options ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri Jul 11 14:43:01 BST 2008 Simon Marlow * FIX #2278: don't complain if the -odir directory doesn't exist we'll create it anyway }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 05:40:06 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 05:30:36 2008 Subject: [GHC] #2302: error messages mangle unicode characters In-Reply-To: <044.147efe59df054c7c5210f4aae33a16fd@localhost> References: <044.147efe59df054c7c5210f4aae33a16fd@localhost> Message-ID: <053.7629d58b3362d41cffec8e89cd732d2a@localhost> #2302: error messages mangle unicode characters ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri Jul 11 16:11:16 BST 2008 Simon Marlow * FIX #2302: print FastStrings in UTF-8 in error messages }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 07:11:18 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 07:02:02 2008 Subject: [GHC] #2434: Spurious timer_create() configure test failure. In-Reply-To: <045.b0c92ecf2e46a74462d7e6763a458995@localhost> References: <045.b0c92ecf2e46a74462d7e6763a458995@localhost> Message-ID: <054.5a2bd231a795a70c4ac5cb41a99f5f4e@localhost> #2434: Spurious timer_create() configure test failure. ------------------------------------+--------------------------------------- Reporter: Eelis- | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: timer_create configure | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown Comment: looks like you're right - strangely the test works on my systems here. I'll fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 09:43:15 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 09:33:46 2008 Subject: [GHC] #2441: Ghc-pkg cannot unregister/expose/hide packages in non-first package databases In-Reply-To: <053.1e7052fd8e6f933efbd3d50f72491d93@localhost> References: <053.1e7052fd8e6f933efbd3d50f72491d93@localhost> Message-ID: <062.25d3918b9e6065a21fcb4d98d78fe2c5@localhost> #2441: Ghc-pkg cannot unregister/expose/hide packages in non-first package databases ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 09:56:08 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 09:46:39 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.49dbdee5dfa77c7cc5ec36fd0685a11f@localhost> #1876: Complete shared library support ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * difficulty: Unknown => Difficult (1 week) * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 09:57:49 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 09:48:22 2008 Subject: [GHC] #1547: Arity can decrease with -prof In-Reply-To: <044.c0c86188c91ab503a2f98a561709e8de@localhost> References: <044.c0c86188c91ab503a2f98a561709e8de@localhost> Message-ID: <053.ddf670f7ab154acc8a256fe554f96f1d@localhost> #1547: Arity can decrease with -prof ---------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Profiling | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: stm package/tests/conc052 | Architecture: Unknown Os: Unknown | ---------------------------------------+------------------------------------ Changes (by simonmar): * priority: high => normal * milestone: 6.10 branch => _|_ Comment: bug isn't manifesting any more, and doesn't seem to be an urgent problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:00:41 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 09:51:16 2008 Subject: [GHC] #1964: GHC.Prim In-Reply-To: <044.9207dad19026729963694adf6b204b9d@localhost> References: <044.9207dad19026729963694adf6b204b9d@localhost> Message-ID: <053.adf64611f85d1b42822f83753e11fa2b@localhost> #1964: GHC.Prim ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:03:23 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 09:53:53 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.ade0a267402f929f253f6c43a3ccc918@localhost> #2002: problems with very large (list) literals ------------------------------------------+--------------------------------- Reporter: Isaac Dupree | Owner: simonmar Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Changes (by simonmar): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:05:02 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 09:55:33 2008 Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of range. In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost> References: <044.2f007075e8a3e652be5aa7c77056c714@localhost> Message-ID: <053.01ce6b2d3b2af2bcf47cdd555727c85a@localhost> #2013: ghci crash on startup: R_X86_64_32S relocation out of range. ---------------------+------------------------------------------------------ Reporter: mboes | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: GHCi | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: reopened => closed * resolution: => duplicate Comment: already open as #2063. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:05:37 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 09:56:06 2008 Subject: [GHC] #2063: Breackage on OpenBSD due to mmap remap In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.70f91238cef519550fac6259a163043a@localhost> #2063: Breackage on OpenBSD due to mmap remap ----------------------------+----------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: OpenBSD | ----------------------------+----------------------------------------------- Changes (by simonmar): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:07:04 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 09:57:39 2008 Subject: [GHC] #2231: ASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv} [tau] In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.434a9f6e82cdfd81312718e826d88ef2@localhost> #2231: ASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv} [tau] -------------------------------------+-------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by simonmar): * priority: high => normal * os: Linux => Multiple * component: Runtime System => Compiler (Type checker) * architecture: x86_64 (amd64) => Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:07:48 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 09:58:31 2008 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.6e8a1263b538a86b8ec738ac43efc9de@localhost> #2262: Build failure of HEAD from 2008-05-04 on OS X 10.4.11 ----------------------+----------------------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonmar): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:09:05 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 09:59:34 2008 Subject: [GHC] #2297: Profiler is inconsistent about biography for GHC's heap In-Reply-To: <044.fbea862bca1709c4fb82e649273727f1@localhost> References: <044.fbea862bca1709c4fb82e649273727f1@localhost> Message-ID: <053.9a777484ffac1ccf8da518aed6885c9b@localhost> #2297: Profiler is inconsistent about biography for GHC's heap -----------------------+---------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Profiling | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------+---------------------------------------------------- Changes (by simonmar): * milestone: 6.10 branch => 6.10.1 Comment: Needed for further profiling of GHC, we should investigate for 6.10.1 if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:11:24 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:02:01 2008 Subject: [GHC] #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails In-Reply-To: <045.009b69f25f0ac7df34c06021735a7f36@localhost> References: <045.009b69f25f0ac7df34c06021735a7f36@localhost> Message-ID: <054.f1b75b7b9ceb06cefa6b6356c78ed5bf@localhost> #2318: building GHC 6.8.3 Release Candidate 6.8.2.20080527 under PC solaris fails --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10 branch Component: Build System | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: Going by the previous comment, it looks like this was not a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:12:07 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:02:39 2008 Subject: [GHC] #2335: Haddock's internal GHC version must match the configured GHC version In-Reply-To: <042.dd7881e9cf460e19411390b51f02530e@localhost> References: <042.dd7881e9cf460e19411390b51f02530e@localhost> Message-ID: <051.9b29f0da492f14c5349d55e2e3e5cafe@localhost> #2335: Haddock's internal GHC version must match the configured GHC version --------------------------+------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Build System | Version: 6.8.2 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------------+------------------------------------------------- Changes (by simonmar): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:13:14 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:03:45 2008 Subject: [GHC] #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 In-Reply-To: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> References: <045.7c5ad0836c0444e2655d0f93786db19e@localhost> Message-ID: <054.5e05671f0f5e642a919af51cceeab147@localhost> #2342: timer problem under Sparc Solaris for Release Candidate ghc-6.8.2.20080603 --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Build System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by simonmar): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:14:54 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:05:24 2008 Subject: [GHC] #2444: gtk2hs 0.9.13 fails to build on ppc due to bad code generated with -fvia-C Message-ID: <042.86c4267360832e863379a2145bf9d85a@localhost> #2444: gtk2hs 0.9.13 fails to build on ppc due to bad code generated with -fvia-C ------------------------+--------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: powerpc | Os: Linux ------------------------+--------------------------------------------------- SimonM auggests that this might be a mangler bug. The upstream gtk2hs bug is http://hackage.haskell.org/trac/gtk2hs/ticket/1132 For a build log exposing the error, see about 100 lines from the end of http://koji.fedoraproject.org/koji/getfile?taskID=714114&name=build.log -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:15:22 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:05:51 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.c85684c1177a058d8a28a35c2b0b1648@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: high => normal Comment: Not essential for 6.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:20:21 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:10:50 2008 Subject: [GHC] #1348: inconsistent 'ghc --help" message In-Reply-To: <044.40c02a1b9d8104e641ba174ea3f5e40e@localhost> References: <044.40c02a1b9d8104e641ba174ea3f5e40e@localhost> Message-ID: <053.ac5b0cffb3ee84000fb7beeee49eecb6@localhost> #1348: inconsistent 'ghc --help" message ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * priority: high => normal Comment: dependent on #1880, which has normal prio, so dropping this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:22:19 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:12:49 2008 Subject: [GHC] #1048: Add forkIO that starts in 'block' mode In-Reply-To: <053.3d943aa074476096db4463def1398273@localhost> References: <053.3d943aa074476096db4463def1398273@localhost> Message-ID: <062.027fbd48e099156a63142f86159f82fc@localhost> #1048: Add forkIO that starts in 'block' mode -----------------------------+---------------------------------------------- Reporter: ChrisKuklewicz | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6 Severity: normal | Resolution: fixed Keywords: concurrency | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Finished: {{{ Wed Jul 9 06:55:58 PDT 2008 Simon Marlow * forkOS: start the new thread in blocked mode iff the parent was (#1048) This matches the behaviour of forkIO }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:23:05 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:13:33 2008 Subject: [GHC] #2426: ghc-pkg should treat package.conf as UTF8 In-Reply-To: <044.52bda3c925309f2ed287ef35b894919b@localhost> References: <044.52bda3c925309f2ed287ef35b894919b@localhost> Message-ID: <053.6a0bbf6b7f92c6195e5c8ab6e06eca71@localhost> #2426: ghc-pkg should treat package.conf as UTF8 ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * difficulty: Unknown => Easy (1 hr) * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:23:48 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:14:17 2008 Subject: [GHC] #2322: cmath library broken with -fvia-C In-Reply-To: <047.4f5ed74e9c0974e832a64d783dd3e20d@localhost> References: <047.4f5ed74e9c0974e832a64d783dd3e20d@localhost> Message-ID: <056.d4fc6e63fccfa3fb8a8b593f341c892a@localhost> #2322: cmath library broken with -fvia-C ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri Jul 11 08:27:03 PDT 2008 Simon Marlow * FIX #2322: add exceptions for more functions in math.h }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:31:50 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:22:23 2008 Subject: [GHC] #366: incomplete patterns and GADT In-Reply-To: <045.78fabe56a37c24d921b345c081d108ef@localhost> References: <045.78fabe56a37c24d921b345c081d108ef@localhost> Message-ID: <054.93e80a6a233d4b55d7d5f67cb9c2ed3c@localhost> #366: incomplete patterns and GADT -----------------------------+---------------------------------------------- Reporter: nobody | Owner: nobody Type: feature request | Status: assigned Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Unknown Testcase: tc215 | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * component: None => Compiler * milestone: 6.10 branch => _|_ Comment: Could be done with #595. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:33:10 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:23:38 2008 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@localhost> References: <047.bea78f01cbb904765ad77c751bc8d3af@localhost> Message-ID: <056.dcb6bf58587008eeec30404afdedc8c6@localhost> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: normal | Resolution: None Keywords: warnings | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): And #366. Someone could fix this and bag 8 tickets in one go :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:37:48 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:28:20 2008 Subject: [GHC] #631: GHCi doesn't work unregisterised In-Reply-To: <058.77987f0da5513fbc618ea4c0e4ce6de9@localhost> References: <058.77987f0da5513fbc618ea4c0e4ce6de9@localhost> Message-ID: <067.df901f9b1c5221bf4cb3f385f75b37d7@localhost> #631: GHCi doesn't work unregisterised ---------------------------------+------------------------------------------ Reporter: trentbuck@gmail.com | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.4.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:38:59 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:29:27 2008 Subject: [GHC] #1924: Rewrite the handling of values we get from ./configure In-Reply-To: <044.9ce32a75cdc46063892169755ff2cb07@localhost> References: <044.9ce32a75cdc46063892169755ff2cb07@localhost> Message-ID: <053.64a8b9c1fcdbde61edf16ff13405e4cc@localhost> #1924: Rewrite the handling of values we get from ./configure --------------------------+------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Build System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:40:05 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:30:33 2008 Subject: [GHC] #654: Cabalization of the GHC library. In-Reply-To: <045.dc10624aae03913b743ddf1bf7e81e4c@localhost> References: <045.dc10624aae03913b743ddf1bf7e81e4c@localhost> Message-ID: <054.dc39102c55868987ed45291c32cac99b@localhost> #654: Cabalization of the GHC library. -----------------------------+---------------------------------------------- Reporter: Lemmih | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:41:08 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:31:37 2008 Subject: [GHC] #657: add WARNING pragma In-Reply-To: <045.8c73cf4e3bcf8e038b01b87ef7c68682@localhost> References: <045.8c73cf4e3bcf8e038b01b87ef7c68682@localhost> Message-ID: <054.9275f314f22fc2e147d25fd70886f856@localhost> #657: add WARNING pragma ----------------------+----------------------------------------------------- Reporter: ijones | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: N/A | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:44:41 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:35:23 2008 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@localhost> References: <046.37416aee19ee095c9a6e98285b215b72@localhost> Message-ID: <055.47a36fb0bac4eac46ac677fc674fac1b@localhost> #915: Implement list fusion using streams instead of foldr/build ----------------------------+----------------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8 Severity: normal | Resolution: Keywords: fusion | Difficulty: Project (> 1 week) Testcase: N/A | Architecture: Multiple Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:48:39 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:39:14 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.41f31de8b99d6bb9447b15e3e251de72@localhost> #2157: Equality Constraints with Type Families -------------------------------------+-------------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: I fixed the checking of rhss of type family instances. Otherwise, I don't think there is anything that we can do about this; hence, I close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:51:04 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:41:38 2008 Subject: [GHC] #1232: generalise runhaskell to support arbitrary file names, not just those with .{l}hs extensions In-Reply-To: <047.cac0ff6b1474594ce3579cffcdfc1b73@localhost> References: <047.cac0ff6b1474594ce3579cffcdfc1b73@localhost> Message-ID: <056.d8903f8df5524555af75cbcf56b56d07@localhost> #1232: generalise runhaskell to support arbitrary file names, not just those with .{l}hs extensions -----------------------------+---------------------------------------------- Reporter: Frederik | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: runhaskell | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:52:01 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:42:29 2008 Subject: [GHC] #2444: gtk2hs 0.9.13 fails to build on ppc due to bad code generated with -fvia-C In-Reply-To: <042.86c4267360832e863379a2145bf9d85a@localhost> References: <042.86c4267360832e863379a2145bf9d85a@localhost> Message-ID: <051.60d1b2d9409e50f6ca0ce855c1761e72@localhost> #2444: gtk2hs 0.9.13 fails to build on ppc due to bad code generated with -fvia-C -------------------------+-------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: powerpc | Os: Linux -------------------------+-------------------------------------------------- Comment (by bos): Removing -fvia-C from the compiler options fixes the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:52:17 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:42:49 2008 Subject: [GHC] #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH In-Reply-To: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> References: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> Message-ID: <060.8b6a5cd8c9359d9056ce4be1e26d838d@localhost> #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- Comment (by igloo): Fix at the same time as #1232 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:52:20 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:42:52 2008 Subject: [GHC] #1232: generalise runhaskell to support arbitrary file names, not just those with .{l}hs extensions In-Reply-To: <047.cac0ff6b1474594ce3579cffcdfc1b73@localhost> References: <047.cac0ff6b1474594ce3579cffcdfc1b73@localhost> Message-ID: <056.6137bd36edae1fa646bd4f1453430f95@localhost> #1232: generalise runhaskell to support arbitrary file names, not just those with .{l}hs extensions -----------------------------+---------------------------------------------- Reporter: Frederik | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: runhaskell | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Unknown | -----------------------------+---------------------------------------------- Comment (by igloo): Fix at the same time as #1281 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:54:02 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:44:42 2008 Subject: [GHC] #838: GHC binary for FreeBSD/amd64 In-Reply-To: <044.99d7d73649e2c40163a15f6117571bf0@localhost> References: <044.99d7d73649e2c40163a15f6117571bf0@localhost> Message-ID: <053.6c53050ad26c12dd2721bafc7bc56632@localhost> #838: GHC binary for FreeBSD/amd64 -----------------------------+---------------------------------------------- Reporter: alter | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: x86_64 (amd64) Os: FreeBSD | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: There now exists a FreeBSD port that works on x86_64, so closing this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 10:54:39 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:45:07 2008 Subject: [GHC] #1248: Use sensible flags for ghc -M In-Reply-To: <046.7dbf2ab1bf1975707055f3f2e91a0e84@localhost> References: <046.7dbf2ab1bf1975707055f3f2e91a0e84@localhost> Message-ID: <055.48260e85175c70465e121fd3a006ab6d@localhost> #1248: Use sensible flags for ghc -M ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => 6.10.1 Comment: I'm not sure if doing #1880 first is important, but it would be good to do this for 6.10.1 so that we can rely on the new flags existing sooner. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 11:06:43 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 10:57:14 2008 Subject: [GHC] #1032: Test.QuickCheck.Batch overflow in length of tests In-Reply-To: <058.9904bd8ceee29cc789e92d82cdc7a6d3@localhost> References: <058.9904bd8ceee29cc789e92d82cdc7a6d3@localhost> Message-ID: <067.d1c6e12b2c03c7f9633d85ac7c7cbd3c@localhost> #1032: Test.QuickCheck.Batch overflow in length of tests ---------------------------------+------------------------------------------ Reporter: gwright@antiope.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: Compiler | Version: 6.6 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: Please see http://www.haskell.org/haskellwiki/Library_submissions if you would like to propose an alternate interface. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 11:14:35 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 11:05:04 2008 Subject: [GHC] #1248: Use sensible flags for ghc -M In-Reply-To: <046.7dbf2ab1bf1975707055f3f2e91a0e84@localhost> References: <046.7dbf2ab1bf1975707055f3f2e91a0e84@localhost> Message-ID: <055.7b7345cf184ee86f4ebbf2c1b33d7069@localhost> #1248: Use sensible flags for ghc -M ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 11:19:54 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 11:10:26 2008 Subject: [GHC] #1389: readline checks in configure.ac can probably be removed In-Reply-To: <047.d6f3a7067b92adffac648351296fa875@localhost> References: <047.d6f3a7067b92adffac648351296fa875@localhost> Message-ID: <056.60c874b297e421104c4399a494d2373a@localhost> #1389: readline checks in configure.ac can probably be removed --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 11:27:24 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 11:17:52 2008 Subject: [GHC] #2365: Warn about suspicious flags in OPTIONS_GHC pragmas In-Reply-To: <044.945add75703117abb32003d74d697760@localhost> References: <044.945add75703117abb32003d74d697760@localhost> Message-ID: <053.684477f6cd049da5dd831e2dbf82acf0@localhost> #2365: Warn about suspicious flags in OPTIONS_GHC pragmas -----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by igloo): For -package, see also #1407 and http://hackage.haskell.org/trac/ghc/wiki/GhcPackages -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 11:27:35 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 11:18:03 2008 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@localhost> References: <044.ced6846230ff2e238418885a3d68ddd9@localhost> Message-ID: <053.2a1b348542e77b7ce124a64220b3bd85@localhost> #1407: Add the ability to :set -l{foo} in .ghci files -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by igloo): See also #2365 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 11:35:36 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 11:26:04 2008 Subject: [GHC] #1499: Visual Haskell installer issue(s) In-Reply-To: <047.21727f65cd03c38e3110e5bb514abdd8@localhost> References: <047.21727f65cd03c38e3110e5bb514abdd8@localhost> Message-ID: <056.106a91532c98b97ecc12d533edc8a176@localhost> #1499: Visual Haskell installer issue(s) ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: Visual Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * milestone: 6.10 branch => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 11:37:13 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 11:27:40 2008 Subject: [GHC] #1444: Template Haskell: add proper support for qualified names in non-splicing applications In-Reply-To: <043.13bd5bcef9b2285ee8443a489f6d7487@localhost> References: <043.13bd5bcef9b2285ee8443a489f6d7487@localhost> Message-ID: <052.255cf0374f20f133438688e64511158a@localhost> #1444: Template Haskell: add proper support for qualified names in non-splicing applications ------------------------------+--------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 11:43:02 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 11:33:30 2008 Subject: [GHC] #1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs In-Reply-To: <044.a916af5b8c38ab63a7239d33e71dfb3b@localhost> References: <044.a916af5b8c38ab63a7239d33e71dfb3b@localhost> Message-ID: <053.d1f3703264aafb97ba9e0bacbfc08b0c@localhost> #1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs ---------------------+------------------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: hsc2hs | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * milestone: 6.10 branch => 6.10.1 Comment: We're now using Cabal to build hsc2hs, so we're part-way there. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 11:54:08 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 11:44:39 2008 Subject: [GHC] #1502: GHC should integrate better with mingw In-Reply-To: <047.b7395f3fc65ee001157bf44a9570b106@localhost> References: <047.b7395f3fc65ee001157bf44a9570b106@localhost> Message-ID: <056.46e082b9cf74aa560745f45e455ee81c@localhost> #1502: GHC should integrate better with mingw -----------------------------+---------------------------------------------- Reporter: eivuokko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: windows | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 11:56:52 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 11:47:21 2008 Subject: [GHC] #1534: [Debugger] Watch on accesses of "variables" In-Reply-To: <056.e37fa8ac72efebdb5745a46382bc4ddd@localhost> References: <056.e37fa8ac72efebdb5745a46382bc4ddd@localhost> Message-ID: <065.3fbb6bb2b5736a073bdd20c366705fdc@localhost> #1534: [Debugger] Watch on accesses of "variables" -------------------------------+-------------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 12:11:52 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 12:02:21 2008 Subject: [GHC] #1574: Broken link testing In-Reply-To: <056.4175938f47088948409e38405f44cd8f@localhost> References: <056.4175938f47088948409e38405f44cd8f@localhost> Message-ID: <065.70a27a2392d4e463d87d7de672c42fbf@localhost> #1574: Broken link testing -------------------------------+-------------------------------------------- Reporter: iampure@gmail.com | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Documentation | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: 6.10 branch => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 12:31:32 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 12:22:01 2008 Subject: [GHC] #2445: better error message needed for missing package files Message-ID: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> #2445: better error message needed for missing package files ------------------------+--------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Here's a real user's confusion: {{{ ~ $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :module Network Could not find module `Network': Use -v to see a list of the files searched for. Prelude> Leaving GHCi. ~ $ ghc-pkg list network /usr/lib/ghc-6.8.2/package.conf: network-2.1.0.0 /home/sjm/.ghc/i386-linux-6.8.2/package.conf: network-2.2.0.0 }}} Turns out the problem is that the `network-2.2.0.0` package that is registered locally is messed up, the .hi files are missing, probably accidentally deleted. In this situation the error message is not very helpful. The current error message makes sense in the context of local files since there is is quite reasonable for them to not exist however it's no good at all for the case of a module from a package. We know that the package exports that module so the file had better exist and if it does not, it's not simply a case of a missing file, the package is totally borked. The user needs to know that the package is borked so that they can unregister or reinstall it. The current message does not alert them to the real problem. The message should say which package (including version) claims to provide the module and that files are missing from the installed package and as such the package is unusably broken and should be reinstalled. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 19:36:39 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 19:27:06 2008 Subject: [GHC] #1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs In-Reply-To: <044.a916af5b8c38ab63a7239d33e71dfb3b@localhost> References: <044.a916af5b8c38ab63a7239d33e71dfb3b@localhost> Message-ID: <053.ad8483b7644c6156f4668b794d14eef2@localhost> #1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs ---------------------+------------------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: hsc2hs | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Comment (by duncan): This also depends on changes in Cabal: http://hackage.haskell.org/trac/hackage/ticket/296 I don't know for sure but I suspect that the major difference between ghc's hsc2hs and the mainline one is that ghc's fork uses ghc as cc rather than gcc. So if Cabal is adapted to tell hsc2hs to use gcc then that's probably most of the work done. It's not totally trivial since Cabal will have to lookup the right cc options to pass to gcc, that ghc normally uses when we pass -package options etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 14 20:18:45 2008 From: trac at galois.com (GHC) Date: Mon Jul 14 20:09:15 2008 Subject: [GHC] #2250: unpackFamily on Windows fails match In-Reply-To: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> References: <044.9136a0e7b8ebc803db4744ef0ab955c3@localhost> Message-ID: <053.832ec1d2c0e6b8e770c69970801ff649@localhost> #2250: unpackFamily on Windows fails match -------------------------------+-------------------------------------------- Reporter: larsv | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Windows | -------------------------------+-------------------------------------------- Changes (by RafaelGCPP): * architecture: x86 => Multiple * summary: unpackFamily on Windows 2008 fails match => unpackFamily on Windows fails match Comment: I can reproduce the exact bug on the following combinations: - GHC 6.8.2, x86, Windows XP - GHC 6.8.3, x86, Windows XP - GHC 6.8.2, x86, Windows Vista - GHC 6.8.3, x86, Windows Vista - GHC 6.8.2, x64, Windows Vista - GHC 6.8.3, x64, Windows Vista -- Ticket URL: GHC The Glasgow Haskell Compiler From chak at cse.unsw.edu.au Mon Jul 14 23:57:22 2008 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Mon Jul 14 23:47:51 2008 Subject: [GHC] #2436: Bad warning when exporting data families In-Reply-To: References: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> <050.f17abced99f071386cf81e533b283f88@localhost> Message-ID: David Waern: > 2008/7/13 GHC : >> #2436: Bad warning when exporting data families >> ------------------------- >> +-------------------------------------------------- >> Reporter: rl | Owner: chak >> Type: bug | Status: new >> Priority: normal | Milestone: >> Component: Compiler | Version: 6.9 >> Severity: normal | Resolution: >> Keywords: | Testcase: >> Architecture: Unknown | Os: Unknown >> ------------------------- >> +-------------------------------------------------- >> Changes (by chak): >> >> * owner: => chak >> >> -- >> Ticket URL: > > >> > Correct me if I'm wrong, but shouldn't GHC report here that data > instances can't be exported? Or can they be exported? When > implementing Type Family support in Haddock, I could see no way to > export type/data instances using the GHC AST. They cannot be explicitly exported - they are really like class instances wrt to import/export. However, you *can* export the data constructors introduced by a data instances (just like you can export the data constructors of vanilla algebraic data types). That's what rl is doing here. He is exporting the data constructor, not the instances (which is implicitly exported anyway). Manuel From trac at galois.com Tue Jul 15 01:28:54 2008 From: trac at galois.com (GHC) Date: Tue Jul 15 01:19:26 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.67a9c5cbfce7bda65423aca480709785@localhost> #2157: Equality Constraints with Type Families -------------------------------------+-------------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2157 | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by chak): * testcase: => T2157 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 15 01:30:29 2008 From: trac at galois.com (GHC) Date: Tue Jul 15 01:21:03 2008 Subject: [GHC] #2203: TFs in class instances heads In-Reply-To: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> References: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> Message-ID: <052.bb6ea77ba3292049ddd33c37036dba04@localhost> #2203: TFs in class instances heads -------------------------------------+-------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T2203a | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by chak): * testcase: => T2203a Comment: I fixed the first half of ticket (ie, disallow family synonym applications in instance heads). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 15 02:32:37 2008 From: trac at galois.com (GHC) Date: Tue Jul 15 02:23:07 2008 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.142ed8b5d81e15ee3b5a039eb98dab6d@localhost> #1968: data family + GADT: not implemented yet ------------------------------------------------+--------------------------- Reporter: Remi | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: GADT13 | Architecture: Multiple Os: Multiple | ------------------------------------------------+--------------------------- Changes (by chak): * testcase: => GADT13 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 15 02:46:50 2008 From: trac at galois.com (GHC) Date: Tue Jul 15 02:37:20 2008 Subject: [GHC] #2203: TFs in class instances heads In-Reply-To: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> References: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> Message-ID: <052.ff09aebfa60efec977347cda9c8b869a@localhost> #2203: TFs in class instances heads -------------------------------------+-------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T2203a | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Comment (by claus): Replying to [comment:3 chak]: > I fixed the first half of ticket (ie, disallow family synonym applications in instance heads). This is an interesting case, considering this type family application desugaring: {{{ type family F a forall a . .. F a .. === forall a . F a ~ b => .. fa .. }}} At first glance, your fix seems to deny this equivalence (right hand side valid, left hand side invalid) but on further consideration, that isn't actually the case. The missing piece is the location of the constraint resulting from the desugaring. {{{ type family F a instance Context => Class a (F a) -- 1 }}} should desugar to {{{ type family F a instance Context => Class a (F a~fa => fa) -- 2 }}} but there is no valid place to put that constraint in the instance head, so ruling out the sugared form (1) makes sense. Moreover, {{{ type family F a instance (Context,F a~fa) => Class a fa -- 3 }}} is not a desugaring of (1): (1), if it were valid, would restrict instance selection (other instance heads might match), whereas (3) restricts instance validity (this instance head always matches, but its context might not be satisfiable). (just a note to self, and other interested parties who might find this ticket resolution confusing at first) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 15 04:36:07 2008 From: trac at galois.com (GHC) Date: Tue Jul 15 04:26:45 2008 Subject: [GHC] #2434: Spurious timer_create() configure test failure. In-Reply-To: <045.b0c92ecf2e46a74462d7e6763a458995@localhost> References: <045.b0c92ecf2e46a74462d7e6763a458995@localhost> Message-ID: <054.046af7d38e72499c5037a3d190e414a8@localhost> #2434: Spurious timer_create() configure test failure. ------------------------------------+--------------------------------------- Reporter: Eelis- | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: timer_create configure | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | ------------------------------------+--------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed, thanks: {{{ Mon Jul 14 04:10:07 PDT 2008 Simon Marlow * fix #2434: we weren't waiting long enough for the signal }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 15 06:03:27 2008 From: trac at galois.com (GHC) Date: Tue Jul 15 05:53:53 2008 Subject: [GHC] #2442: Heuristics to improve error messages for badly referenced things In-Reply-To: <053.d96b74737451be892238b37815ca44b6@localhost> References: <053.d96b74737451be892238b37815ca44b6@localhost> Message-ID: <062.928a750e295f136151a13a0148da2f4c@localhost> #2442: Heuristics to improve error messages for badly referenced things ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Looks splendid. I'd like to review the patch when I get back from holiday, but in principle thumbs-up from me. Thank you! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 15 07:45:06 2008 From: trac at galois.com (GHC) Date: Tue Jul 15 07:35:32 2008 Subject: [GHC] #2442: Heuristics to improve error messages for badly referenced things In-Reply-To: <053.d96b74737451be892238b37815ca44b6@localhost> References: <053.d96b74737451be892238b37815ca44b6@localhost> Message-ID: <062.59b2ac2b367a84c1db61aebd601098a4@localhost> #2442: Heuristics to improve error messages for badly referenced things ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by batterseapower): Great! For posterity, the accompanying thread on Haskell-Cafe is at http://www.haskell.org/pipermail/haskell-cafe/2008-July/045175.html That thread also discusses what would be a cool improvement: searching all installed packages for the unbound name. However, that would require an actual index and as such is a bit of a heavier-weight solution. As a practical matter, I've been developing GHC using a stage1 compiler with this patch compiled into it and there is a noticable delay when displaying unbound name error messages if there are many things in scope. This is because I have made no attempt to optimize the code yet, and this needs to be resolved. Notes for me, when I get time to look at it: * Cache global reader environment elements between unbound name error messages (I'm guessing eltsUniqFM is fairly expensive) * Revert to the Levenshtein distance (http://en.wikipedia.org/wiki/Levenshtein_distance) rather than one that attempts to account for transpositions too, as the associated algorithm is considerably simpler. Unbox it to the hilt * Possibly adapt the distance metric so it operates in conjunction with a threshold distance it should bail out after -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 15 08:59:16 2008 From: trac at galois.com (GHC) Date: Tue Jul 15 08:49:45 2008 Subject: [GHC] #1417: Add pseudoterminal support to the unix package In-Reply-To: <057.da33875de43e810fe55f4c7d0f97ea47@localhost> References: <057.da33875de43e810fe55f4c7d0f97ea47@localhost> Message-ID: <066.7baf6b0476746e3165ea7ed953a5bcb0@localhost> #1417: Add pseudoterminal support to the unix package --------------------------------+------------------------------------------- Reporter: bos@serpentine.com | Owner: Type: proposal | Status: reopened Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Changes (by bos): * status: closed => reopened * resolution: wontfix => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 15 08:59:44 2008 From: trac at galois.com (GHC) Date: Tue Jul 15 08:50:10 2008 Subject: [GHC] #1417: Add pseudoterminal support to the unix package In-Reply-To: <057.da33875de43e810fe55f4c7d0f97ea47@localhost> References: <057.da33875de43e810fe55f4c7d0f97ea47@localhost> Message-ID: <066.aab8b237daa6ae9b905bed9ad1bb56da@localhost> #1417: Add pseudoterminal support to the unix package --------------------------------+------------------------------------------- Reporter: bos@serpentine.com | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Changes (by bos): * status: reopened => closed * resolution: => fixed Comment: This was actually shipped in, I think, 6.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From david.waern at gmail.com Tue Jul 15 12:15:05 2008 From: david.waern at gmail.com (David Waern) Date: Tue Jul 15 12:05:34 2008 Subject: [GHC] #2436: Bad warning when exporting data families In-Reply-To: References: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> <050.f17abced99f071386cf81e533b283f88@localhost> Message-ID: 2008/7/15 Manuel M T Chakravarty : > They cannot be explicitly exported - they are really like class instances > wrt to import/export. > > However, you *can* export the data constructors introduced by a data > instances (just like you can export the data constructors of vanilla > algebraic data types). That's what rl is doing here. He is exporting the > data constructor, not the instances (which is implicitly exported anyway). Ah, I see. So if you have multiple instances, the union of all their data constructors will be exported? What happens in the case of associated types? Are their data constructors always exported, or can they also be exported explicitly somehow? David From david.waern at gmail.com Tue Jul 15 12:22:31 2008 From: david.waern at gmail.com (David Waern) Date: Tue Jul 15 12:12:56 2008 Subject: [GHC] #2436: Bad warning when exporting data families In-Reply-To: References: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> <050.f17abced99f071386cf81e533b283f88@localhost> Message-ID: 2008/7/15 David Waern : > 2008/7/15 Manuel M T Chakravarty : >> They cannot be explicitly exported - they are really like class instances >> wrt to import/export. >> >> However, you *can* export the data constructors introduced by a data >> instances (just like you can export the data constructors of vanilla >> algebraic data types). That's what rl is doing here. He is exporting the >> data constructor, not the instances (which is implicitly exported anyway). > > Ah, I see. So if you have multiple instances, the union of all their > data constructors will be exported? What happens in the case of > associated types? Are their data constructors always exported, or can > they also be exported explicitly somehow? Sorry for bothering you, I just realized all of this is explained on the wiki page. David From trac at galois.com Wed Jul 16 02:13:36 2008 From: trac at galois.com (GHC) Date: Wed Jul 16 02:04:08 2008 Subject: [GHC] #2446: Network.Socket.PortNum should not be exported Message-ID: <042.b2277c9aa83a0038145519302cc81ee4@localhost> #2446: Network.Socket.PortNum should not be exported -------------------------+-------------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Network.Socket exports a PortNum value constructor. Though there's no haddock documentation to say so, this constructs a value of type PortNumber by taking a Word16 in *machine* order, i.e., byte-swapped on little-endian machines. However, PortNumber is an instance of Num and has a fromIntegral (that converts from a non-byte-swapped int), so when specifying a PortNumber for a something such as a SockAddrInet, one should just use an Integral. That is, instead of SockAddrInet (PortNum $ fromIntegral (byteswap 12345)) hostaddr one should just use SockAddrInet 12345 hostaddr I think that the PortNum constructor should not be exported; it's difficult to use due to the lack of documentation (and its own nature, really), is not necessary, and worst of all, its existence has mislead at least two programmers I know of to use it when they didn't want or need to. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 16 09:58:27 2008 From: trac at galois.com (GHC) Date: Wed Jul 16 09:48:52 2008 Subject: [GHC] #1842: runInteractiveCommand should install SIGCHLD handler In-Reply-To: <046.adac5e06980fc4eb8a64d21d0ef765a1@localhost> References: <046.adac5e06980fc4eb8a64d21d0ef765a1@localhost> Message-ID: <055.df9c008ae7abce8637f32b369a47c3b8@localhost> #1842: runInteractiveCommand should install SIGCHLD handler -------------------------------------+-------------------------------------- Reporter: firefly | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/process | Version: 6.8.1 Severity: normal | Resolution: Keywords: fork(), wait(), SIGCHLD | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -------------------------------------+-------------------------------------- Comment (by simonmar): This is in fact a duplicate of #1619 (programs exiting silently due to SIGPIPE). The 141 exit code is SIGPIPE, not SIGCHLD. SIGCHLD is ignored by default and won't cause a problem. We do intend to make System.Process install a SIGCHLD handler, but for different reasons: it's more efficient than having one OS thread per waiting process, it allows `waitForProcess` to be interruptible, and it will avoid the need for `-threaded`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 16 10:03:28 2008 From: trac at galois.com (GHC) Date: Wed Jul 16 09:53:51 2008 Subject: [GHC] #1842: runInteractiveCommand should install SIGCHLD handler In-Reply-To: <046.adac5e06980fc4eb8a64d21d0ef765a1@localhost> References: <046.adac5e06980fc4eb8a64d21d0ef765a1@localhost> Message-ID: <055.62145ef829d7b2847ebfd37f8503c09f@localhost> #1842: runInteractiveCommand should install SIGCHLD handler -------------------------------------+-------------------------------------- Reporter: firefly | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: libraries/process | Version: 6.8.1 Severity: normal | Resolution: duplicate Keywords: fork(), wait(), SIGCHLD | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -------------------------------------+-------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: #2123 is the ticket for using signals to implement `waitForProcess`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 16 13:56:42 2008 From: trac at galois.com (GHC) Date: Wed Jul 16 13:47:11 2008 Subject: [GHC] #2123: implement waitForProcess using signals In-Reply-To: <047.96e17276f11f467a9162fc8e32a52352@localhost> References: <047.96e17276f11f467a9162fc8e32a52352@localhost> Message-ID: <056.e82a7a458a2ba510fffb08fcd82528f6@localhost> #2123: implement waitForProcess using signals -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by duncan): The other advantage is that `ProcessHandle`s become safe to discard/forget without ending up with defunct zombie processes under Unix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 16 21:29:44 2008 From: trac at galois.com (GHC) Date: Wed Jul 16 21:20:10 2008 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> Message-ID: <052.4be296c2ae0c5dbc343f8a837e84e10e@localhost> #2289: Needless reboxing of values when returning from a tight loop ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: boxing, loops, performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------------+----------------------------------- Comment (by dons): Another case we'd like genralised CPR to work is for sum types. Consider the task of summing integers from a file, one per line. We need to parse each line, returning possibly success, in a tight loop: {{{ import qualified Data.ByteString.Char8 as S main = print . go 0 =<< S.getContents where go !n s = case S.readInt s of S.Nothing -> n S.Just (k,t) -> go (n+k) (S.tail t) }}} Where {{{ readInt :: ByteString -> Maybe (Int, ByteString) }}} We'd like the Just/Nothing tag returned in a register, in an ideal world. And the components of the pair as well. Currently we have to monomorphise the type, and flatten it , to get register returns here. Note that Clean uses a triple of (Bool, Int, String) for this kind of thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 17 01:05:16 2008 From: trac at galois.com (GHC) Date: Thu Jul 17 00:55:36 2008 Subject: [GHC] #2447: Typo in Data.Set.split documentation Message-ID: <050.2e85ce4cae0d663cffd4de37104f1b83@localhost> #2447: Typo in Data.Set.split documentation ----------------------------+----------------------------------------------- Reporter: jeffwheeler | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------+----------------------------------------------- The documentation for Data.Set.split contains an awkward double-negative: ". . . is not found in neither set1 or set2." It should be ". . . is found in neither set1 nor set2." {{{ -- | /O(log n)/. The expression (@'split' x set@) is a pair @(set1,set2)@ -- where all elements in @set1@ are lower than @x@ and all elements in -- @set2@ larger than @x@. @x@ is not found in neither @set1@ nor @set2@. }}} Found here: http://haskell.org/ghc/docs/latest/html/libraries/containers/src/Data- Set.html#split -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 17 02:55:40 2008 From: trac at galois.com (GHC) Date: Thu Jul 17 02:46:01 2008 Subject: [GHC] #2447: Typo in Data.Set.split documentation In-Reply-To: <050.2e85ce4cae0d663cffd4de37104f1b83@localhost> References: <050.2e85ce4cae0d663cffd4de37104f1b83@localhost> Message-ID: <059.5d6156d2e3cb20ee9274cef73dfdcf69@localhost> #2447: Typo in Data.Set.split documentation ------------------------------+--------------------------------------------- Reporter: jeffwheeler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------------+--------------------------------------------- Changes (by ross): * status: new => closed * resolution: => fixed Comment: Reworded as {{{ -- | /O(log n)/. The expression (@'split' x set@) is a pair @(set1,set2)@ -- where @set1@ comprises the elements of @set@ less than @x@ and @set2@ -- comprises the elements of @set@ greater than @x@. }}} patch: tighter description of split (addresses #2447) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 17 05:21:04 2008 From: trac at galois.com (GHC) Date: Thu Jul 17 05:11:31 2008 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> Message-ID: <052.e0587248222a07d88207b3388cc77ce7@localhost> #2289: Needless reboxing of values when returning from a tight loop ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: boxing, loops, performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------------+----------------------------------- Comment (by simonpj): Don't hold your breath for unboxed sum types. For example, if the `Bool` is `True`, the other two fields may be uninitialised, and should not be followed by the GC. I suppose if you were prepared to stubs initialised to `(error "Bad")`, then you could do this worker/wrapper split for `go`: {{{ readInt :: String -> Maybe (Int, String) readInt s = case readInt_w s of (# True, n, s #) -> Nothing (# False, n, s #) -> Just (n,s) readInt_w :: String -> (# Bool, Int, String #) readInt_w s = case of Just (n,s) -> (# False, n, s #) Nothing -> (# True, error "BAD", error "BAD" #) }}} Things get harder if there are more constructors in the sum type, or the constructors have more arguments. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 17 06:49:02 2008 From: trac at galois.com (GHC) Date: Thu Jul 17 06:39:21 2008 Subject: [GHC] #2448: Type equality constraint not propagated to superclass Message-ID: <044.69c727e94da0f0e8a02cdc7148428338@localhost> #2448: Type equality constraint not propagated to superclass ---------------------------------------------------------+------------------ Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: type families, type equality constraints | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------------------------------+------------------ The code: {{{ {-# LANGUAGE TypeFamilies, UndecidableInstances #-} -- Demonstrates a bug in propagating type equality constraints class VectorSpace v where type Scalar v :: * class VectorSpace v => InnerSpace v instance (VectorSpace u,VectorSpace v, Scalar u ~ Scalar v) => VectorSpace (u,v) where type Scalar (u,v) = Scalar u instance (InnerSpace u,InnerSpace v, Scalar u ~ Scalar v) => InnerSpace (u,v) }}} In ghc 6.9.20080622, the last line yields {{{ Data\TypeEqBug.hs:20:0: Couldn't match expected type `Scalar v' against inferred type `Scalar u' When checking the super-classes of an instance declaration In the instance declaration for `InnerSpace (u, v)' }}} I'd expect the type equality constraint in the {{{InnerSpace}}} instance to get propagated to the parent class. By the way, without the {{{UndecidableInstances}}} above, we get: {{{ Constraint is no smaller than the instance head in the constraint: Scalar u ~ Scalar v (Use -XUndecidableInstances to permit this) In the instance declaration for `VectorSpace (u, v)' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 17 08:10:11 2008 From: trac at galois.com (GHC) Date: Thu Jul 17 08:00:30 2008 Subject: [GHC] #2449: panic with GeneralizedNewtypeDeriving and a .hs-boot file Message-ID: <044.e61299c07a3173d5bd1857190eae6cdf@localhost> #2449: panic with GeneralizedNewtypeDeriving and a .hs-boot file -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- With `A.hs-boot`: {{{ module A where data A deriving Show }}} We can get a panic: {{{ $ ghc -c -XGeneralizedNewtypeDeriving A.hs-boot A.hs-boot:5:13:ghc: panic! (the 'impossible' happened) (GHC version 6.9.20080716 for x86_64-unknown-linux): newTyConEtadRhs main:A.A{tc r6K} 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 Jul 17 11:22:53 2008 From: trac at galois.com (GHC) Date: Thu Jul 17 11:13:40 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.a5429c5708b3fc0c5589c81d450a9b20@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by conal): * cc: conal@conal.net (added) Comment: Replying to [comment:1 simonmar]: > However, we could make an exception for C finalizers registered via `Foreign.ForeignPtr`, and give these extra guarantees. This has been requested before, and I think it would be a useful feature. As far as I can tell, running finalizers promptly is ''essential'' to efficient functional graphics programming on modern hardware. For graphics, C-only finalizers (for graphics resource deallocation) would be a perfectly fine restriction to live with. Could we get C finalizers executed promptly? For instance, could they be executed at the end of each GC cycle, rather than thread-enqueued? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 17 11:29:04 2008 From: trac at galois.com (GHC) Date: Thu Jul 17 11:19:28 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.7ed240986fbde4936837fc3a49aa6700@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by simonmar): * milestone: 6.10 branch => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 17 11:58:05 2008 From: trac at galois.com (GHC) Date: Thu Jul 17 11:48:26 2008 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@localhost> References: <045.f06a53427920f75d02000e2372e27573@localhost> Message-ID: <054.904b1d93eb1b59d0e740a7eef2f21a8e@localhost> #2301: Proper handling of SIGINT/SIGQUIT -------------------------------+-------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -------------------------------+-------------------------------------------- Comment (by duncan): So the next part is how we handle `^C` when we are running foreground processes. I think the behaviour suggested in the above description is right but lets try to flesh it out a bit more and suggest how it could be implemented. Some terminology: technically all processes we launch are in the foreground. Putting a process into the background has to be done explicitly. However that does not means that logically we consider all processes to be in the foreground. We often launch processes and do not expect them to communicate with the user via the console or we may connect them via pipes and not let them use the console at all. So we only want to delegate`^C` handling to some processes. Delegating `^C` handling is a property of a process which we set when we launch it. When we get a `^C` there are two cases: * we are running one or more processes to which we consider we are delegating `^C` handling * we are running no such processes The second case is easy and is addressed by the patch above. We throw an exception to the main thread which will typically propagate and terminate the program. In the first case we do not want to throw any exception immediately. However when processes to which we were delegating `^C` handling terminate due to `^C` we should at that point throw an exception to the main thread. So how could we implement this? Delegated `^C` handling becomes another property of a process we launch. We keep a global count of the number of such processes we're running. We use that count to decide if we should throw an exception to the main thread when we receive `SIGINT` or not. We will also need to record in the map of launched processes if we were delegating `^C` handling or not. This means changing from a `Map PID (MVar ExitCode)` to a `Map PID (Bool, MVar ExitCode)`. When the `SIGCHILD` handler runs for a PID it will look it up in the map, if we were delegating ^C handling for that process and it terminated due to `^C` then it should throw an exception to the main thread, exactly as the `^C` handler would do when there were no delegated `^C` processes running. It should also set the `MVar ExitCode` since the main thread may well be ignoring `^C` exceptions and want to continue as normal. So in both cases, `^C` happens as an async exception in the main thread. The difference is whether it happens when the `^C` is first received or when a process to which we are delegating `^C` handling terminates due to `^C`. So the `CreateProcess` record will need an extra field to indicate if we're delegating `^C` handling. That will make it possible to implement the old `system` and `rawSystem` functions in terms of `createProcess`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 18 01:56:37 2008 From: trac at galois.com (GHC) Date: Fri Jul 18 01:47:02 2008 Subject: [GHC] #2448: Type equality constraint not propagated to superclass In-Reply-To: <044.69c727e94da0f0e8a02cdc7148428338@localhost> References: <044.69c727e94da0f0e8a02cdc7148428338@localhost> Message-ID: <053.13291225bbc3d8effd6f3a368f43f300@localhost> #2448: Type equality constraint not propagated to superclass ---------------------------------------------------------+------------------ Reporter: conal | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: type families, type equality constraints | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------------------------------+------------------ Changes (by chak): * owner: => chak * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 18 08:22:03 2008 From: trac at galois.com (GHC) Date: Fri Jul 18 08:12:20 2008 Subject: [GHC] #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow Message-ID: <044.75a109ff49643f020ff0241cedbdd8c4@localhost> #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Data.Complex.magnitude squares using `^(2 :: Int)`, which is slow. Either it should use `sqr x = x * x` or a rule should rewrite `e ^ (2 :: Int)` to do so (or perhaps both; the RULE for general cases, and the manual `sqr` for hugs etc). More detail in this thread: http://www.haskell.org/pipermail/haskell-cafe/2008-July/045327.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 18 08:22:38 2008 From: trac at galois.com (GHC) Date: Fri Jul 18 08:12:54 2008 Subject: [GHC] #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow In-Reply-To: <044.75a109ff49643f020ff0241cedbdd8c4@localhost> References: <044.75a109ff49643f020ff0241cedbdd8c4@localhost> Message-ID: <053.b87215f6c9ae1bd73c1ad9ca6559cb5f@localhost> #2450: Data.Complex.magnitude squares using ^(2 :: Int), which is slow --------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * type: bug => run-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 18 08:52:39 2008 From: trac at galois.com (GHC) Date: Fri Jul 18 08:42:55 2008 Subject: [GHC] #2451: New signal-handling API Message-ID: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> #2451: New signal-handling API -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- The current API for handling signals in `System.Posix` is lacking in a couple of ways: * it isn't modular: there's no way for a library to install a private signal handler, there is only a singla global handler per signal. * it isn't possible to get hold of the information from `siginfo_t` (#592). I want to propose a new API. This has already undergone a round of changes after discussion with Duncan Coutts, and we ended up with something quite simple. Haddock docs are here: [http://darcs.haskell.org/~simonmar/unix/System-Posix-Signals.html#4] (also attached as `unix-html.tar.gz`). I have working patches to implement this. The old API is still available, and is reimplemented using the new API. Signal handlers installed using the old API will coexist with those installed using the new API. The main motivation for this change was so that I could hook the `SIGCHLD` signal in the `System.Process` library without disturbing users of the `System.Posix` library who might also want to install a `SIGCHLD` handler. Deadline: 1 Aug (2 weeks) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 18 10:40:02 2008 From: trac at galois.com (GHC) Date: Fri Jul 18 10:30:23 2008 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@localhost> References: <047.24a366415ff9b59c03e5bf49850898a6@localhost> Message-ID: <056.84e152a664ed9e31a58271f8a4dd0202@localhost> #2233: Overhaul System.Process -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by simonmar): Another round of changes has been posted for comment. Haddock docs in the same location: [http://darcs.haskell.org/~simonmar/process/System- Process.html], and the patch message is as follows: {{{ * More System.Process overhaul New functions: callProcess :: FilePath -> [String] -> IO () callCommand :: String -> IO () spawnProcess :: FilePath -> [String] -> IO ProcessHandle spawnCommand :: String -> IO ProcessHandle Changes: - system and rawSystem have been removed from System.Process again. (they were only there temporarily after the last round of changes, now callCommand and callProcess replace them respectively). On Unix systems we now use SIGCHLD to detect process completion instead of calling waitpid(). This has several advantages: - much cheaper: no extra OS threads to do the waiting - doesn't require -threaded to get non-blocking waitForProcess - waitForProcess can be interrupted - no zombie process left around (only relevant on Unix) However, it relies on the new signal API (see separate proposal). And these advantages aren't available on Windows (yet). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 18 13:55:01 2008 From: trac at galois.com (GHC) Date: Fri Jul 18 13:45:16 2008 Subject: [GHC] #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode Message-ID: <049.31db7471187fa0b39e4d12923cd80edb@localhost> #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode --------------------------------+------------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- In interactive mode every available module is implicitly imported qualified. While this is very convenient when working with GHCi, it can be a little annoying in other contexts. For instance, in a lambdabot-like application, one would like to rely on the type of a given expression to decide if it is side-effect free and, thus, safe to execute. However, because every module in the `base` package is imported qualified one has to do a manual check to filter out cases like: {{{ ghc -e 'System.IO.Unsafe.unsafePerformIO (evilStuff >> return "i'm an innocent string")' }}} Another example would be a GHC-API based refactoring tool that wants to check if a refactored expression typechecks before modifying the code. If every module is imported qualified, the tool might get many false positives. The proposal is to keep the current behaviour as the default but to add a `-fno-implicit-import-qualified` flag to disable it when needed. The following should fail to execute: {{{ ghc -fno-implicit-import-qualified -e 'System.IO.Unsafe.unsafePerformIO (evilStuff >> return "i'm an innocent string")' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 18 15:23:00 2008 From: trac at galois.com (GHC) Date: Fri Jul 18 15:13:21 2008 Subject: [GHC] #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode In-Reply-To: <049.31db7471187fa0b39e4d12923cd80edb@localhost> References: <049.31db7471187fa0b39e4d12923cd80edb@localhost> Message-ID: <058.d52e1666cdaf98a2c29d1dc49751b311@localhost> #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode ----------------------------------------+----------------------------------- Reporter: jcpetruzza | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Changes (by jcpetruzza): * owner: => igloo Comment: Since it looks like a simple enough fix, I've added a patch for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 18 20:01:22 2008 From: trac at galois.com (GHC) Date: Fri Jul 18 19:51:49 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.fb86fe9ce4b485b3e1a0890580116137@localhost> #1876: Complete shared library support ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by batterseapower): * cc: batterseapower+GHC1876@hotmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 18 20:02:53 2008 From: trac at galois.com (GHC) Date: Fri Jul 18 19:53:09 2008 Subject: [GHC] #2335: Haddock's internal GHC version must match the configured GHC version In-Reply-To: <042.dd7881e9cf460e19411390b51f02530e@localhost> References: <042.dd7881e9cf460e19411390b51f02530e@localhost> Message-ID: <051.72932a3e6db2c74b4ec52b3dbaea0317@localhost> #2335: Haddock's internal GHC version must match the configured GHC version --------------------------+------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Build System | Version: 6.8.2 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------------+------------------------------------------------- Changes (by batterseapower): * cc: batterseapower+GHC2335@hotmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 19 10:13:18 2008 From: trac at galois.com (GHC) Date: Sat Jul 19 10:03:31 2008 Subject: [GHC] #654: Cabalization of the GHC library. In-Reply-To: <045.dc10624aae03913b743ddf1bf7e81e4c@localhost> References: <045.dc10624aae03913b743ddf1bf7e81e4c@localhost> Message-ID: <054.210ad7b43b92f5631f0ab44afa79a98c@localhost> #654: Cabalization of the GHC library. -----------------------------+---------------------------------------------- Reporter: Lemmih | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.4.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We now build GHC with Cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 19 10:14:24 2008 From: trac at galois.com (GHC) Date: Sat Jul 19 10:04:37 2008 Subject: [GHC] #1574: Broken link testing In-Reply-To: <056.4175938f47088948409e38405f44cd8f@localhost> References: <056.4175938f47088948409e38405f44cd8f@localhost> Message-ID: <065.8e88f03f12960c012f8e24829379ea9c@localhost> #1574: Broken link testing -------------------------------+-------------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Documentation | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 19 10:19:30 2008 From: trac at galois.com (GHC) Date: Sat Jul 19 10:09:45 2008 Subject: [GHC] #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode In-Reply-To: <049.31db7471187fa0b39e4d12923cd80edb@localhost> References: <049.31db7471187fa0b39e4d12923cd80edb@localhost> Message-ID: <058.7dfac8ef11f584c41ebc0f3e6c804419@localhost> #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode -------------------------------------+-------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * owner: igloo => * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the patch! However, before applying it I'd like to be sure that it is the right thing to do. For lambdabot, I think we really want Safe Haskell (#1380). Should a refactoring tool be using interactive mode if it wants to do that? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 19 10:31:07 2008 From: trac at galois.com (GHC) Date: Sat Jul 19 10:21:21 2008 Subject: [GHC] #2414: GHCi / GHC segfault : type checker problem In-Reply-To: <043.07db70092bd8811bd5934348939d4781@localhost> References: <043.07db70092bd8811bd5934348939d4781@localhost> Message-ID: <052.030575ce6607d9703a4d127fd619aaf8@localhost> #2414: GHCi / GHC segfault : type checker problem -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: merge | Status: new Priority: high | Milestone: 6.8 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2414 | Architecture: Unknown Os: Unknown | -----------------------------------------+---------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 19 10:31:14 2008 From: trac at galois.com (GHC) Date: Sat Jul 19 10:21:29 2008 Subject: [GHC] #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable In-Reply-To: <053.8442170ef9b4829325987986f707598b@localhost> References: <053.8442170ef9b4829325987986f707598b@localhost> Message-ID: <062.1adf7c11fc924d138fc9428ae3032d05@localhost> #2386: Splicing in constructors that are abstract from the point of view of the splice point is unreliable ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Template Haskell | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: th/T2386 | Architecture: x86_64 (amd64) Os: MacOS X | ------------------------------+--------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 19 10:33:56 2008 From: trac at galois.com (GHC) Date: Sat Jul 19 10:24:17 2008 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@localhost> References: <046.37416aee19ee095c9a6e98285b215b72@localhost> Message-ID: <055.bc0a01f73bf0b5cdec3ad76951247c53@localhost> #915: Implement list fusion using streams instead of foldr/build ----------------------------+----------------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8 Severity: normal | Resolution: Keywords: fusion | Difficulty: Project (> 1 week) Testcase: N/A | Architecture: Multiple Os: Unknown | ----------------------------+----------------------------------------------- Comment (by select): [http://www.salewroughtiron.cn http://hackage.haskell.org/trac/ghc/ticket/915] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 19 12:30:24 2008 From: trac at galois.com (GHC) Date: Sat Jul 19 12:20:36 2008 Subject: [GHC] #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode In-Reply-To: <049.31db7471187fa0b39e4d12923cd80edb@localhost> References: <049.31db7471187fa0b39e4d12923cd80edb@localhost> Message-ID: <058.3a42d5ecbf1a8501885166a3beba7031@localhost> #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode -------------------------------------+-------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by Isaac Dupree): * cc: id@isaac.cedarswampstudios.org (added) Comment: FWIW, I'd like this as an option for using interactive mode interactively in the normal way :-), on occasion I want to do that to simplify my bug- fighting or maybe reduce ambiguities -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 19 14:13:07 2008 From: trac at galois.com (GHC) Date: Sat Jul 19 14:03:19 2008 Subject: [GHC] #2453: users_guide/syntax-extns.html # 8.3.3 has obsolete ref to www.cse.ogi.edu/PacSoft/ Message-ID: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> #2453: users_guide/syntax-extns.html # 8.3.3 has obsolete ref to www.cse.ogi.edu/PacSoft/ ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.8.3 | Severity: trivial Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html reads: "The web page: http://www.cse.ogi.edu/PacSoft/projects/rmb/ contains up to date information on recursive monadic bindings. " That web page no longer exists. Please update the link, or remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 04:18:07 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 04:08:23 2008 Subject: [GHC] #2454: Closing handle from runInteractiveProcess causes myserious, uncatchable death. Message-ID: <042.e4e6e52741f4105b24c0e1aa7038eedc@localhost> #2454: Closing handle from runInteractiveProcess causes myserious, uncatchable death. -----------------------+---------------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Multiple -----------------------+---------------------------------------------------- Running the attached program on Windows works, because runInteractiveProcess fails. Under Linux and NetBSD, runIntractiveProcess returns (which it probably shouldn't--wouldn't it be nicer if it checked that it had execute access on what it wanted to exec before it forked?) and then at some point in hClose the program silently dies, though returning an error code to the process that spawned it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 13:05:19 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 12:55:28 2008 Subject: [GHC] #657: add WARNING pragma In-Reply-To: <045.8c73cf4e3bcf8e038b01b87ef7c68682@localhost> References: <045.8c73cf4e3bcf8e038b01b87ef7c68682@localhost> Message-ID: <054.8f4af8c90d69734dad3014fa742d9395@localhost> #657: add WARNING pragma ----------------------+----------------------------------------------------- Reporter: ijones | Owner: igloo Type: task | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.4.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: N/A | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: WARNING pragma added -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 16:14:38 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 16:04:49 2008 Subject: [GHC] #2427: Allow compilation of source from stdin In-Reply-To: <044.abbe9ae8909931700fcc95de3eb51afe@localhost> References: <044.abbe9ae8909931700fcc95de3eb51afe@localhost> Message-ID: <053.ce9f7b5a5e3a0dd132b02e3a5e0c7bfd@localhost> #2427: Allow compilation of source from stdin -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > Hiya. So, as part of how the Hint library (a wrapper around the GHC API > operates), it has to generate a file in /tmp containing module > boilerplate and the supplied code of interesting, and it then evaluates > it*. But for my mueval code (which uses Hint), I'd like to disable file > creation entirely through resource limits, and so it would be much better > for Hint if it could instead just create the string and pipe it right > into GHC. This avoids any file creation (which may not be possible for > any number of reasons besides resource limits, like LiveCDs or read-only > disks). But in my experiments, and those of #haskell, GHC determinedly > blocks any attempt - you can't simply pipe it in with |, you can't use > /dev/stdin, can't use one of the file descriptors, etc. > > So what I would like is to be able to do: > $ echo "import qualified Data.List\nmain = print $ Data.List.intersperse > 'f' "ggggg" > > "fgfgfgfgfgfg" > > (Why can't I use ghc -e? Doesn't do imports of any kind, and if mueval is > to replicate lambdabot's functionality, it needs to be able to import > many libraries qualified.**) > > * It has to do this roundabout hackish thing because alas, the GHC API > seems to allow functions from any module whatsoever to be called as long > as they are named qualified, even if the appropriate module had not been > allowed in. The magnitude of this as a security hole is obvious. > > ** Why qualified? Too many of the basic libraries have name collisions. > Can't remove them, as it'd be silly to have only half the base libraries > or whatever, but can't just blindly import them as you'll get conflicts. New description: Hiya. So, as part of how the Hint library (a wrapper around the GHC API operates), it has to generate a file in /tmp containing module boilerplate and the supplied code of interesting, and it then evaluates it*. But for my mueval code (which uses Hint), I'd like to disable file creation entirely through resource limits, and so it would be much better for Hint if it could instead just create the string and pipe it right into GHC. This avoids any file creation (which may not be possible for any number of reasons besides resource limits, like LiveCDs or read-only disks). But in my experiments, and those of #haskell, GHC determinedly blocks any attempt - you can't simply pipe it in with |, you can't use /dev/stdin, can't use one of the file descriptors, etc. So what I would like is to be able to do: {{{ $ echo "import qualified Data.List\nmain = print $ Data.List.intersperse 'f' "ggggg" "fgfgfgfgfgfg" }}} (Why can't I use ghc -e? Doesn't do imports of any kind, and if mueval is to replicate lambdabot's functionality, it needs to be able to import many libraries qualified.**) * It has to do this roundabout hackish thing because alas, the GHC API seems to allow functions from any module whatsoever to be called as long as they are named qualified, even if the appropriate module had not been allowed in. The magnitude of this as a security hole is obvious. ** Why qualified? Too many of the basic libraries have name collisions. Can't remove them, as it'd be silly to have only half the base libraries or whatever, but can't just blindly import them as you'll get conflicts. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 16:17:40 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 16:07:49 2008 Subject: [GHC] #2428: bad error message for multiple modules in the same file In-Reply-To: <051.032da37103557c880f77cd3249b27a59@localhost> References: <051.032da37103557c880f77cd3249b27a59@localhost> Message-ID: <060.21caccbd6789eb63848fc403191186ff@localhost> #2428: bad error message for multiple modules in the same file --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the suggestion -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 16:22:15 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 16:12:24 2008 Subject: [GHC] #2429: error building full dll name to be loaded in ghci In-Reply-To: <042.4bf17899c73d8aa74b87acbd8588af1e@localhost> References: <042.4bf17899c73d8aa74b87acbd8588af1e@localhost> Message-ID: <051.3a6254064b1ecf2254aed00c17633597@localhost> #2429: error building full dll name to be loaded in ghci ---------------------+------------------------------------------------------ Reporter: jvl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.8.2 Severity: normal | Resolution: Keywords: dll | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 16:24:51 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 16:14:59 2008 Subject: [GHC] #2431: allow empty case analysis In-Reply-To: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> References: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> Message-ID: <057.1e7f865971d97d45214a2909e41c8c5d@localhost> #2431: allow empty case analysis ---------------------------------+------------------------------------------ Reporter: RalfHinze | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: empty case analysis | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch Comment: Perhaps this would be better proposed for Haskell'? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 16:25:30 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 16:15:42 2008 Subject: [GHC] #2432: type family panic: Coercion.splitCoercionKindOf In-Reply-To: <044.419fb1a60288d8516aab35dbc1443539@localhost> References: <044.419fb1a60288d8516aab35dbc1443539@localhost> Message-ID: <053.a4ace09024cddfc75b92f7e1cf1409c8@localhost> #2432: type family panic: Coercion.splitCoercionKindOf -------------------------------------+-------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 16:26:29 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 16:16:36 2008 Subject: [GHC] #2433: standalone deriving Typeable shouldn't need data constructors in scope? In-Reply-To: <044.c3db89885eba9cc62656744d598e567c@localhost> References: <044.c3db89885eba9cc62656744d598e567c@localhost> Message-ID: <053.c82320861796a01fba14680a2ab3f46d@localhost> #2433: standalone deriving Typeable shouldn't need data constructors in scope? ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 16:31:42 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 16:21:54 2008 Subject: [GHC] #2435: Qualified name required when defining type family instance in instance declaration In-Reply-To: <041.497191dfe597e8898c23dfb8fea641e6@localhost> References: <041.497191dfe597e8898c23dfb8fea641e6@localhost> Message-ID: <050.340fded2c37edc85c7116bcb04d7cc7b@localhost> #2435: Qualified name required when defining type family instance in instance declaration ----------------------+----------------------------------------------------- Reporter: rl | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 16:31:54 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 16:22:05 2008 Subject: [GHC] #2436: Bad warning when exporting data families In-Reply-To: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> References: <041.c0e126f9cae0d4eca6685716c24c2990@localhost> Message-ID: <050.dda6f777fd823572df893cdbaeeed812@localhost> #2436: Bad warning when exporting data families ----------------------+----------------------------------------------------- Reporter: rl | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 16:59:00 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 16:49:09 2008 Subject: [GHC] #1248: Use sensible flags for ghc -M In-Reply-To: <046.7dbf2ab1bf1975707055f3f2e91a0e84@localhost> References: <046.7dbf2ab1bf1975707055f3f2e91a0e84@localhost> Message-ID: <055.a39674f5e87bf064f12270b820fa93c5@localhost> #1248: Use sensible flags for ghc -M ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): OK, I've sorted out the argument parsing, so now it's just a matter of picking good new names and marking the old ones as deprecated. Any objections to these? {{{ -optdep-f -> --dep-makefile -optdep-s -> --dep-suffix -optdep--include-pkg-deps -> --include-pkg-deps -optdep--exclude-module -> --exclude-module }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 17:38:49 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 17:28:57 2008 Subject: [GHC] #2438: memory performance problem when compiling lots of derived instances in a single file In-Reply-To: <044.ea581854aeddeff62675b30ef35f5bfc@localhost> References: <044.ea581854aeddeff62675b30ef35f5bfc@localhost> Message-ID: <053.ee7c4ee362e0de565fc3f0fd26f1ba43@localhost> #2438: memory performance problem when compiling lots of derived instances in a single file ------------------------------------------+--------------------------------- Reporter: claus | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 20 17:49:40 2008 From: trac at galois.com (GHC) Date: Sun Jul 20 17:39:50 2008 Subject: [GHC] #2451: New signal-handling API In-Reply-To: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> References: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> Message-ID: <056.3271f6be950a268378ead015c316f48a@localhost> #2451: New signal-handling API ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 00:12:47 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 00:03:07 2008 Subject: [GHC] #2455: Building ticky-ticky profiling libraries doesn't work Message-ID: <042.404a6408ffd00bc83f7ff98903be15f6@localhost> #2455: Building ticky-ticky profiling libraries doesn't work ------------------------+--------------------------------------------------- Reporter: tim | Owner: tim Type: task | Status: new Priority: normal | Component: Profiling Version: 6.9 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- On ghc-users, Andrew Hunter pointed out that "make way=t" for the libraries is broken. If I try it with a clean libraries/ directory in the HEAD, I get: {{{ [snip] echo dist/build/cbits/longlong.t_o dist/build/GHC/Bool.t_o dist/build/GHC/Generics.t_o dist/build/GHC/Ordering.t_o dist/build/GHC/PrimopWrappers.t_o dist/build/GHC/IntWord32.t_o dist/build/GHC/IntWord64.t_o `find dist/build -name "*_stub.t_o" -print` | xargs /usr/bin/ar q dist/build/libHSghc-prim-0.1_t.a /usr/bin/ar: creating dist/build/libHSghc-prim-0.1_t.a make[1]: Leaving directory `/home/tjc/GhcTrees/ticky-test/libraries/ghc- prim' Registering ghc-prim-0.1... Reading package info from "dist/inplace-pkg-config" ... done. ghc-pkg-inplace: cannot find libHSghc-prim-0.1.a on library path (use --force to override) make: *** [make.library.ghc-prim] Error 1 }}} This isn't shocking, since the package system doesn't know to look for the ticky versions of libraries (and I think the filename should be libHSghc- prim-0.1.t_a and not libHSghc-prim-0.1_t.a, besides), but it should be fixed. I'll try to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 03:30:25 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 03:20:32 2008 Subject: [GHC] #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." Message-ID: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." ------------------------+--------------------------------------------------- Reporter: ronwalf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X ------------------------+--------------------------------------------------- {{{ $ rm -f DerivingError.o DerivingError.hi; ghc --make DerivingError.hs [1 of 1] Compiling DerivingError ( DerivingError.hs, DerivingError.o ) /var/folders/C0/C0SledGV2RaxbU+8ZLDnVU+++TI/-Tmp-//ghc27223_0/ghc27223_0.s:6080:0: FATAL:Symbol _XxG_srt already defined. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 03:54:54 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 03:45:06 2008 Subject: [GHC] #2455: Building ticky-ticky profiling libraries doesn't work In-Reply-To: <042.404a6408ffd00bc83f7ff98903be15f6@localhost> References: <042.404a6408ffd00bc83f7ff98903be15f6@localhost> Message-ID: <051.09f47e753b78902286fc535eb34d2ebb@localhost> #2455: Building ticky-ticky profiling libraries doesn't work --------------------------+------------------------------------------------- Reporter: tim | Owner: tim Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.9 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------+------------------------------------------------- Comment (by tim): I realized that the error I was seeing above was because I was running "make way=t" under libraries/ after doing a clean build, which doesn't seem to work for way=p either. But if I set GhcLibWays to "t" in the build.mk file, and "make" from the top level, it doesn't seem to build a copy of the libraries with ticky enabled either. At this point I'm thoroughly confused about what's going on, but I'll look into it later. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 04:57:52 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 04:48:00 2008 Subject: [GHC] #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." In-Reply-To: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> References: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> Message-ID: <055.e8416eda5025293a477fb1d81491bac6@localhost> #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." -------------------------+-------------------------------------------------- Reporter: ronwalf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: As discussed on haskell-cafe, it seems this bug doesn't come about as of GHC 6.9.20080720: http://www.haskell.org/pipermail/haskell-cafe/2008-July/045404.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 05:28:30 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 05:18:37 2008 Subject: [GHC] #2457: Seq causes panic in GHCi Message-ID: <052.f49613a35315bb727f65212defe6fc11@localhost> #2457: Seq causes panic in GHCi ------------------------------+--------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X ------------------------------+--------------------------------------------- While trying to understand the semantic differences between seq and pseq, when looking at the Control.Parallel page, it says that the compiler may transform "x `seq` y" into "y `seq` x `seq` y" Trying this in GHCi lead me to this: {{{ $ ghci GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> let x = tail [1..] Prelude> x `seq` () () Prelude> () `seq` x `seq` () ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-apple-darwin): nameModule (){v 71} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> }}} When testing this in a file however, things go smoothly: {{{ $ cat seq.hs x = tail [1..] -- x `seq` y can apparently be transformed -- into y `seq` x `seq y v = () `seq` x `seq` () main = return v $ ghc --make seq.hs [1 of 1] Compiling Main ( seq.hs, seq.o ) Linking seq ... $ ./seq; echo $? 0 $ }}} I cannot be sure if this bug still occurs as of GHC 6.9.20080720, as ghci is apparently broken in my build (this could have to do with build settings but I am not sure, it has to do with the fact that the base library can't find the _environ symbol; should I file another report?) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 06:10:37 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 06:00:44 2008 Subject: [GHC] #2457: Seq causes panic in GHCi In-Reply-To: <052.f49613a35315bb727f65212defe6fc11@localhost> References: <052.f49613a35315bb727f65212defe6fc11@localhost> Message-ID: <061.53ce639882942430a800b5c85132bd46@localhost> #2457: Seq causes panic in GHCi ---------------------------+------------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report; happily, this works in the HEAD: {{{ GHCi, version 6.9.20080720: 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 x = tail [1..] Prelude> x `seq` () () Prelude> () `seq` x `seq` () () }}} We discovered the `_environ` problem in #ghc yesterday. I have a fix in my tree which I should be able to push soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 06:57:57 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 06:48:04 2008 Subject: [GHC] #2457: Seq causes panic in GHCi In-Reply-To: <052.f49613a35315bb727f65212defe6fc11@localhost> References: <052.f49613a35315bb727f65212defe6fc11@localhost> Message-ID: <061.4aafa061dc610e3ee20b59a901be62b3@localhost> #2457: Seq causes panic in GHCi ---------------------------+------------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------------+------------------------------------------------ Comment (by duncan): It's weirder than that though. It works in 6.8.2 (on amd64/linux at least). Does it fail with 6.8.3 on all platforms or is it just OSX? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 07:15:30 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 07:05:37 2008 Subject: [GHC] #2457: Seq causes panic in GHCi In-Reply-To: <052.f49613a35315bb727f65212defe6fc11@localhost> References: <052.f49613a35315bb727f65212defe6fc11@localhost> Message-ID: <061.1443f5558dbfbbbc400698fde0859725@localhost> #2457: Seq causes panic in GHCi ---------------------------+------------------------------------------------ Reporter: thoughtpolice | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------------+------------------------------------------------ Comment (by igloo): All platforms, yes. I assume it was caused by {{{ Fri May 16 09:51:49 BST 2008 simonpj@microsoft.com * Improve the treatment of 'seq' (Trac #2273) }}} and fixed by {{{ Tue Jul 1 17:37:22 BST 2008 simonpj@microsoft.com * Easy fix for Trac #2409 }}} but I haven't verified that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 08:54:41 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 08:44:49 2008 Subject: [GHC] #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode In-Reply-To: <049.31db7471187fa0b39e4d12923cd80edb@localhost> References: <049.31db7471187fa0b39e4d12923cd80edb@localhost> Message-ID: <058.5558e4b1885a2b6b79698eadb00f2a8f@localhost> #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode -------------------------------------+-------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by jcpetruzza): IMO, the GHC-API in interactive mode can be used to build very cool IDE- tools. Maybe an interactive refactoring tool is not the best example one can think of, but I hope it still illustrates the idea. In any case, the point I wanted to make is this: in interactive mode, the typechecker behaves in a unique way and right now there is no way to turn this off. Thus, one simply cannot write an application that uses powerful features from interactive mode and simultaneously relies on a "standard" typechecker. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 10:02:12 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 09:52:24 2008 Subject: [GHC] #2458: GHC MacOS X Leopard build succeeds, but ghci complains about: unknown symbol `_environ' Message-ID: <048.8d22aecac33c2afb7c79a5628eb01872@localhost> #2458: GHC MacOS X Leopard build succeeds, but ghci complains about: unknown symbol `_environ' --------------------------+------------------------------------------------- Reporter: IgorBoehm | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.9 | Severity: major Keywords: environ | Testcase: Architecture: x86 | Os: MacOS X --------------------------+------------------------------------------------- Shared libraries and bundles on MacOS X Leopard don't have direct access to environ (i.e. extern char **environ), which is only available to the loader ld when a complete program is being linked. If direct access to environ is needed, the _NSGetEnviron() routine, defined in can be used to retrieve the address of environ at runtime ([http://developer.apple.com/documentation/Darwin/Reference/ManPages/man7/environ.7.html man environ(7)] see last paragraph in section PROGRAMMING). Two Libraries are affected by this - namely [http://darcs.haskell.org/packages/base/ base] and [http://darcs.haskell.org/packages/unix/ unix]. Both of these Libraries implement (duplicate code) access to environ: * [http://darcs.haskell.org/packages/base/include/HsBase.h base/include/HsBase.h]: {{{ * ToDo: write a feature test that doesn't assume 'environ' to * be in scope at link-time. */ extern char** environ; INLINE char **__hscore_environ() { return environ; } }}} * [http://darcs.haskell.org/packages/unix/include/HsUnix.h unix/include/HsUnix.h] {{{ extern char **environ; }}} Unfortunately this does not work on MaxOS X Leopard with XCode 3.0. My temporary workaround was to comment out the current definition of environ in the header files and add the following instead: * Hack for [http://darcs.haskell.org/packages/base/include/HsBase.h base/include/HsBase.h]: {{{ /* ToDo: write a feature test that doesn't assume 'environ' to * be in scope at link-time. */ //extern char **environ; //INLINE char **__hscore_environ() { return environ; } #include INLINE char **__hscore_environ(void) { return (*_NSGetEnviron()); } }}} * Hack for [http://darcs.haskell.org/packages/unix/include/HsUnix.h unix/include/HsUnix.h]: {{{ //extern char **environ; #include INLINE char **__hsunix_environ (void) { return (*_NSGetEnviron()); } }}} * Hack for [http://darcs.haskell.org/packages/unix/System/Posix/Env.hsc unix/System/Posix/Env.hsc]: {{{ --getEnvironmentPrim :: IO [String] --getEnvironmentPrim = do -- c_environ <- peek c_environ_p -- arr <- peekArray0 nullPtr c_environ -- mapM peekCString arr -- --foreign import ccall unsafe "&environ" -- c_environ_p :: Ptr (Ptr CString) getEnvironmentPrim :: IO [String] getEnvironmentPrim = do c_environ <- c_environ_p arr <- peekArray0 nullPtr c_environ mapM peekCString arr foreign import ccall unsafe "__hsunix_environ" c_environ_p :: IO (Ptr CString) }}} Unfortunately I do not know GHC well enough to propose a clean patch. With these 'hacks' ghc compiled from source on MacOS X Leopard with XCode 3.0 works well. It would also probably be good to get rid of the code duplication in the base and unix libraries. Shall I open another Ticket for libraries/unix? References: * [http://developer.apple.com/documentation/Darwin/Reference/ManPages/man7/environ.7.html environ man page] * [http://lists.apple.com/archives/Java-dev/2007/Dec/msg00096.html response to similar problem on Apple Mailing List] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 10:22:34 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 10:12:40 2008 Subject: [GHC] #2459: can't link haskell without "main" function, or -no-hs-main broken on windows? Message-ID: <042.a892bb62d9bf138a3680ca1e496e0413@localhost> #2459: can't link haskell without "main" function, or -no-hs-main broken on windows? ------------------------+--------------------------------------------------- Reporter: jvl | Owner: Type: bug | Status: new Priority: normal | Component: Driver Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Windows ------------------------+--------------------------------------------------- can't link haskell without "main" function, or -no-hs-main broken on windows? The issue arose when trying to compile wxHaskell examples with a !WinMain entry point in the executable rather than the standard "main" function, thereby stopping a new console window being created when the application starts up, i.e. creating a "windows" application. luckily (by chance, I think) the desired objective can be achieved without any change to the haskell code as follows, with the support that gcc already provides for a !WinMain entry point, utilising the wxHaskell example: {{{ > ghc -o HelloWorl.o -fglasgow-exts -c HelloWorld.hs > ghc -optl-mwindows -o HelloWorld.exe HelloWorld.o -package wxcore }}} OK, so what is the issue ? We what if we want to define our own !WinMain or utilise the !WinMain or other entry point provided by another object file or code. According to the ghc documentation the way it could be achieved would be, with this example ... !MyHelloWorld.hs .. {{{ > module Hello where > > foreign export ccall "runHsMain" runMain :: IO () > > runMain = do > putStrLn "Hello World" }}} and mymain.c {{{ #include "HsFFI.h" extern void __stginit_Hello ( void ); extern void runHsMain(); int main(int argc, char* argv[]) { hs_init(&argc, &argv); hs_add_root(__stginit_Hello); runHsMain(); hs_exit(); return 0; } }}} {{{ > ghc -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs > ghc -o hello.exe mymain.c MyHelloWorld.o MyHelloWorld_stub.o > hello.exe Hello World }}} all works fine, but dosn't ghc documentation say, the -no-hs-main option should be used ? OK so use it {{{ > ghc -no-hs-main -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs > ghc -no-hs-main -o hello.exe mymain.c MyHelloWorld.o MyHelloWorld_stub.o > hello.exe Hello World }}} OK, works both with and without -no-hs-main, strange? but how about if we want to define our own !WinMain or dllMain etc (i.e. no main at all) winmain.c: {{{ #include #include "HsFFI.h" extern void __stginit_Hello ( void ); extern void runHsMain(); int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow) { hs_init(0, 0); hs_add_root(__stginit_Hello); hs_exit(); return 0; } }}} you can use the above haskell hello example or the wxHaskell !HelloWorld example but with edits to main/module name as per !MyHelloWorld, call it !MyHelloWorldW. But the above Haskell suffices as a test case, and is used in the following. linking with winmain, we get this error: {{{ >ghc -no-hs-main -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined reference to ` __stginit_ZCMain' C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined reference to `ZCMain_main_closure' collect2: ld returned 1 exit status }}} it appears ghc does something like this (normal operation, for a standard haskell main) * create bootstrapping that initialises the ghc runtime and adds the root !__stginit_ZCMain, and runs the haskell main * create a "c" main that calls/executes the bootstrapping code * the executables entry point will be set by default to the "c" "main" procedure it seems that linking the haskell object with an object that already contains a main symbol will: * suppress the creation of bootstrapping code * executable entry point still set to the default ("main") this behaviour is exhibitted regardless of -no-hs-main option When the haskell objects are linked with other objects and even though -no-hs-main option is specified it appears that ghc: * creates bootstrapping that initialises the ghc runtime and adds the root !__stginit_ZCMain, and runs the haskell main * creates a main that calls/executes the bootstrapping code * executable entry point still set to the default ("main") i.e. the same behaviour as for "normal" execution, this behaviour appears wrong, the behaviour should be: * suppress the creation of bootstrapping code (initialisation of haskell should be the responsibility of the external code, per guidlines) * executable entry point still set to default i.e., as in the above example hs_add_root initialises the root module (!__stginit_Hello) and there is no requirement for an !__stginit_ZCMain. you can get the above example to compile and link with ... {{{ >ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs >ghc -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o }}} but if this is the wxHaskell !HelloWorld example, you would see that the it still starts up as a console application and not a !WinMain (windows) application. the effect of using th -main-is option is to insert a "!___stginit_ZCMain" symbol into the !HelloWorld.o object. A "c" "main" will be created, initialising haskell and invoking the haskell main Hell.runMain. The entry point of the executable will be this "main", i.e. regard, [link with ldl-mwindows to set entry to win32,see what happens] {{{ > ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs > ghc -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o }}} the above will compile and run but, will not invoke the winmain, rather it will invoke the automatically generated "main". the following {{{ > ghc -main-is Hello.runMain -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs > ghc -optl-mwindows -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o >winhello }}} will invoke the !WinMain routine as a windows application, (in this example a popup will be displayed reporting an error "hPutChar invalid arg bad file descriptor", as it should), ignoring the haskell supplied main/init. BUT you shouldn't have to compile the haskell module with -main-is ... in order to get the overall exe to link , i.e. the following should work {{{ >ghc -no-hs-main -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs >ghc -optl-mwindows -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o }}} but we get ... {{{ C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x7):Main.c: undefined reference to ` __stginit_ZCMain' C:/apps/ghc/6.8.2/libHSrts.a(Main.o)(.text+0x36):Main.c: undefined reference to `ZCMain_main_closure' collect2: ld returned 1 exit status }}} what should be: * no-hs-main option should suppress the requirement for a !___stginit_ZCMain symbol, this should enable the linking of, and specification of an arbitrary entry point into the executable external to the haskell code. i.e. the last example should work. the -optl-mwindows on the ghc command line we can flip the .exe entry point for the executable to a windows entry point, gcc seems to handle it as follows: if the above -mwindows option is given then the entry point of the executable is set to !WinMainCRTStartup, which in turn calls the !WinMain function (if present) or the supplied main, it also sets the subsystem to windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 10:32:28 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 10:22:35 2008 Subject: [GHC] #2460: provide -mwindows option like gcc Message-ID: <042.8396d2df2e0ff931276aa5a0abcdaca6@localhost> #2460: provide -mwindows option like gcc --------------------------------+------------------------------------------- Reporter: jvl | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Windows --------------------------------+------------------------------------------- provide a command line option -mwindows (aka main windows) to compile and link the code as a windows executable (i.e. WinMain). This is mearly a matter of passing through the option to gcc and would be trivial to implement. see #2459 for full discussion. Why Bother ? To enahnce "User Friendliness" and encourage gui users on win32 aka wxHaskell and Gtk2Hs users to produce application with "Native" look and feel. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 17:07:49 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 16:58:01 2008 Subject: [GHC] #2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6 In-Reply-To: <042.cebcc11cc6f8e024f65fef292f8041c0@localhost> References: <042.cebcc11cc6f8e024f65fef292f8041c0@localhost> Message-ID: <051.3fa80039f018676a75c9fe4c63c3bccd@localhost> #2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6 -------------------------------+-------------------------------------------- Reporter: cjs | Owner: bos Type: bug | Status: assigned Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by bos): * status: new => assigned * owner: => bos Comment: This sounds like a peculiarity of the BSD networking stack. On Linux, the code correctly chooses a wildcard address that responds to both IPv4 and IPv6 traffic. I'd strongly suggest that a BSD user dig into the platform-specific problem. Suggesting an API change without any investigation of the underlying issue is not the right approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 21 22:41:45 2008 From: trac at galois.com (GHC) Date: Mon Jul 21 22:31:50 2008 Subject: [GHC] #2460: provide -mwindows option like gcc In-Reply-To: <042.8396d2df2e0ff931276aa5a0abcdaca6@localhost> References: <042.8396d2df2e0ff931276aa5a0abcdaca6@localhost> Message-ID: <051.5d1cfb3c887c51eb09f2775914b850b8@localhost> #2460: provide -mwindows option like gcc --------------------------------+------------------------------------------- Reporter: jvl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Windows --------------------------------+------------------------------------------- Comment (by duncan): Of course one can already use `-optl-mwindows` which is what the Gtk2Hs FAQ has been recommending for the past couple years. If we want to make it really user friendly we should deal with the issue that when in `-mwindows` mode, reading from stdin or writing to stdout/stderr causes an exception. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 22 03:30:58 2008 From: trac at galois.com (GHC) Date: Tue Jul 22 03:21:05 2008 Subject: [GHC] #2432: type family panic: Coercion.splitCoercionKindOf In-Reply-To: <044.419fb1a60288d8516aab35dbc1443539@localhost> References: <044.419fb1a60288d8516aab35dbc1443539@localhost> Message-ID: <053.e6e2294f2d33a23550bfc04b0b6d0552@localhost> #2432: type family panic: Coercion.splitCoercionKindOf -------------------------------------+-------------------------------------- Reporter: claus | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by chak): * owner: => chak Comment: Probably a duplicate of #2432, but I'll leave it open and verify once #2432 has been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 22 03:32:17 2008 From: trac at galois.com (GHC) Date: Tue Jul 22 03:22:25 2008 Subject: [GHC] #2432: type family panic: Coercion.splitCoercionKindOf In-Reply-To: <044.419fb1a60288d8516aab35dbc1443539@localhost> References: <044.419fb1a60288d8516aab35dbc1443539@localhost> Message-ID: <053.7528a44d60ef9ef22a217875dd27227c@localhost> #2432: type family panic: Coercion.splitCoercionKindOf -------------------------------------+-------------------------------------- Reporter: claus | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by chak): Oops - #2432 is this ticket, I mean to write this is a duplicate of #1999. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 22 03:51:53 2008 From: trac at galois.com (GHC) Date: Tue Jul 22 03:42:06 2008 Subject: [GHC] #2454: Closing handle from runInteractiveProcess causes myserious, uncatchable death. In-Reply-To: <042.e4e6e52741f4105b24c0e1aa7038eedc@localhost> References: <042.e4e6e52741f4105b24c0e1aa7038eedc@localhost> Message-ID: <051.4e4af91adc21340ac58dc29887982b1c@localhost> #2454: Closing handle from runInteractiveProcess causes myserious, uncatchable death. ----------------------------+----------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Multiple | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: duplicate of #1619, now fixed. Thanks anyway for a nice report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 22 03:54:55 2008 From: trac at galois.com (GHC) Date: Tue Jul 22 03:45:01 2008 Subject: [GHC] #1248: Use sensible flags for ghc -M In-Reply-To: <046.7dbf2ab1bf1975707055f3f2e91a0e84@localhost> References: <046.7dbf2ab1bf1975707055f3f2e91a0e84@localhost> Message-ID: <055.56699d9401b7196fdb7054585cefc22d@localhost> #1248: Use sensible flags for ghc -M ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): Yes, but with single dashes only. Right now the only double-dash options are "mode" options, which seems as good a convention as any. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 22 10:22:39 2008 From: trac at galois.com (GHC) Date: Tue Jul 22 10:12:42 2008 Subject: [GHC] #2424: Error compiling Crypto-4.1.0 on ghc-6.8.3 In-Reply-To: <047.5175165ab642b3e70df2d2bcd3e5fe6e@localhost> References: <047.5175165ab642b3e70df2d2bcd3e5fe6e@localhost> Message-ID: <056.f6568d08f326e772d5b308c0711877a1@localhost> #2424: Error compiling Crypto-4.1.0 on ghc-6.8.3 ----------------------+----------------------------------------------------- Reporter: kristall | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Looks like this is already fixed in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 22 11:56:33 2008 From: trac at galois.com (GHC) Date: Tue Jul 22 11:46:44 2008 Subject: [GHC] #2309: containers: specialize functions that fail in a Monad to Maybe In-Reply-To: <043.a73cd7403da16bcdc6cc412935455c2a@localhost> References: <043.a73cd7403da16bcdc6cc412935455c2a@localhost> Message-ID: <052.44347c90d487ca49e1647422bfe02eae@localhost> #2309: containers: specialize functions that fail in a Monad to Maybe -------------------------------+-------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by ross): Several container classes have types like {{{ lookup :: (Monad m, Ord k) => k -> Map k a -> m a }}} and use fail to signal exceptional conditions. This allows them to be used with a range of monads, e.g. [], IO and parser monads. Some of these use the string passed to fail. However the strings are not very useful, and probably shouldn't be exposed in production code: {{{ Data.Map.lookup: Key not found Data.Map.lookupIndex: Key not found Data.Map.minViewWithKey: empty map Data.Map.maxViewWithKey: empty map Data.Map.minView: empty map Data.Map.maxView: empty map }}} The problem with this device is that depending on the monad, fail can be an ordinary value, an exception or a runtime error (the default). It complicates checking whether a program is safe, because it hides possible runtime errors among testable conditions. The proposal was to revert these types to the simpler {{{ lookup :: (Ord k) => k -> Map k a -> Maybe a }}} No information would be lost, as each of these functions has only one use of fail -- the Maybe type describes the situation precisely. As the initial "thing with zero and return", it can be lifted to any other. Several people argued that the non-Maybe case is rare, and explicitly marking use of a different monad is no bad thing. Changing the monad classes is not a possibility at this stage: we need to work with the classes as defined in Haskell 98. No-one defended the status quo, but Twan van Laarhoven and Dan Doel argued that if the constraint were changed from Monad to `MonadPlus`, one should be able to assume a safe fail, while avoiding the the need for lifting. At present, fail in STM and Seq use the default error, which could be changed. Haskell 98 specifies the fail in IO as throwing an exception (the `MonadPlus` instance is in the mtl package). In favour of the proposal were: apfelmus, Conor !McBride, David Menendez, Don Stewart, Duncan Coutts, Iavor Diatchki, Isaac Dupree, Josef Svenningsson, Krasimir Angelov, Lennart Augustsson, Neil Mitchell, Ross Paterson. That's not consensus, but it is a substantial majority, and I think we've explored all the issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 22 11:57:41 2008 From: trac at galois.com (GHC) Date: Tue Jul 22 11:47:45 2008 Subject: [GHC] #2309: containers: specialize functions that fail in a Monad to Maybe In-Reply-To: <043.a73cd7403da16bcdc6cc412935455c2a@localhost> References: <043.a73cd7403da16bcdc6cc412935455c2a@localhost> Message-ID: <052.686d83450c0c573132f751598ccd3ae9@localhost> #2309: containers: specialize functions that fail in a Monad to Maybe -------------------------------+-------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by ross): * status: new => closed * resolution: => fixed Comment: oops, forgot to close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 22 12:05:06 2008 From: trac at galois.com (GHC) Date: Tue Jul 22 11:55:18 2008 Subject: [GHC] #2455: Building ticky-ticky profiling libraries doesn't work In-Reply-To: <042.404a6408ffd00bc83f7ff98903be15f6@localhost> References: <042.404a6408ffd00bc83f7ff98903be15f6@localhost> Message-ID: <051.e53100eebe32bed450ea98c29fc7cd19@localhost> #2455: Building ticky-ticky profiling libraries doesn't work -----------------------+---------------------------------------------------- Reporter: tim | Owner: tim Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Profiling | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: We probably need some sort of support from Cabal for building different "way"s. I don't know if there are any plans for how this should work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 22 12:09:00 2008 From: trac at galois.com (GHC) Date: Tue Jul 22 11:59:03 2008 Subject: [GHC] #2461: add Traversable generalizations of mapAccumL and mapAccumR Message-ID: <043.013a273f6f1f47f6080e2f3a0bdc3cdd@localhost> #2461: add Traversable generalizations of mapAccumL and mapAccumR -------------------------+-------------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- The proposal is to add the following functions to Data.Traversable, generalizing the list versions in Data.List: {{{ -- |The 'mapAccumL' function behaves like a combination of 'fmap' -- and 'foldl'; it applies a function to each element of a structure, -- passing an accumulating parameter from left to right, and returning -- a final value of this accumulator together with the new structure. mapAccumL :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) -- |The 'mapAccumR' function behaves like a combination of 'fmap' -- and 'foldr'; it applies a function to each element of a structure, -- passing an accumulating parameter from right to left, and returning -- a final value of this accumulator together with the new structure. mapAccumR :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) }}} These functions are handy for things like labelling trees, zipping, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 22 12:36:46 2008 From: trac at galois.com (GHC) Date: Tue Jul 22 12:26:49 2008 Subject: [GHC] #1248: Use sensible flags for ghc -M In-Reply-To: <046.7dbf2ab1bf1975707055f3f2e91a0e84@localhost> References: <046.7dbf2ab1bf1975707055f3f2e91a0e84@localhost> Message-ID: <055.0d8272e1406f5ea914ab367157bf4eef@localhost> #1248: Use sensible flags for ghc -M ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: igloo Type: task | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 22 21:17:01 2008 From: trac at galois.com (GHC) Date: Tue Jul 22 21:07:07 2008 Subject: [GHC] #2459: can't link haskell without "main" function, or -no-hs-main broken on windows? In-Reply-To: <042.a892bb62d9bf138a3680ca1e496e0413@localhost> References: <042.a892bb62d9bf138a3680ca1e496e0413@localhost> Message-ID: <051.1307882cb78a5656fcee5611d4279e75@localhost> #2459: can't link haskell without "main" function, or -no-hs-main broken on windows? ------------------------+--------------------------------------------------- Reporter: jvl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Windows ------------------------+--------------------------------------------------- Comment (by jvl): correction, the last example should read {{{ >ghc -c -fglasgow-exts -o MyHelloWorld.o MyHelloWorld.hs >ghc -optl-mwindows -no-hs-main -o winhello.exe winmain.c MyHelloWorld.o MyHelloWorld_stub.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 23 01:02:26 2008 From: trac at galois.com (GHC) Date: Wed Jul 23 00:52:27 2008 Subject: [GHC] #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu In-Reply-To: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> References: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> Message-ID: <053.0be1acda22ddac513c89f4111adc76e0@localhost> #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: trivial | Resolution: Keywords: OGI | Testcase: Architecture: Unknown | Os: Unknown ------------------------------+--------------------------------------------- Changes (by guest): * keywords: => OGI * summary: users_guide/syntax-extns.html # 8.3.3 has obsolete ref to www.cse.ogi.edu/PacSoft/ => users_guide/syntax- extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu Comment: Other dead links in doc: Many of the MTL pages: http://haskell.org/ghc/docs/latest/html/libraries/mtl/Control-Monad- RWS.html http://haskell.org/ghc/docs/latest/html/libraries/mtl/Control-Monad-RWS- Lazy.html http://haskell.org/ghc/docs/latest/html/libraries/mtl/Control-Monad- State.html etc... have a broken reference to http://www.cse.ogi.edu/~mpj that should be changed to one of these: http://www.google.com/search?q=Functional+Programming+with+Overloading+and +Higher-Order+Polymorphism Actually, it would be extra swell if Mark Jones would give permission and relevant text from the paper (or a new writeup) could be included in the documentation directly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 23 04:24:05 2008 From: trac at galois.com (GHC) Date: Wed Jul 23 04:14:06 2008 Subject: [GHC] #2462: Data.List.sum is slower than 6.8.3 Message-ID: <047.a070686fa958e3b92e101be0217ff9b1@localhost> #2462: Data.List.sum is slower than 6.8.3 -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- {{{ main = print (sum [1..100000000::Int]) }}} with 6.8.3: {{{ MUT time 1.76s ( 1.79s elapsed) }}} with HEAD (22/7/08) {{{ MUT time 1.97s ( 1.99s elapsed) }}} complete guess: sum has been mis-optimised by SAT? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 23 12:03:03 2008 From: trac at galois.com (GHC) Date: Wed Jul 23 11:53:06 2008 Subject: [GHC] #2005: localhost on mac causes getnameinfo error in safari. In-Reply-To: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost> References: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost> Message-ID: <052.890b77a3e53cc8bbc086ff44abc37579@localhost> #2005: localhost on mac causes getnameinfo error in safari. ------------------------------------+--------------------------------------- Reporter: alex | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.8.2 Severity: normal | Resolution: Keywords: network localhost ipv6 | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ------------------------------------+--------------------------------------- Comment (by judah): claude, if you're referring to #2391 this appears to be a different issue. The problem is that we aren't setting a necessary field the in IPV6 socket address struct. I've submitted a fix to the libraries list: http://www.haskell.org/pipermail/libraries/2008-July/010239.html With that fix, danb's `Server.hs` running on OS X accepts connections on both IPV4 and IPV6 (`localhost`, `127.0.0.1` and `::1` all work). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 23 13:27:21 2008 From: trac at galois.com (GHC) Date: Wed Jul 23 13:17:23 2008 Subject: [GHC] #1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs In-Reply-To: <044.a916af5b8c38ab63a7239d33e71dfb3b@localhost> References: <044.a916af5b8c38ab63a7239d33e71dfb3b@localhost> Message-ID: <053.7db3885d044a4a29ef5f09e0cbecd0d6@localhost> #1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs ---------------------+------------------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: closed Priority: normal | Milestone: 6.10.1 Component: hsc2hs | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We now use the standalone hsc2hs repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 23 15:32:44 2008 From: trac at galois.com (GHC) Date: Wed Jul 23 15:23:19 2008 Subject: =?utf-8?b?UmU6IFtHSENdICMxNzEyOiB1bmtub3duIHN5bWJvbCDigJxnbHV0?= =?utf-8?b?R2V04oCd?= In-Reply-To: <065.b6ed7b12defb8965a01b63493858f588@localhost> References: <065.b6ed7b12defb8965a01b63493858f588@localhost> Message-ID: <074.2647a42fe3c897c8cdd1680342a84a99@localhost> #1712: unknown symbol ?glutGet? ----------------------------------------+----------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Comment (by gdweber): As I understand the comment on 10/30/07, this bug was fixed in GHC version 6.8.0.20071029 -- that would be before 6.8.1, right? This bug re-appeared in 6.8.2, but is not present in 6.8.3. Would some test cases help to prevent it from re-appearing again in future releases? I can provide some, if that would help. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 23 18:18:12 2008 From: trac at galois.com (GHC) Date: Wed Jul 23 18:08:14 2008 Subject: [GHC] #1232: generalise runhaskell to support arbitrary file names, not just those with .{l}hs extensions In-Reply-To: <047.cac0ff6b1474594ce3579cffcdfc1b73@localhost> References: <047.cac0ff6b1474594ce3579cffcdfc1b73@localhost> Message-ID: <056.35116195a27977f5718450e00a7afa34@localhost> #1232: generalise runhaskell to support arbitrary file names, not just those with .{l}hs extensions -----------------------------+---------------------------------------------- Reporter: Frederik | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: runhaskell | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Wed Jul 23 19:21:56 BST 2008 Ian Lynagh * If the extension is not .lhs, runghc now treats it as .hs; fixes trac #1232 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 23 18:18:55 2008 From: trac at galois.com (GHC) Date: Wed Jul 23 18:08:53 2008 Subject: [GHC] #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH In-Reply-To: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> References: <051.688c37be95655ef452fcfa7bd4cd6ebf@localhost> Message-ID: <060.02911e01f88eb0ae3d915aa6c0b2d858@localhost> #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Wed Jul 23 19:11:15 BST 2008 Ian Lynagh * runghc now uses the compiler that it comes with; fixes trac #1281 rather than the first one that it finds on the PATH }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From duncan.coutts at worc.ox.ac.uk Wed Jul 23 18:51:26 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Jul 23 18:40:03 2008 Subject: [GHC] #1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs In-Reply-To: <053.7db3885d044a4a29ef5f09e0cbecd0d6@localhost> References: <044.a916af5b8c38ab63a7239d33e71dfb3b@localhost> <053.7db3885d044a4a29ef5f09e0cbecd0d6@localhost> Message-ID: <1216853486.12754.55.camel@localhost> On Wed, 2008-07-23 at 17:27 +0000, GHC wrote: > #1479: Merge GHC's hsc2hs with http://darcs.haskell.org/hsc2hs > ---------------------+------------------------------------------------------ > Reporter: igloo | Owner: igloo > Type: task | Status: closed > Priority: normal | Milestone: 6.10.1 > Component: hsc2hs | Version: 6.6.1 > Severity: normal | Resolution: fixed > Keywords: | Difficulty: Unknown > Testcase: | Architecture: Unknown > Os: Unknown | > ---------------------+------------------------------------------------------ > Changes (by igloo): > > * status: new => closed > * resolution: => fixed > > Comment: > > We now use the standalone hsc2hs repo. Hooray! Good job Ian. Fewer unnecessary forks. Speaking of which I should really remove the fork of c2hs that's bundled with gtk2hs... Duncan From trac at galois.com Wed Jul 23 18:55:16 2008 From: trac at galois.com (GHC) Date: Wed Jul 23 18:45:52 2008 Subject: =?utf-8?b?UmU6IFtHSENdICMxNzEyOiB1bmtub3duIHN5bWJvbCDigJxnbHV0?= =?utf-8?b?R2V04oCd?= In-Reply-To: <065.b6ed7b12defb8965a01b63493858f588@localhost> References: <065.b6ed7b12defb8965a01b63493858f588@localhost> Message-ID: <074.f5b843024f6434cb43707ba94275a0f0@localhost> #1712: unknown symbol ?glutGet? ----------------------------------------+----------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Comment (by igloo): It looks like this problem was caused by bindist creation issues, and the plan is for OpenGL not to be in the bindists any more, so thanks for the offer but I don't think it would. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 23 19:46:56 2008 From: trac at galois.com (GHC) Date: Wed Jul 23 19:37:07 2008 Subject: [GHC] #607: Ticky-ticky profiling In-Reply-To: <047.e5dd649fce23786fe47a53426e7bbe8b@localhost> References: <047.e5dd649fce23786fe47a53426e7bbe8b@localhost> Message-ID: <056.8a919960a66e942c0df26820c91bd41b@localhost> #607: Ticky-ticky profiling ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: tim Type: task | Status: assigned Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: normal | Resolution: None Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by tim): * status: new => assigned * owner: => tim Comment: Oops, I never saw SimonM's last comment here until now. I'll try to look at this as part of looking into #2455, though I don't currently have a need for ticky either, so it may not happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 23 20:12:30 2008 From: trac at galois.com (GHC) Date: Wed Jul 23 20:02:31 2008 Subject: [GHC] #1232: generalise runhaskell to support arbitrary file names, not just those with .{l}hs extensions In-Reply-To: <047.cac0ff6b1474594ce3579cffcdfc1b73@localhost> References: <047.cac0ff6b1474594ce3579cffcdfc1b73@localhost> Message-ID: <056.38a46d26b255c05fecd828d0064ac4ef@localhost> #1232: generalise runhaskell to support arbitrary file names, not just those with .{l}hs extensions -----------------------------+---------------------------------------------- Reporter: Frederik | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: runhaskell | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Unknown | -----------------------------+---------------------------------------------- Comment (by Frederik): Yay! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 24 12:51:57 2008 From: trac at galois.com (GHC) Date: Thu Jul 24 12:41:57 2008 Subject: [GHC] #2385: Include cabal-install in the release In-Reply-To: <047.5e5d3c71f6963642c3502db02e692018@localhost> References: <047.5e5d3c71f6963642c3502db02e692018@localhost> Message-ID: <056.6e0069e4f19c15f3c782e54801dea986@localhost> #2385: Include cabal-install in the release --------------------------+------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: high | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: We've discussed this, and concluded that cabal-install should come with the HP installer rather than the GHC installer. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 24 15:53:09 2008 From: trac at galois.com (GHC) Date: Thu Jul 24 15:43:05 2008 Subject: [GHC] #2463: unsafePerformIO in unused record field affects optimisations Message-ID: <044.c6c9ce581b0819e0d3e27b236eaad365@localhost> #2463: unsafePerformIO in unused record field affects optimisations -----------------------------------------+---------------------------------- Reporter: claus | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- I have some code that runs 2x slower or worse than a previous version, for no obvious reasons. In an attempt to root out the cause, I made a copy and started deleting parts of the code, until I noticed that I could trigger the performance difference by whether or not I initialise a record field that is no longer even used in this reduced source! Further refinement shows that much of the performance difference depends on whether that ''unused'' field is initialised using 'unsafePerformIO' (needed to use 'typeRepKey') or 'undefined'. To reproduce, switch the lines with commented with '-- slow' and '--fast': {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.9.20080514 $ ghc --make -O2 Main [2 of 3] Compiling GPS ( GPS.hs, GPS.o ) GPS.hs:29:8: Warning: Pattern match(es) are overlapped In the definition of `typeRepKey'': typeRepKey' tr = ... Linking Main.exe ... $ ./Main.exe >dump 5553600000 "Data.Generics.GPS countStuff: 20 secs" $ ghc --make -O2 Main [2 of 3] Compiling GPS ( GPS.hs, GPS.o ) GPS.hs:29:8: Warning: Pattern match(es) are overlapped In the definition of `typeRepKey'': typeRepKey' tr = ... [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... $ ./Main.exe >dump 5553600000 "Data.Generics.GPS countStuff: 11 secs" }}} 'Main' uses 'GPS' and 'CompanyDatatypes' for some benchmarking of a Syb variant, hence the blown-up data structures and Syb imports. Only the code in 'GPS' seems to be directly involved, so perhaps one could achieve the same effect by constructing a non-Syb loop, but I'm reluctant to reduce this further, as the performance impact has started to disappear with shrinking code. Since the remaining code doesn't actually do much anymore, the issue doesn't seem to be in my code, which is nice. But in the original version, I need that record field, and I need to use 'typeRepKey' via 'unsafePerformIO', so any suggestions for helpful compiler options, etc would be welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 24 16:24:54 2008 From: trac at galois.com (GHC) Date: Thu Jul 24 16:14:49 2008 Subject: [GHC] #2464: Allow #ifdef'd pragmas Message-ID: <042.da2d7162b5833ab052aba0dee11396e7@localhost> #2464: Allow #ifdef'd pragmas --------------------------------+------------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Sometimes I want to do something like {{{ {-# LANGUAGE CPP #-} #ifdef RUN_TESTS {-# LANGUAGE GeneralizedNewtypeDeriving #-} #endif module Foo where #ifdef RUN_TESTS import Test.QuickCheck #endif newtype Bar = Bar Int #ifdef RUN_TESTS deriving Arbitrary #endif ... }}} especially (like in that example) for embedding testing code in my modules. I want to #ifdef the pragma so that my code stays Haskell98 when it's only being used, not tested, but this doesn't seem to work. I suppose this would require two passes of looking for pragmas if CPP was invoked; one before CPP and one after, because the -XCPP option can be invoked in a pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 24 16:58:32 2008 From: trac at galois.com (GHC) Date: Thu Jul 24 16:48:29 2008 Subject: [GHC] #2465: View + Pattern Match not fused sufficiently Message-ID: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> #2465: View + Pattern Match not fused sufficiently ---------------------------------------------+------------------------------ Reporter: ryani | Owner: Type: compile-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows ---------------------------------------------+------------------------------ This came up while playing with the ICFP2007 task. I have a function {{{dnaView :: DNA -> [D]}}}; DNA is a {{{[ByteString]}}} and D is just the enum {{{I|C|F|P}}}. When I call a function that just pattern matches on the result, I think the pattern matching function should be fused with the view -- the view should run as a coroutine. I've attached an example. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 25 00:16:01 2008 From: trac at galois.com (GHC) Date: Fri Jul 25 00:05:55 2008 Subject: [GHC] #2466: Execution time mis-accounting Message-ID: <047.14a5fe48bc275ad5be0eac4353281985@localhost> #2466: Execution time mis-accounting -------------------------+-------------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Component: Profiling Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- In the attached test case, profiling assigns a large fraction of run time to a single function. The fraction ranges from 19% to 40% across runs. Although I haven't independently verified the profile, I believe execution time is mis-attributed to this function. The function in question is: {{{ intersect :: Object -> Ray -> Maybe Intersection intersect obj@(Object dat mem) = objmIntersect mem dat obj }}} where `objmIntersect` is a field selector. In `-ddump-simpl` output, the function consists of two case statements and a function call. The function it calls has its own SCC. In profiling, this function is usually listed as the most time-consuming function in the program. Its callee is assigned a similar amount of time. Both functions are called the same number of times. The callee computes a ray-triangle intersection, which is presumably more time-consuming than two case statements and a function call... {{{ COST CENTRE MODULE %time %alloc intersect Datatypes 28.5 11.3 triangle.intersect Triangle 25.0 2.0 (other functions...) }}} I've reduced the test case from a somewhat larger ray tracer. I'm willing to help reduce it further if needed. The test case depends on the [http://haskell.org/haskellwiki/Vector-space vector-space] library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 25 08:35:48 2008 From: trac at galois.com (GHC) Date: Fri Jul 25 08:25:47 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.a2ba9a3de8e1c98e50df298ce83b0e15@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: Svarog Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by Svarog): * owner: => Svarog -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 25 10:46:50 2008 From: trac at galois.com (GHC) Date: Fri Jul 25 10:36:43 2008 Subject: [GHC] #2467: orphan instance warnings are badly behaved Message-ID: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> #2467: orphan instance warnings are badly behaved ------------------------+--------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- There are two problems with them: * They do not respect -Werror. That is they are not fatal when using -Werror. * They are ugly. They do not explain the issue or use Haskell syntax. They look like a dump of internal data structures and mention internally generated names. {{{ Warning: orphan instances: instance HAppS.Data.Serialize.Serialize [Distribution.Server.Types.PkgInfo] = Distribution.Server.State.$f1 instance HAppS.Data.Serialize.Version [Distribution.Server.Types.PkgInfo] = Distribution.Server.State.$f2 instance HAppS.Data.Serialize.Serialize [Distribution.Package.PackageIdentifier] = Distribution.Server.State.$f3 instance HAppS.Data.Serialize.Version [Distribution.Package.PackageIdentifier] = Distribution.Server.State.$f4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 25 18:51:02 2008 From: trac at galois.com (GHC) Date: Fri Jul 25 18:41:07 2008 Subject: [GHC] #1997: Stricter enumFrom instance for Integer, to match Int In-Reply-To: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost> References: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost> Message-ID: <052.2d83ea45fdb83a70dd59ad514fa18342@localhost> #1997: Stricter enumFrom instance for Integer, to match Int -----------------------------------+---------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: lib/should_run/enum04 | Architecture: Multiple Os: Multiple | -----------------------------------+---------------------------------------- Changes (by Bart Massey): * severity: normal => major Comment: The current Report only requires that enumFrom* on Int, Integer, Float and Double instances be strict in all their arguments, but arguably all instances should be strict in this way. Otherwise, the behavior gets pretty mystifying---in particular, the referenced stack overflows and out- of-memory errors. The patch from dons for enumDeltaInteger needs to be accepted. In addition, similar patches should be constructed for Float and Double. (Before 6.10 would be even better; this is a non-trivial deviation from the Report...) For 6.10, someone should probably also go through the remaining Enum types and make sure that their enumFrom is strict in its arguments as well. (Several of us just spent a half-day on #haskell tracking this down and verifying it. Then dons pointed us at this bug report. :-) Thanks much to rwbarton, dolio, dons, and others on #haskell for helping me understand this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 26 04:11:14 2008 From: trac at galois.com (GHC) Date: Sat Jul 26 04:01:21 2008 Subject: [GHC] #1997: Stricter enumFrom instance for Integer, to match Int In-Reply-To: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost> References: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost> Message-ID: <052.4ad6004ab1e849146331b4e85146ec81@localhost> #1997: Stricter enumFrom instance for Integer, to match Int -----------------------------------+---------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: lib/should_run/enum04 | Architecture: Multiple Os: Multiple | -----------------------------------+---------------------------------------- Comment (by Bart Massey): My attached patch file provides a patch against current GHC head which should fix most of the types. It needs review and testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 26 18:50:25 2008 From: trac at galois.com (GHC) Date: Sat Jul 26 18:40:17 2008 Subject: [GHC] #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode In-Reply-To: <049.31db7471187fa0b39e4d12923cd80edb@localhost> References: <049.31db7471187fa0b39e4d12923cd80edb@localhost> Message-ID: <058.7e0e9c2a60b0a318f2100a2dd34143c7@localhost> #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode -------------------------------------+-------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by guest): * cc: id@isaac.cedarswampstudios.org (removed) * cc: gwern0@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 26 18:51:09 2008 From: trac at galois.com (GHC) Date: Sat Jul 26 18:40:57 2008 Subject: [GHC] #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode In-Reply-To: <049.31db7471187fa0b39e4d12923cd80edb@localhost> References: <049.31db7471187fa0b39e4d12923cd80edb@localhost> Message-ID: <058.03a24801ddbb4dd4e6ac69e94ec43f39@localhost> #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode -------------------------------------+-------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by guest): * cc: id@isaac.cedarswampstudios.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 26 18:54:53 2008 From: trac at galois.com (GHC) Date: Sat Jul 26 18:44:42 2008 Subject: [GHC] #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode In-Reply-To: <049.31db7471187fa0b39e4d12923cd80edb@localhost> References: <049.31db7471187fa0b39e4d12923cd80edb@localhost> Message-ID: <058.771f70c899659476267f27f2295fd843@localhost> #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode -------------------------------------+-------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by guest): Igloo: I don't really think this is much related to the Safe Haskell proposal, which is pretty comprehensive and addresses all the attacks circumventing IO. Rather, this is more "I want modules and imports to work the way they already do (in normal source files), and to stop being exceptional when it goes through the GHC API" (ie. not allowing the code to do stuff the imports forbid), if you follow me. I mean, if you import Foreign, everything will still be as unsafe as before. This just avoids GHC going out of its way to sabotage security efforts. -- gwern -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 26 18:55:17 2008 From: trac at galois.com (GHC) Date: Sat Jul 26 18:45:08 2008 Subject: [GHC] #1380: Safe Haskell In-Reply-To: <044.3b0885c88c35a1aacdb90750c7783a3a@localhost> References: <044.3b0885c88c35a1aacdb90750c7783a3a@localhost> Message-ID: <053.dc3f504bca9a7702bd009edfe734b8a2@localhost> #1380: Safe Haskell -----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by guest): * cc: gwern0@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 26 23:37:16 2008 From: trac at galois.com (GHC) Date: Sat Jul 26 23:27:06 2008 Subject: [GHC] #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode In-Reply-To: <049.31db7471187fa0b39e4d12923cd80edb@localhost> References: <049.31db7471187fa0b39e4d12923cd80edb@localhost> Message-ID: <058.baa894c10bcb0c14c502e98eb9917d99@localhost> #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode -------------------------------------+-------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by guest): So, I'd just like to mention an example of why I really don't like this bug: it forces me to use stuff like the Hint sandboxing to work around it. Why is this so bad? Well, I just blew 5 or 6 hours this evening because of the Hint sandboxing. I was trying to add UTF support, since lambdabot can handle it, and I was having serious problems: each and every time compilation failed with UTF chars, even though they are perfectly valid in GHCi and Lambdabot. As I eventually discovered: turns out that while evaluating straight through the GHC API works fine when your expression contains strange UTF characters, Hint's sandboxing internally works via writing a module to a file and also one's expression. And of course it uses the usual 'writeFile' function, and as we all know, the basic GHC IO functions are all broken w/r/t Unicode, and of course I didn't remember that the sandboxing flag changed the route. And that is how my evening was wasted. Now, is it this bug/GHC's fault that Hint used the standard IO functions instead of uft8-string's functions? No. (Well, maybe in the broader sense.) Is it even Hint's fault? Not really. But the fact remains that my evening was quite unpleasant because of this unchangeable behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 27 04:54:09 2008 From: trac at galois.com (GHC) Date: Sun Jul 27 04:43:58 2008 Subject: [GHC] #2468: Wrong names in Mangler script Message-ID: <043.ceb2592b5f923064428cfcba80ddc7f3@localhost> #2468: Wrong names in Mangler script ------------------------+--------------------------------------------------- Reporter: jsnx | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- From [http://darcs.haskell.org/ghc/driver/mangler/ghc-asm.lprl the perl]: {{{ .... #--------------------------------------------------------# } elsif ( $TargetPlatform =~ /^i386-apple-darwin.*/m ) { # Apple PowerPC Darwin/MacOS X. .... #--------------------------------------------------------# } elsif ( $TargetPlatform =~ /^x86_64-apple-darwin.*/m ) { # Apple PowerPC Darwin/MacOS X. .... }}} These versions of OS X are both i386 of some flavor, not PowerPC :) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 27 09:32:06 2008 From: trac at galois.com (GHC) Date: Sun Jul 27 09:21:55 2008 Subject: [GHC] #2469: Linking fails with "multiple definition of `deRefStablePtr'" Message-ID: <048.9eb18d1762f2087efabea300fec1f63f@localhost> #2469: Linking fails with "multiple definition of `deRefStablePtr'" -------------------------------------+-------------------------------------- Reporter: meteficha | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.8.2 | Severity: normal Keywords: linker ffi stableptr | Testcase: Architecture: Unknown | Os: Multiple -------------------------------------+-------------------------------------- Package Hipmunk-0.1 in Hackage compiles fine, but when compiling !HipmunkPlayground-0.1 it fails with something like (this message from Hackage build log) {{{ Building executable: HipmunkPlayground... Creating dist/build/HipmunkPlayground (and its parents) Creating dist/build/HipmunkPlayground/HipmunkPlayground-tmp (and its parents) /usr/local/bin/ghc -o dist/build/HipmunkPlayground/HipmunkPlayground --make -hide-all-packages -i -idist/build/autogen -idist/build/HipmunkPlayground/HipmunkPlayground-tmp -i. -Idist/build/HipmunkPlayground/HipmunkPlayground-tmp -odir dist/build/HipmunkPlayground/HipmunkPlayground-tmp -hidir dist/build/HipmunkPlayground/HipmunkPlayground-tmp -stubdir dist/build/HipmunkPlayground/HipmunkPlayground-tmp -package containers-0.1.0.1 -package base-3.0.1.0 -package Hipmunk-0.1 -package OpenGL-2.2.1.1 -package GLFW-0.3 -O -Wall ./Playground.hs [1 of 1] Compiling Main ( ./Playground.hs, dist/build/HipmunkPlayground/HipmunkPlayground-tmp/Main.o ) Linking dist/build/HipmunkPlayground/HipmunkPlayground ... /usr/local/lib/ghc-6.8.2/libHSrts.a(Stable.o): In function `deRefStablePtr': Stable.c:(.text+0x0): multiple definition of `deRefStablePtr' /usr/local/tmp/archive/install/lib/Hipmunk-0.1/ghc-6.8.2/libHSHipmunk-0.1.a(Space_stub.o):Space_stub.c:(.text+0x0): first defined here collect2: ld returned 1 exit status }}} This bug has been observed on some configurations, but not on some others: || '''Worked''' || '''Box tried''' || '''Arch''' || '''OS''' || '''Version''' || || ''Failed'' || My 2nd box || x86_32 || Debian Linux || GHC 6.8.2 || || ''Failed'' || dons' box || ??? || ??? Linux || GHC 6.8.2 || || ''Failed'' || Antoines's box || x86_?? || Mac OS 10.5 || GHC 6.8.2 || || ''Failed'' || Hackage || ??? || ??? || GHC 6.8.2 || || Ok || My 1st box || x86_64 || Gentoo Linux || GHC 6.8.3 || || Ok || My 3rd box || x86_32 || Windows XP || GHC 6.8.1 || On all cases that failed above, the message was about multiple definition of defRefStablePtr (which Hipmunk doesn't use directly). On my 2nd box and on dons' one, it was confirmed that configuring the Hipmunk package (not HipmunkPlayground where the problem appears) with "--enable-split-objs" makes everything work. I think this is a GHC bug because it works on some boxes and because there's nothing fancy on Hipmunk (specially about StablePtr's). Some possibly useful links: * http://hackage.haskell.org/packages/archive/HipmunkPlayground/0.1/logs/failure/ghc-6.8 * http://www.haskell.org/pipermail/haskell-cafe/2008-July/045543.html I don't have a clue on what is needed to reproduce this bug, but I'll try to give any info as requested. At first I thought about bug 2100 that got fixed in 6.8.3, but my 3rd box with 6.8.1 doesn't complain. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 27 16:15:28 2008 From: trac at galois.com (GHC) Date: Sun Jul 27 16:05:16 2008 Subject: [GHC] #2469: Linking fails with "multiple definition of `deRefStablePtr'" In-Reply-To: <048.9eb18d1762f2087efabea300fec1f63f@localhost> References: <048.9eb18d1762f2087efabea300fec1f63f@localhost> Message-ID: <057.d2865d81d620e749332ac7741eef8810@localhost> #2469: Linking fails with "multiple definition of `deRefStablePtr'" -------------------------------------+-------------------------------------- Reporter: meteficha | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: Keywords: linker ffi stableptr | Testcase: Architecture: Unknown | Os: Multiple -------------------------------------+-------------------------------------- Changes (by guest): * cc: aslatter@gmail.com (added) Comment: Upgrading my Mac to 6.8.3 and typeing "cabal install HipmunkPlayround" produces the same error, if that's any help. -Antoine -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 28 04:12:22 2008 From: trac at galois.com (GHC) Date: Mon Jul 28 04:02:07 2008 Subject: [GHC] #2185: Memory leak with parMap In-Reply-To: <044.5c6962ddf20fe9d5c3ed9f8bcf46a5b6@localhost> References: <044.5c6962ddf20fe9d5c3ed9f8bcf46a5b6@localhost> Message-ID: <053.75825a552ee7c66c89046a577ea46ea7@localhost> #2185: Memory leak with parMap --------------------------------------+------------------------------------- Reporter: igloo | Owner: simonmar Type: run-time performance bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * status: closed => reopened * component: Compiler => Runtime System * resolution: fixed => Comment: unfixed. Sparks really should be treated as GC roots, because many uses of par rely on this behaviour (including most of the strategies library). I don't have any ideas for how to fix this yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 28 10:06:47 2008 From: trac at galois.com (GHC) Date: Mon Jul 28 09:56:37 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.77c6a309825abcd68f8d08e8482e5334@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by Svarog): * owner: Svarog => simonmar Comment: Added patches that add C finalizers that can be run directly from the garbage collector. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 28 10:24:30 2008 From: trac at galois.com (GHC) Date: Mon Jul 28 10:14:15 2008 Subject: [GHC] #2470: read for StdGen fails for arbitrary string Message-ID: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> #2470: read for StdGen fails for arbitrary string ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/random Version: 6.8.3 | Severity: normal Keywords: StdGen read | Testcase: Architecture: x86 | Os: Windows ----------------------------+----------------------------------------------- According to the docs for StdGen: "In addition, read may be used to map an arbitrary string (not necessarily one produced by show) onto a value of type StdGen. In general, the read instance of StdGen has the following properties: * It guarantees to succeed on any string. * It guarantees to consume only a finite portion of the string. * Different argument strings are likely to result in different results." Here's what happens on my system: C:\odm\ghc\lib>ghci GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :mod +System.Random Prelude System.Random> (read "tasty tofu") :: StdGen Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package random-1.0.0.0 ... linking ... done. *** Exception: Prelude.read: no parse Prelude System.Random> You can contact me at orielmaxime@yahoo.com if you need more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 28 11:34:16 2008 From: trac at galois.com (GHC) Date: Mon Jul 28 11:24:07 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.2048fedb5a89b4e90f2f0da447144273@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Comment (by Svarog): Replying to [comment:6 Svarog]: > Added patches that add C finalizers that can be run directly from the garbage collector. Just in case it's not clear, fix1364-ghc.patch should be applied to ghc and fix1364-base.patch should be applied to the base library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 28 14:13:10 2008 From: trac at galois.com (GHC) Date: Mon Jul 28 14:03:00 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.0691561b35420d9ca2ffb1397bdfc08e@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by tibbe): * cc: johan.tibell@gmail.com (added) Comment: Replying to [comment:6 Svarog]: > Added patches that add C finalizers that can be run directly from the garbage collector. Will this add a performance penalty (i.e. extra GC overhead) to code that does not make use of finalizers? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 28 14:35:24 2008 From: trac at galois.com (GHC) Date: Mon Jul 28 14:25:06 2008 Subject: [GHC] #2470: read for StdGen fails for arbitrary string In-Reply-To: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> References: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> Message-ID: <053.2bb64778d838582e75b20398996158be@localhost> #2470: read for StdGen fails for arbitrary string ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/random | Version: 6.8.3 Severity: normal | Resolution: Keywords: StdGen read | Testcase: Architecture: x86 | Os: Windows ---------------------------------+------------------------------------------ Comment (by guest): With further thought, I wonder if I misunderstand the specification. From reading the code, it looks like the read instance is using the first 6 characters to construct the StdGen result. However, because the rest of the string is "left over" and unprocessed, the read call fails whenever there are more than 6 characters in the passed string. Two notes: (1) The number 6 is undocumented, making the behavior of read incompehensible without examining the code; (2) it's unclear how this specification interacts with compound structures, like the derived instance of read :: String -> (StdGen,StdGen). What would we expect read "(longword,longerword,longestword)" :: (StdGen,StdGen) to do? How do we know which commas mean what? If whoever looks at this decides this is an enhancement rather than a bug, I won't be too terribly hurt. Again, you can contact me at orielmaxime@yahoo.com. Exposing stdFromString (perhaps with a different name) might make everything cleaner. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 28 15:11:45 2008 From: trac at galois.com (GHC) Date: Mon Jul 28 15:01:36 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.33b4b87a9cb4999ce44b6840caf6fda0@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Comment (by Svarog): Replying to [comment:8 tibbe]: > > Will this add a performance penalty (i.e. extra GC overhead) to code that does not make use of finalizers? I'm pretty sure that it won't. The only overhead is that the weak pointer struct now has an extra field for a C finalizer and the code that goes through dead weak pointers and schedules existing Haskell finalizers has an extra if statement to check for C finalizers and run them immediately. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 28 15:46:27 2008 From: trac at galois.com (GHC) Date: Mon Jul 28 15:36:25 2008 Subject: [GHC] #1997: Stricter enumFrom instance for Integer, to match Int In-Reply-To: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost> References: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost> Message-ID: <052.2adc8e780c9d8eb42be60a8daba17339@localhost> #1997: Stricter enumFrom instance for Integer, to match Int -----------------------------------+---------------------------------------- Reporter: dons | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: lib/should_run/enum04 | Architecture: Multiple Os: Multiple | -----------------------------------+---------------------------------------- Changes (by igloo): * owner: => igloo * milestone: 6.10 branch => 6.10.1 Comment: Thanks for the patch! We'll take a look -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 28 16:49:36 2008 From: trac at galois.com (GHC) Date: Mon Jul 28 16:39:19 2008 Subject: [GHC] #2470: read for StdGen fails for arbitrary string In-Reply-To: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> References: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> Message-ID: <053.9b742f631dde940bf18b35b73e411206@localhost> #2470: read for StdGen fails for arbitrary string ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/random | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: StdGen read | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Strings that are the result of showing a StdGen work fine as part of structures: {{{ Prelude System.Random> let x = (mkStdGen 100, mkStdGen 200) Prelude System.Random> x (101 1,201 1) Prelude System.Random> let y = show x Prelude System.Random> y "(101 1,201 1)" Prelude System.Random> let z = read y :: (StdGen,StdGen) Prelude System.Random> z (101 1,201 1) Prelude System.Random> }}} For reading a random string you can use `reads` to avoid the exception. We've discussed this before, although I can't find the ticket now (it might have been on a mailing list or something), and concluded that given the "finite portion" requirement the current behaviour is the best. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 28 17:11:04 2008 From: trac at galois.com (GHC) Date: Mon Jul 28 17:00:46 2008 Subject: [GHC] #2470: read for StdGen fails for arbitrary string In-Reply-To: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> References: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> Message-ID: <053.ff3e063aa708e7e5b1118ebcba2ab5f7@localhost> #2470: read for StdGen fails for arbitrary string ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/random | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: StdGen read | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Comment (by guest): igloo: would it be appropriate to document the "read 6 characters"? Just a final thought. At a minimum, my interpretation of the phrase "using different strings is likely to result in different generators" is strongly violated by a dependency on the first six characters, unless that's documented. No worries either way. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 28 17:21:57 2008 From: trac at galois.com (GHC) Date: Mon Jul 28 17:11:39 2008 Subject: [GHC] #1930: infix type constructors are printed incorrectly by GHC In-Reply-To: <044.4cf3e6fbd26fe995daaaaeb63fab91ac@localhost> References: <044.4cf3e6fbd26fe995daaaaeb63fab91ac@localhost> Message-ID: <053.76ef0499e2ccc42ae887e547880c0794@localhost> #1930: infix type constructors are printed incorrectly by GHC ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by nfrisby): Moreover, infix constructors - even those that are not operators - are also incorrectly printed. {{{ data Report = AsExpected Outcome | Outcome `InsteadOf` Outcome }}} Note how GHC 6.8.2 prints the !InsteadOf operator without the backticks: {{{ *Correctness> :i Report data Report = AsExpected Outcome | Outcome InsteadOf Outcome -- Defined at Correctness.hs:23:5-10 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 06:39:53 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 06:29:37 2008 Subject: [GHC] #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs In-Reply-To: <046.59221d2fec02e33b156d46e404241b5d@localhost> References: <046.59221d2fec02e33b156d46e404241b5d@localhost> Message-ID: <055.681ccdbc28436ef9aed85900902c9d27@localhost> #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs -------------------------+-------------------------------------------------- Reporter: oboudry | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: driver081.* | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------+-------------------------------------------------- Changes (by simonmar): * keywords: => driver081.* * status: new => closed * resolution: => fixed Comment: Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 06:40:48 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 06:30:29 2008 Subject: [GHC] #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs In-Reply-To: <046.59221d2fec02e33b156d46e404241b5d@localhost> References: <046.59221d2fec02e33b156d46e404241b5d@localhost> Message-ID: <055.cdd5b48b84a1fa96bfa4e726dcf9c47e@localhost> #2248: .exe extension missing when compiling a file ending in dot + digits + dot hs -------------------------+-------------------------------------------------- Reporter: oboudry | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: driver081.* | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------+-------------------------------------------------- Comment (by simonmar): {{{ Fri Jul 11 08:11:46 PDT 2008 Simon Marlow * FIX #2248 Unconditionally add .exe to the output executable name when using --make on Windows, and no -o option was given. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 07:16:32 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 07:06:14 2008 Subject: [GHC] #631: GHCi doesn't work unregisterised In-Reply-To: <058.77987f0da5513fbc618ea4c0e4ce6de9@localhost> References: <058.77987f0da5513fbc618ea4c0e4ce6de9@localhost> Message-ID: <067.a8f04bd52584375ca932c529f2e2527f@localhost> #631: GHCi doesn't work unregisterised ---------------------------------+------------------------------------------ Reporter: trentbuck@gmail.com | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.4.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Now fixed; I have an unregisterised build on x86_64/Linux with a completely working GHCi, including FFI (using libffi) and debugger. The final fix was: {{{ Mon Jul 28 08:56:21 PDT 2008 Simon Marlow * Change the calling conventions for unboxed tuples slightly When returning an unboxed tuple with a single non-void component, we now use the same calling convention as for returning a value of the same type as that component. This means that the return convention for IO now doesn't vary depending on the platform, which make some parts of the RTS simpler, and fixes a problem I was having with making the FFI work in unregisterised GHCi (the byte-code compiler makes some assumptions about calling conventions to keep things simple). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 08:43:44 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 08:33:26 2008 Subject: [GHC] #1603: a miscompilation of (`rem` 0x40000000)::Int with -O -fvia-C In-Reply-To: <051.236bdfc382b4b8b333be4e1f7b023bf9@localhost> References: <051.236bdfc382b4b8b333be4e1f7b023bf9@localhost> Message-ID: <060.679def55c3a0d39fcce8c8a35c66d928@localhost> #1603: a miscompilation of (`rem` 0x40000000)::Int with -O -fvia-C --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: None | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: numeric/1603 | Architecture: Multiple Os: Multiple | --------------------------+------------------------------------------------- Changes (by simonmar): * milestone: 6.10.1 => 6.10 branch Comment: FYI, gcc 4.2.3 and later has the fix. Only one of my machines has this (Fedora 9), so I don't think we can close the bug just yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 08:52:15 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 08:41:57 2008 Subject: [GHC] #2470: read for StdGen fails for arbitrary string In-Reply-To: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> References: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> Message-ID: <053.e893fe577e8aa06c46cbf0174d21787a@localhost> #2470: read for StdGen fails for arbitrary string ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/random | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: StdGen read | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Comment (by Isaac Dupree): IMHO it would be appropriate to specify in the documentation that (read::String->StdGen) is only guaranteed to work on the result of (show::StdGen->String). The "read 6 characters" can be mentioned as an implementation detail. (Then it's just like all other read/show pairs: it works fine in tuples.) That leaves us free to / forces us to come up with a more proper suite of functions for initializing a generator (for example, taking all the bits in a finite list into account, initializing from an Int, from an Integer, etc.) -Isaac -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 09:02:37 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 08:52:18 2008 Subject: [GHC] #2471: generate C wrappers for FFI functions Message-ID: <047.b55a3f6edbbae1ef25207e61f546365e@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 | Keywords: Difficulty: Moderate (1 day) | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------+------------------------------------------ We often need to go via a wrapper when calling a C function using the FFI, because the function is part of the API but not the ABI (e.g. it is defined using a CPP macro, or renamed using a CPP macro). In order to support these calls more easily, we could have GHC automatically generate the appropriate C wrappers into the stub file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 09:04:17 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 08:54:25 2008 Subject: [GHC] #2305: GHC does not care __RENAME macro In-Reply-To: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost> References: <044.e399572fbb2da5bdb111ddafffcbdbb1@localhost> Message-ID: <053.4c3793cb854d8aee89662cf71f3a5a92@localhost> #2305: GHC does not care __RENAME macro -----------------------------+---------------------------------------------- Reporter: iquiw | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: NetBSD | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: reopened => closed * resolution: => wontfix Comment: Closing; if there is a need for wrappers in particular libraries then someone should open tickets for those. To help with the more general problem, I've created Task #2471. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 09:07:21 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 08:57:05 2008 Subject: [GHC] #2323: Segfaulting binary only with modules In-Reply-To: <043.59108a38ad3f698b1c3d8890dcfb5bc4@localhost> References: <043.59108a38ad3f698b1c3d8890dcfb5bc4@localhost> Message-ID: <052.a173261f102db2ff6ecf8bf932aca719@localhost> #2323: Segfaulting binary only with modules ----------------------+----------------------------------------------------- Reporter: yrn1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: I'm also unable to reproduce on x86_64/Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 09:44:56 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 09:34:37 2008 Subject: [GHC] #1603: a miscompilation of (`rem` 0x40000000)::Int with -O -fvia-C In-Reply-To: <051.236bdfc382b4b8b333be4e1f7b023bf9@localhost> References: <051.236bdfc382b4b8b333be4e1f7b023bf9@localhost> Message-ID: <060.27cd4d7a67cbbcad208ff6b999f61991@localhost> #1603: a miscompilation of (`rem` 0x40000000)::Int with -O -fvia-C --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: None | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: numeric/1603 | Architecture: Multiple Os: Multiple | --------------------------+------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: on second thoughts, having the bug open doesn't really achieve anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 09:45:51 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 09:35:36 2008 Subject: [GHC] #2327: -O flag produces faulty code In-Reply-To: <050.bb840f94897b26ad4ed51d48f56b2d63@localhost> References: <050.bb840f94897b26ad4ed51d48f56b2d63@localhost> Message-ID: <059.e15de791b1807d90b1f27f1e948780ad@localhost> #2327: -O flag produces faulty code ----------------------------+----------------------------------------------- Reporter: orenbenkiki | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: Optimizer -O | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'm on this one, looks like a problem with the thunk-selector machinery (again; surprise surprise). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 11:37:06 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 11:26:47 2008 Subject: [GHC] #2332: Can't allocate 4 gigs of RAM In-Reply-To: <049.b927c02f2fd47c4ea604c4be8f41114f@localhost> References: <049.b927c02f2fd47c4ea604c4be8f41114f@localhost> Message-ID: <058.eface292515152ccfaa0e397c875e409@localhost> #2332: Can't allocate 4 gigs of RAM -------------------------------+-------------------------------------------- Reporter: mightybyte | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: memory allocation | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * component: Compiler => Runtime System * resolution: => fixed Comment: Fixed: {{{ Tue Jul 29 16:04:59 BST 2008 Simon Marlow * FIX #2332: avoid overflow on 64-bit machines in the memory allocator }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 11:37:48 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 11:27:34 2008 Subject: [GHC] #2327: -O flag produces faulty code In-Reply-To: <050.bb840f94897b26ad4ed51d48f56b2d63@localhost> References: <050.bb840f94897b26ad4ed51d48f56b2d63@localhost> Message-ID: <059.51b079f1d08a7bded67b1b108d750efc@localhost> #2327: -O flag produces faulty code ----------------------------+----------------------------------------------- Reporter: orenbenkiki | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: Optimizer -O | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Tue Jul 29 16:05:18 BST 2008 Simon Marlow * FIX #2327: a fault in the thunk-selector machinery (again) This program contains an expression of the form let x = snd (_, snd (_, snd (_, x))) (probably not explicitly, but that's what appears in the heap at runtime). Obviously the program should deadlock if it ever enters this thing, but apparently the test program in #2327 never does. The GC tries to evaluate the snd closures, and gets confused due to the loop. In particular the earlier fix for #1038 was to blame. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 29 19:03:45 2008 From: trac at galois.com (GHC) Date: Tue Jul 29 18:53:26 2008 Subject: [GHC] #2472: GHC: Hard-coded and wrong path to perl interpreter for ghc-asm Message-ID: <046.0c29c740873e6968d58d3860791897c0@localhost> #2472: GHC: Hard-coded and wrong path to perl interpreter for ghc-asm -------------------------------+-------------------------------------------- Reporter: sanketr | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: major Keywords: ghc, asm, perl | Testcase: Architecture: x86 | Os: MacOS X -------------------------------+-------------------------------------------- In ghc-asm, the interpreter is hard-coded to /opt/local/bin/perl. On Mac (and Linux as well), the path for perl interpreter is usually /usr/bin/perl. The work-around should be to use the "env" variable instead of hard-coded path. So, the first statement should be: #!/usr/bin/env perl -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 05:46:37 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 05:46:43 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.3120bc21b945427a7127645567fe5c5b@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: GHCi | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: reopened => new * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 06:13:32 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 06:13:37 2008 Subject: [GHC] #2375: RTS assertion failure on Vista with -DEBUG In-Reply-To: <043.34dc15d41b49327b2a6587cf172331a9@localhost> References: <043.34dc15d41b49327b2a6587cf172331a9@localhost> Message-ID: <052.f10804d5867aab0de9fdbe349db11f01@localhost> #2375: RTS assertion failure on Vista with -DEBUG -----------------------------------------------+---------------------------- Reporter: dias | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: rts -DEBUG hashtables memory leak | Difficulty: Unknown Testcase: ghci/prog002 | Architecture: x86 Os: Windows | -----------------------------------------------+---------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 06:35:52 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 06:35:54 2008 Subject: [GHC] #2376: GHC.Word: shiftR and shiftL are not marked as inline. In-Reply-To: <044.1d775a18fce526f6afc014f2bd5a4272@localhost> References: <044.1d775a18fce526f6afc014f2bd5a4272@localhost> Message-ID: <053.853c456b5e31945501aa0a87f6c8b1bd@localhost> #2376: GHC.Word: shiftR and shiftL are not marked as inline. ----------------------------------+----------------------------------------- Reporter: mjark | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: inline shiftR shiftL | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 06:55:28 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 06:55:38 2008 Subject: [GHC] #2388: GHC creates invalid test instruction for 64-bit code In-Reply-To: <056.33dc1f03d68892257923e7c03147f8f1@localhost> References: <056.33dc1f03d68892257923e7c03147f8f1@localhost> Message-ID: <065.b7ee22531f3a3a0a88896c93481b1ecd@localhost> #2388: GHC creates invalid test instruction for 64-bit code -------------------------------+-------------------------------------------- Reporter: MartinGrabmueller | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 07:06:13 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 07:06:22 2008 Subject: [GHC] #2397: inclusion of Network.Curl causes compiler issues and coredumps In-Reply-To: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> References: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> Message-ID: <053.9a5b850927c9a2b157a17e93982c805c@localhost> #2397: inclusion of Network.Curl causes compiler issues and coredumps -------------------------------+-------------------------------------------- Reporter: b7j0c | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: curl, GC | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: the program currently hangs for me waiting for a response from download.finance.yahoo.com. I'll try again later. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 07:47:08 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 07:47:10 2008 Subject: [GHC] #2401: unsafeIOToSTM hangs with 64 bit multicore. In-Reply-To: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> References: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> Message-ID: <052.c2c71184f55e77969ee6bfac9deea2ff@localhost> #2401: unsafeIOToSTM hangs with 64 bit multicore. ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: major | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: I understand what's happening here. Inside a transaction you're doing this: {{{ unsafeIOToSTM $ putStrLn ".." }}} Now, `putStrLn` needs to take a lock on `stdin`. But the STM implementation assumes it can abort a transaction at any time, and in this case it aborts a transaction in the middle of `putStrLn` (because it discovered the transaction was already invalid). When it aborts the transaction, the exception handler in `putStrLn` is discarded (STM didn't expect there to be a real IO exception handler in the middle of a transaction). So `stdin` remains locked, and the program eventually deadlocks. Perhaps we could fix this by throwing a real exception, but there's quite a large design space there, and in any case when using `unsafeIOToSTM` you're really on your own. I'll put a big warning in the docs for `unsafeIOToSTM` though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 08:03:18 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 08:03:24 2008 Subject: [GHC] #2405: Panic when using gtk2hs from ghci In-Reply-To: <047.41535c8adbd9e2dcf8a550a77421cdc4@localhost> References: <047.41535c8adbd9e2dcf8a550a77421cdc4@localhost> Message-ID: <056.324c45d33852de2c4d619ef77f6ff99c@localhost> #2405: Panic when using gtk2hs from ghci ----------------------+----------------------------------------------------- Reporter: wagstaff | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 08:05:00 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 08:05:04 2008 Subject: [GHC] #2407: internal error In-Reply-To: <048.61f1ce93106e412769adb2b6a8addcd6@localhost> References: <048.61f1ce93106e412769adb2b6a8addcd6@localhost> Message-ID: <057.a03d7c74cfbea1a01958776728b577d8@localhost> #2407: internal error ----------------------------+----------------------------------------------- Reporter: vigalchin | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: 1 month with no feedback; closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 08:43:56 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 08:44:01 2008 Subject: [GHC] #2405: Panic when using gtk2hs from ghci In-Reply-To: <047.41535c8adbd9e2dcf8a550a77421cdc4@localhost> References: <047.41535c8adbd9e2dcf8a550a77421cdc4@localhost> Message-ID: <056.2580281539818898d5a18b57923e359c@localhost> #2405: Panic when using gtk2hs from ghci ----------------------+----------------------------------------------------- Reporter: wagstaff | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: This was already fixed by John Dias: {{{ Wed May 28 13:14:50 BST 2008 dias@eecs.harvard.edu * when linking, ignore unknown .reloc section that appeared in gcc 3.4.5(?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 08:49:16 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 08:49:20 2008 Subject: [GHC] #2408: threadWaitRead on mingw32 threaded causes internal error In-Reply-To: <044.646a5d9cf31ef2594dbfe492fec77132@localhost> References: <044.646a5d9cf31ef2594dbfe492fec77132@localhost> Message-ID: <053.9a4e5585fdb686f4f970f9282d5d2af5@localhost> #2408: threadWaitRead on mingw32 threaded causes internal error ----------------------------+----------------------------------------------- Reporter: kirby | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: `threadWaitRead` now partially works on Windows. To use it on anything other than `stdin`, you'll need `-threaded` (otherwise you'll get an error saying as much). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 10:07:42 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 10:07:50 2008 Subject: [GHC] #2375: RTS assertion failure on Vista with -DEBUG In-Reply-To: <043.34dc15d41b49327b2a6587cf172331a9@localhost> References: <043.34dc15d41b49327b2a6587cf172331a9@localhost> Message-ID: <052.2c04e1157e35e7e2779d49b762cd6f2a@localhost> #2375: RTS assertion failure on Vista with -DEBUG -----------------------------------------------+---------------------------- Reporter: dias | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: rts -DEBUG hashtables memory leak | Difficulty: Unknown Testcase: ghci/prog002 | Architecture: x86 Os: Windows | -----------------------------------------------+---------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Wed Jul 30 11:12:52 BST 2008 Simon Marlow * FIX #2375: remove oc->lochash completely, it apparently isn't used }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 10:08:49 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 10:09:01 2008 Subject: [GHC] #2388: GHC creates invalid test instruction for 64-bit code In-Reply-To: <056.33dc1f03d68892257923e7c03147f8f1@localhost> References: <056.33dc1f03d68892257923e7c03147f8f1@localhost> Message-ID: <065.70c671e451039c078daf446a8130765f@localhost> #2388: GHC creates invalid test instruction for 64-bit code -------------------------------+-------------------------------------------- Reporter: MartinGrabmueller | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Wed Jul 30 11:52:31 BST 2008 Simon Marlow * FIX #2388: check that the operand fits before using the 'test' opcode }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 10:10:15 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 10:10:29 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.4910c1d406eb4678582574dd1ccf0eae@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: GHCi | Version: 6.9 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed, and I also mailed the upstream author. {{{ Wed Jul 30 14:59:18 BST 2008 Simon Marlow * workaround #2277: turn off the RTS timer when calling into editline }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 10:11:33 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 10:11:36 2008 Subject: [GHC] #2376: GHC.Word: shiftR and shiftL are not marked as inline. In-Reply-To: <044.1d775a18fce526f6afc014f2bd5a4272@localhost> References: <044.1d775a18fce526f6afc014f2bd5a4272@localhost> Message-ID: <053.9a04fa0d690c8f73498bc807c5f2b140@localhost> #2376: GHC.Word: shiftR and shiftL are not marked as inline. ----------------------------------+----------------------------------------- Reporter: mjark | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: inline shiftR shiftL | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Wed Jul 30 11:35:39 BST 2008 Simon Marlow * FIX #2376: inline shiftR Duplicating the default definition for shiftR doesn't seem quite right to me, but it gets the right results when compiling the example program, and I couldn't find a better way to do it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 14:57:50 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 14:57:53 2008 Subject: [GHC] #2473: Data.Array.IO.Internals hidden in GHC6.8 for no good reason Message-ID: <044.3c74e42a68ae62a3562b4a333f1234f6@localhost> #2473: Data.Array.IO.Internals hidden in GHC6.8 for no good reason ------------------------+--------------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- I had some fast array modification code in C to modify the contents of an IOUArray, because I couldn't get my Haskell performance up to snuff. Now that module is hidden in the array package and it doesn't seem possible to unhide it. The code compiled & worked quite well in GHC6.6. I understand that by going into the internals I may have to update the code as the internals change, but it doesn't seem to be possible to do so at all at this point. The only workaround I can think of is to figure out the internal type from the source, re-declare it locally, and use unsafeCoerce# shenanigans to extract the data. That seems terrible, since future changes to the internals could cause the code to start crashing without any compile-time warning at all. Bitmap.hs: {{{ {-# OPTIONS_GHC -fffi -fglasgow-exts #-} {-# INCLUDE "bitmap_operations.h" #-} module Bitmap(clearBitmap) where import Data.Array.Base import Data.Array.IO.Internals import GHC.Exts import Data.Word foreign import ccall unsafe clear_bitmap :: MutableByteArray# RealWorld -> Word32 -> Word32 -> IO () {-# INLINE unsafeGetMutableArray# #-} unsafeGetMutableArray# :: IOUArray Int Word32 -> MutableByteArray# RealWorld unsafeGetMutableArray# (IOUArray (STUArray _ _ array#)) = array# clearBitmap :: IOUArray Int Word32 -> Word32 -> Word32 -> IO () clearBitmap a c sz = clear_bitmap (unsafeGetMutableArray# a) c sz }}} bitmap_operations.h: {{{ #include "HsFFI.h" void clear_bitmap(void* p, HsWord32 color, HsWord32 size); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 30 18:53:29 2008 From: trac at galois.com (GHC) Date: Wed Jul 30 18:53:33 2008 Subject: [GHC] #2474: II belive that in ISO8601 the date and time should be separated by a 'T', not a space Message-ID: <053.c50e53ab3abbd63ccd001b113f15157f@localhost> #2474: II belive that in ISO8601 the date and time should be separated by a 'T', not a space -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Based on http://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations I believe the implementation ought to be changed to {{{ iso8601DateFormat :: Maybe String -> String iso8601DateFormat timeFmt = "%Y-%m-%d" ++ case timeFmt of Nothing -> "" Just fmt -> 'T' : fmt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 31 00:05:11 2008 From: trac at galois.com (GHC) Date: Thu Jul 31 00:05:12 2008 Subject: [GHC] #2401: unsafeIOToSTM discards exception handlers. In-Reply-To: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> References: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> Message-ID: <052.e28e0b03748e92e7d15f892ba805c02b@localhost> #2401: unsafeIOToSTM discards exception handlers. ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by sclv): * severity: major => normal * summary: unsafeIOToSTM hangs with 64 bit multicore. => unsafeIOToSTM discards exception handlers. Comment: (changing the ticket name to reflect the real issue) I'm not happy with this for a number of reasons. Primarily because I imagine the same effect could be achieved if, e.g., STM was operating on an ostensibly pure data structure that hid an exception handler inside via, e.g., unsafeInterleaveIO. I'll think more about when/how this could come up using, e.g., only the standard libs, but I'm fairly sure I can manufacture a case. Second, I think unsafeIOToSTM should be as well supported as unsafePerformIO in that one can break invariants with it if one is not careful, but that it can be used "properly" to introduce new and useful features. As it stands, unsafeIOToSTM with this issue is too unsafe to be used even for debugging, much less for any real code. Finally, because the semantics of STM as described in the papers don't run into this problem, as the mechanism there only checks for consistency on transaction commits, not at other arbitrary intervals as well (i.e. on GC). I tend to think that, although it obviously requires discussion, throwing a real exception would make sense, especially since atomic rollback uses the same stack unwinding mechanism in any case, as I understand it. But, at a minimum, what would be nice is an RTS flag that disables the consistency check on GC, and thus sidesteps this whole issue. Furthermore, since there's a cost-benefit tradeoff to this check in any case, it would be nice to let users tweak that setting and play with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 31 00:26:01 2008 From: trac at galois.com (GHC) Date: Thu Jul 31 00:26:02 2008 Subject: [GHC] #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. In-Reply-To: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> References: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> Message-ID: <052.c8806c8d326ff9d82a9ef696a9ea8bff@localhost> #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by sclv): Attaching a very simplified testcase that strips out the typeclass nonsense. It looks to me like catchSTM is almost just plain hopeless. I can't piece through everything, but I note that it starts a nested transaction, while raiseAsync asserts that there is no enclosing transaction on a rollback. So, I could well be misunderstanding this, but it looks like that may be the issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 31 02:39:54 2008 From: trac at galois.com (GHC) Date: Thu Jul 31 02:39:54 2008 Subject: [GHC] #2270: gcd is specialised only for Int In-Reply-To: <043.b1b4c47bccdeb536ea28564b64a56127@localhost> References: <043.b1b4c47bccdeb536ea28564b64a56127@localhost> Message-ID: <052.07890991037beb520cbbd29d4cb904c4@localhost> #2270: gcd is specialised only for Int ---------------------------------------------+------------------------------ Reporter: dons | Owner: dons@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: rules, performance, double, gcd | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------------------+------------------------------ Changes (by guest): * keywords: => rules, performance, double, gcd * cc: rules, performance, double, gcd (removed) * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 31 02:50:47 2008 From: trac at galois.com (GHC) Date: Thu Jul 31 02:50:47 2008 Subject: [GHC] #311: gmp's memory management In-Reply-To: <043.f6cbfda45c43862fefdcb63df98df61f@localhost> References: <043.f6cbfda45c43862fefdcb63df98df61f@localhost> Message-ID: <052.eb84d530437d1812255bc499c9364d66@localhost> #311: gmp's memory management ----------------------------+----------------------------------------------- Reporter: as49 | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler (FFI) | Version: 6.4 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by guest): * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 31 10:56:26 2008 From: trac at galois.com (GHC) Date: Thu Jul 31 10:56:26 2008 Subject: [GHC] #2463: unsafePerformIO in unused record field affects optimisations In-Reply-To: <044.c6c9ce581b0819e0d3e27b236eaad365@localhost> References: <044.c6c9ce581b0819e0d3e27b236eaad365@localhost> Message-ID: <053.565f53ef7466a3cdf8853cdc4c285a52@localhost> #2463: unsafePerformIO in unused record field affects optimisations -----------------------------------------+---------------------------------- Reporter: claus | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- Changes (by claus): * status: new => closed * resolution: => invalid Comment: Going through the output of `-ddump-simpl`, it appears that just mentioning `unsafePerformIO` in the slow version instead of `undefined` in the fast version is sufficient to prevent a worker/wrapper split for `mkQ`. Adding an `{-# INLINE mkQ #-}` pragma makes the "slow" version as fast as the "fast" one. GHC can't really see that the record field is unused, but it can see that `undefined` is a lot smaller than anything else, so this is probably not a bug, just unexpected behaviour (I used `undefined` as a placeholder, not as a blackhole that would swallow its context; will have to use something else next time;-). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 31 16:25:15 2008 From: trac at galois.com (GHC) Date: Thu Jul 31 16:25:12 2008 Subject: [GHC] #2401: unsafeIOToSTM discards exception handlers. In-Reply-To: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> References: <043.102536ca2a3e567cb6677ad0a9004c1b@localhost> Message-ID: <052.43d9d4d445ad7f33d61fadd6b7c5e825@localhost> #2401: unsafeIOToSTM discards exception handlers. ----------------------------+----------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by sclv): It also occurs to me that there's an easier general solution that throwing retry as a real exception -- a flag could be introduced somewhat like block, except called, e.g., blockRetry, of type STM a -> STM a. Semantics would generally be the same as with block. blockRetry could wrap every call to unsafeIOToSTM, for example, and might prove useful elsewhere in user-generated code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 31 17:05:02 2008 From: trac at galois.com (GHC) Date: Thu Jul 31 17:05:02 2008 Subject: [GHC] #2475: debugger gives "Can't unify" when stopped at an exception Message-ID: <044.67056a89ea8901dff63b307a4127f5ba@localhost> #2475: debugger gives "Can't unify" when stopped at an exception ------------------------+--------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: break011, break024 Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Presumably due to exceptions now using existential types, the GHCi debugger now gives: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.9.20080731 for x86_64-unknown-linux): Can't unify Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} when it stops at an exception. See `break011` and `break024` for testcases. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 31 17:11:25 2008 From: trac at galois.com (GHC) Date: Thu Jul 31 17:11:42 2008 Subject: [GHC] #1997: Stricter enumFrom instance for Integer, to match Int In-Reply-To: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost> References: <043.bda0d5ecfd811d8fda5e74a0019c2fae@localhost> Message-ID: <052.110743ecc1d89551f7fccfbfeaab5f8d@localhost> #1997: Stricter enumFrom instance for Integer, to match Int -----------------------------------+---------------------------------------- Reporter: dons | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: lib/should_run/enum04 | Architecture: Multiple Os: Multiple | -----------------------------------+---------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks guys; I've applied Bart's patch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 31 23:29:38 2008 From: trac at galois.com (GHC) Date: Thu Jul 31 23:29:35 2008 Subject: [GHC] #2476: internal error: awaitEvent: descriptor out of range Message-ID: <046.98b2024ece2c4d6cefc902a4a054a14b@localhost> #2476: internal error: awaitEvent: descriptor out of range ------------------------+--------------------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: ia64 | Os: FreeBSD ------------------------+--------------------------------------------------- My program reports: Server3s.exe: internal error: awaitEvent: descriptor out of range (GHC version 6.8.2 for x86_64_unknown_freebsd) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 (core dumped) The core dump shows: (gdb) where #0 0x0000000800956dec in kill () from /lib/libc.so.7 #1 0x0000000800955c5b in abort () from /lib/libc.so.7 #2 0x00000000004e5bcd in rtsFatalInternalErrorFn () #3 0x00000000004e58bc in barf () #4 0x00000000004ea57d in awaitEvent () #5 0x00000000004e6d85 in scheduleWaitThread () #6 0x00000000004e42a9 in real_main () #7 0x00000000004e4398 in main () My host is: FreeBSD hpsux 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat Mar 8 14:07:11 HST 2008 root@hpsux:/usr/obj/usr/src/sys/GENERIC amd64 The full sources that are causing this issue are attached. To reproduce: run "make" then in one window run "./Server3s.exe" and in another window run "./DummyClient3s.exe". I get the crash in the Server3s program after it runs for a while. I can provide built binaries and a core dump if it is helpful. I didn't include them yet because they are large. -- Ticket URL: GHC The Glasgow Haskell Compiler