From trac at galois.com Tue May 1 04:01:03 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1315: System.Process.runInteractiveProcess needs a way to pipe just some handles Message-ID: <071.4b32df2577efc4bbcc6e1324ab6b47fe@localhost> #1315: System.Process.runInteractiveProcess needs a way to pipe just some handles -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Moderate (1 day) | Os: Unknown Testcase: | Architecture: Unknown -------------------------------+-------------------------------------------- Currently `runInteractiveProcess` attaches pipes to all 3 standard handles. Sometimes it's necessary to attach pipes to a subset, and possibly pass in existing Handles for the others. For example this could be used to connect a sequence of processes together with pipes. Also see Distribution.Simple.Utils.rawSystemStdout. While we're here, we could add a more convenient popen-like API. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue May 1 04:24:09 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1292: -Wall doesn't include all warnings In-Reply-To: <071.7a7a06479d78e46d64a9d1d8402193c5@localhost> References: <071.7a7a06479d78e46d64a9d1d8402193c5@localhost> Message-ID: <080.0bddb366c5a66ff735e6644af5cfe55e@localhost> #1292: -Wall doesn't include all warnings -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * resolution: => fixed * status: reopened => closed Comment: Ok, I'm convinced. `-Wall` would be rather less useful if it really included all warnings. I've updated the documentation to match the current behaviour. I'm ambivalent about whether `-fwarn-monomorphism-restriction` should be in `-Wall`; Simon PJ believes it should be. That discussion can be moved to the mailing list, however. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From frederik at a5.repetae.net Tue May 1 14:45:32 2007 From: frederik at a5.repetae.net (Frederik Eaton) Date: Thu Jul 19 09:48:32 2007 Subject: groupBy Message-ID: <20070501184532.GC13011@a5.repetae.net> Hello, My copy of the library documentation says: groupBy :: (a -> a -> Bool) -> [a] -> [[a]] The groupBy function is the non-overloaded version of group. User-supplied comparison (replacing an Ord context) The function is assumed to define a total ordering. But group has an Eq context. I don't understand how an Ord context would even be used, or how the function argument of groupBy is meant to define a total ordering. Is this a typo? Frederik -- http://ofb.net/~frederik/ _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue May 1 18:09:19 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1316: add warning for local type signatures that use the same type variable names as outer type signatures Message-ID: <071.81a47e7677ab5bf6b84d6251ba4f9533@localhost> #1316: add warning for local type signatures that use the same type variable names as outer type signatures ------------------------------+--------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ------------------------------+--------------------------------------------- for a (poor) example, {{{ f :: a -> a f x = x where g :: a --this is (forall x. x) not the 'a' from f's type signature -- So, warn about this signature. g = undefined }}} Because it is likely to be confusing, as well as interfering with any possibility of the type variables being considered scoped by default. In fact, this may be a helpful/explanatory message in cases where there will also be a type error due to the type variables not actually being scoped. (although, detecting those cases particularly and giving a recommended solution for how to give such a type signature, would be a more difficult endeavor (what to recommend?)) -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue May 1 18:18:25 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1317: add warning for the Prelude being imported implicitly Message-ID: <071.cd9a0752b3d15704c0210a36ad475fb0@localhost> #1317: add warning for the Prelude being imported implicitly ------------------------------+--------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ------------------------------+--------------------------------------------- For those who don't like the implicit Prelude (but have an existing codebase to work with, or want to stay compatible with Haskell standards). The only ways to keep the warning from triggering, once enabled, are `-fno-implicit-prelude`/`LANGUAGE NoImplicitPrelude`, and/or at least one `import ... Prelude ...` line appearing in the module. Proposed flag name: -fwarn-implicit-prelude Proposed "on" status: not even on with -Wall, must be enabled explicitly -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue May 1 19:41:35 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1318: add warning for prefix negate operator and flag to replace it with negative numeric literals Message-ID: <071.d3fd8e0c9c3e7414b71b9ae7740c59ce@localhost> #1318: add warning for prefix negate operator and flag to replace it with negative numeric literals --------------------------------+------------------------------------------- Reporter: Isaac Dupree | Owner: Isaac Dupree Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------+------------------------------------------- This is tracking a few things relating to the notion that Haskell's single prefix operator, "`-`", should not exist and "`-1`" should parse as a single token anyway. See http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/11954 If there is a LANGUAGE option for this, what should it be called; and what should the ghc flags be called? Should turning off prefix negation and turning on negative numeric literals be separately controllable? This sort of question (exactly what should be implemented) is probably half the difficulty here. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue May 1 20:59:21 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1319: grammatical mistake in user's guide description of -fwarn-name-shadowing Message-ID: <071.0aa423477bb1f11ea1a09891900f50ba@localhost> #1319: grammatical mistake in user's guide description of -fwarn-name-shadowing ----------------------------+----------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.6.1 Severity: trivial | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown ----------------------------+----------------------------------------------- http://www.haskell.org/ghc/docs/latest/html/users_guide/options- sanity.html "Consequently, this option does will complain about cyclic recursive definitions." "does will" isn't quite right - I think it should just be "will" -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 03:30:12 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1320: FAQ item for running GHCi on WinXP x64 using DEP Message-ID: <071.8393d28defea044505a85f56f1e6181d@localhost> #1320: FAQ item for running GHCi on WinXP x64 using DEP ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: task | Status: new Priority: low | Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Keywords: DEP, XP, x64, amd64, windows Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Hi, I don't know if this is a bug or not, but here is what I have witnessed: In order to get ghci to run on Windows XP x64, I needed to add ghci.exe to the "data execution prevention" exception list. Before making this exception, running ghci.exe would pop open my debugger with an access violation. Data Execution Prevention restricts the OS from executing any code that has been marked in memory as 'data'. I presume that the interpreter is taking in some strings, doing some processing on that data; then treating it as executable code and trying to run it. That sounds like a reasonable thing to do, and I don't know if there is a way to prevent it from triggering DEP. If this isn't a bug, perhaps you will consider this exception as a FAQ entry. -- Chris Messer (c.s.messer@gmail.com) -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 04:38:13 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1321: GHCi stdout bug when base package is not optimised Message-ID: <071.0ca5be8eebf0c6b63853ce005142f5e5@localhost> #1321: GHCi stdout bug when base package is not optimised -----------------------+---------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- Reported by Igloo: The problem from a couple of weeks ago, where ghci's hFlush command seems to be flushing a different stdout to the one that expressions evaluated by ghci write to, happens with a "quickest" build: {{{ SRC_HC_OPTS = -H64m -Onot -fasm GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -Onot -fasm GhcLibHcOpts = -Onot -fasm GhcLibWays = SplitObjs = NO }}} but not if libraries are optimised: {{{ SRC_HC_OPTS = -H64m -Onot -fasm GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -Onot -fasm GhcLibHcOpts = -O -fasm GhcLibWays = SplitObjs = NO }}} ghci004 is an example of a failing test (no output is printed if libraries are not optimised). This seems completely illogical to me. I'd have expected such a bug would be caused by optimisation meaning stdout gets inlined somewhere or something. Very curious! -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Tue May 1 21:23:21 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1319: grammatical mistake in user's guide description of -fwarn-name-shadowing In-Reply-To: <071.0aa423477bb1f11ea1a09891900f50ba@localhost> References: <071.0aa423477bb1f11ea1a09891900f50ba@localhost> Message-ID: <080.2d0d6d086d14fdc427c23d4294a521ba@localhost> #1319: grammatical mistake in user's guide description of -fwarn-name-shadowing ------------------------------+--------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.6.1 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------------+--------------------------------------------- Changes (by chevalier@alum.wellesley.edu): * resolution: => fixed * status: new => closed Comment: Fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 05:48:31 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1320: FAQ item for running GHCi on WinXP x64 using DEP In-Reply-To: <071.8393d28defea044505a85f56f1e6181d@localhost> References: <071.8393d28defea044505a85f56f1e6181d@localhost> Message-ID: <080.1b579975db0d2ebf1594df551c08eac3@localhost> #1320: FAQ item for running GHCi on WinXP x64 using DEP ---------------------------------------------+------------------------------ Reporter: guest | Owner: Type: task | Status: closed Priority: low | Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: duplicate Keywords: DEP, XP, x64, amd64, windows | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86_64 (amd64) | ---------------------------------------------+------------------------------ Changes (by simonmar): * resolution: => duplicate * status: new => closed Comment: I'm assuming this is a duplicate of #885, which is fixed in 6.6.1. I'm also guessing that you marked the bug as 6.6.1 because that's the default, not that it actually happens on 6.6.1. If this is wrong and you still see the bug with 6.6.1, please re-open this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 06:00:42 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1317: add warning for the Prelude being imported implicitly In-Reply-To: <071.cd9a0752b3d15704c0210a36ad475fb0@localhost> References: <071.cd9a0752b3d15704c0210a36ad475fb0@localhost> Message-ID: <080.124c380b52a71e66d646760be864a4d7@localhost> #1317: add warning for the Prelude being imported implicitly --------------------------------+------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | --------------------------------+------------------------------------------- Comment (by simonpj): Seems plausible to me, and should be easy to implement, so feel free to submit a patch. The guidelines are here; http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions#Howtosubmitapatchforanewfeature. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 06:58:28 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1313: HEAD gives warnings about code that it generates itself In-Reply-To: <071.998a56eb72cb85387ea081c52d4da142@localhost> References: <071.998a56eb72cb85387ea081c52d4da142@localhost> Message-ID: <080.a83c241270403537c8732ad0db75bb18@localhost> #1313: HEAD gives warnings about code that it generates itself ----------------------------------------+----------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------------+----------------------------------- Changes (by simonpj): * resolution: => fixed * status: new => closed Comment: I believe I have fixed this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 06:59:41 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1306: GHC generates warning about internally generated functions In-Reply-To: <071.28221b9effeafafd79b12837c3763e2e@localhost> References: <071.28221b9effeafafd79b12837c3763e2e@localhost> Message-ID: <080.1da6683388d9c5130b70e0bbd04851c5@localhost> #1306: GHC generates warning about internally generated functions -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonpj): * resolution: => fixed * status: new => closed Comment: Dup of #1313 (well, to be fair, #1313 is dup of this). Anyway, it's fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 07:06:49 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1308: Type signature in warning is wrong In-Reply-To: <071.0613799b287df0fa83f790ccb543efae@localhost> References: <071.0613799b287df0fa83f790ccb543efae@localhost> Message-ID: <080.afd3b4b3fb8bde917ad93c91220f7b0c@localhost> #1308: Type signature in warning is wrong -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by simonpj): Not obviously. `autoChart` falls under the Dreaded Monomorphism Restriction, so its inferred type is ''not'' `forall t. Monad t => ...`. It's not obvious what to report here. I originally added a remark to highlight the MR point. Would that help? Something like: {{{ Warning: Definition but no type signature for `autoChart' Inferred type: autoChart :: t View NB: autoChart is monomorphic in type variable t }}} In Trac #1256 Isaac wants to omit the `forall` in the displayed inferred type; but that would mean there was no way to distinguish `autoChart :: t View` from `autoChard :: forall t. t View`, which is presumably the way Lennart read it. Advice welcome. The issue is what is most comprehensible; implementing it is probably easy! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 07:07:29 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1256: GHC warns about omitting type signatures; would be more helpful if it supplied inferred type signature In-Reply-To: <071.fb61c0b4bcdbb7bf95e7c9fae2e5260d@localhost> References: <071.fb61c0b4bcdbb7bf95e7c9fae2e5260d@localhost> Message-ID: <080.d0a1c688d72cac4a69585fae97bcece3@localhost> #1256: GHC warns about omitting type signatures; would be more helpful if it supplied inferred type signature --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: low | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | --------------------------------+------------------------------------------- Comment (by simonpj): See #1308 for why omitting the `forall` is far from a no-brainer. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 07:10:30 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <071.7152770e64791eb835214efc770da623@localhost> References: <071.7152770e64791eb835214efc770da623@localhost> Message-ID: <080.2972db9f9855864b89e627ad52875628@localhost> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request --------------------------------+------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | --------------------------------+------------------------------------------- Changes (by simonpj): * milestone: => _|_ * priority: normal => low * type: bug => feature request Comment: I can't see any reason this would be impossible in principle, but my brain is too small to figure out all the ramifications of dropping the "newtypes are always boxed" assumption that GHC currently makes. So for now I have simply added the restriction to the user manual, and I'll leave this suggestion as a feature request. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 07:49:02 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1310: confusing error message when trying to give a type-signature to an imported symbol In-Reply-To: <071.20d04f59359a88d5b605a8aab9526f75@localhost> References: <071.20d04f59359a88d5b605a8aab9526f75@localhost> Message-ID: <080.c5422683f21b03e4f5e6f6787ef8053a@localhost> #1310: confusing error message when trying to give a type-signature to an imported symbol -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * resolution: => fixed * status: new => closed Comment: Good point. I've improved the error messages. For imports: {{{ Foo.hs:4:11: Misplaced type signature: putStrLn :: String -> IO () You cannot give a type signature for an imported value }}} For locals: {{{ Foo.hs:4:11: Misplaced type signature: p :: String -> IO () The type signature must be given where `p' is declared }}} Thanks for the suggestion Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 12:40:38 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1204: Associated types don't work with record updates In-Reply-To: <071.85574ce27d86e977ae1fe211979cbdce@localhost> References: <071.85574ce27d86e977ae1fe211979cbdce@localhost> Message-ID: <080.ad90ea6041fcabe6bcc392320dbe24d3@localhost> #1204: Associated types don't work with record updates ----------------------------------------+----------------------------------- Reporter: nominolo@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Records.hs Architecture: Unknown | ----------------------------------------+----------------------------------- Changes (by simonpj): * resolution: => fixed * testcase: => Records.hs * status: new => closed Comment: Good bug repoort. I have finally found a moment to fix it. Should work now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Wed May 2 16:54:56 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1308: Type signature in warning is wrong In-Reply-To: <071.0613799b287df0fa83f790ccb543efae@localhost> References: <071.0613799b287df0fa83f790ccb543efae@localhost> Message-ID: <080.f1235c4ad9d9b4dc04d84257f97cc6e4@localhost> #1308: Type signature in warning is wrong -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by Isaac Dupree): Given inferred monomorphic type `Inferred type: autoChart :: t View`, I think it would be desirable to (additionally) report the type as if the M-R didn't apply, to be informative and in case this is the signature that the user wants to add. Also it would be helpful to report the actual type GHC decides upon (unless there's a type error?). I assume that GHC knows what 't' becomes after applying M-R. Now, is it useful to report `autoChart :: monomorphic t. t View`? As far as I know, it is easy to see what this could be, just based on the fully polymorphic type, especially if a specific example - the actual monomorphic type GHC has chosen - is shown as well. Hmm... is it even possible to pretend that one thing (e.g. `autochart`) is polymorphic (as suggested above), in the presence of other things falling under the monomorphism restriction? Or are there some cases where it still might not be clear what to report? -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu May 3 03:50:53 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1255: UNPACKing a !Foo with newtype Foo = (Ptr Foo) causes the impossible In-Reply-To: <071.3226609f26b0c4bb9c798a2f478f3863@localhost> References: <071.3226609f26b0c4bb9c798a2f478f3863@localhost> Message-ID: <080.d24ea122d9f26fbdc773e089f72b37c7@localhost> #1255: UNPACKing a !Foo with newtype Foo = (Ptr Foo) causes the impossible -----------------------------------------+---------------------------------- Reporter: rashakil | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.2 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: UNPACK unbox newtype Ptr | Difficulty: Unknown Os: Linux | Testcase: tc226 Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonpj): * resolution: => fixed * testcase: => tc226 * status: new => closed Comment: There is a palpable bug in here, which is already fixed in the HEAD. But I must have forgotten to transfer the change to the 6.6 branch. I've done so now, in case we ever release 6.6.2. Thanks for the report. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu May 3 09:09:29 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1322: gcc --make recompiles hs-boot files unncessarily Message-ID: <071.1f99d9e0109732ff2a7294300efd07c6@localhost> #1322: gcc --make recompiles hs-boot files unncessarily -----------------------+---------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------+---------------------------------------------------- `ghc --make` should not recompile unnecessarily. Yet every build of the base package (for exanple) says: {{{ Preprocessing library base-2.1... Building base-2.1... [ 2 of 166] Compiling GHC.Err[boot] ( GHC/Err.lhs-boot, nothing ) [ 4 of 166] Compiling GHC.Unicode[boot] ( GHC/Unicode.hs-boot, nothing ) [ 15 of 166] Compiling Data.Typeable[boot] ( Data/Typeable.hs-boot, nothing ) [ 23 of 166] Compiling Data.Dynamic[boot] ( Data/Dynamic.hs-boot, nothing ) [ 35 of 166] Compiling Foreign.Storable[boot] ( Foreign/Storable.hs-boot, nothing ) [ 40 of 166] Compiling GHC.TopHandler[boot] ( GHC/TopHandler.lhs-boot, nothing ) }}} There is something wrong with the compilation manager. It's more of an infelicity than a bug, but it's still unsatisfactory. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu May 3 10:36:29 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1323: crash when zipping two lists of the same length... Message-ID: <071.2d16d53cd539cb4a2feb5b41dc49a4f4@localhost> #1323: crash when zipping two lists of the same length... ------------------------------------+--------------------------------------- Reporter: matthew@wellquite.org | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86_64 (amd64) ------------------------------------+--------------------------------------- I've personally not checked this against 6.6.1, but "mauke" on #haskell says the same crash and same line number appears in the crash report. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 $ ghc -v --make Session.hs Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6 Using package config file: /usr/lib/ghc-6.6/package.conf hiding package hinstaller-2007.4.21 to avoid conflict with later version hinstaller-2007.4.24 wired-in package base mapped to base-2.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.0 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Session.hs Stable obj: [] Stable BCO: [] compile: input file Session.hs Created temporary directory: /tmp/ghc4588_0 *** Checking old interface for main:Main: [1 of 1] Compiling Main ( Session.hs, Session.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 379 *** Simplify: *** Deleting temp files: Deleting: /tmp/ghc4588_0/ghc4588_0.s Warning: deleting non-existent /tmp/ghc4588_0/ghc4588_0.s *** Deleting temp dirs: Deleting: /tmp/ghc4588_0 ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for x86_64-unknown-linux): Pattern match failure in do expression at simplCore/Simplify.lhs:1540:8-21 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Now as the comments in the source say, it works fine if you replace newtype with data, and I am aware that there are differences in what they do, though I can never quite remember the fine details. So it's quite possibly my fault, but an error message other than a GHC crash would be nicer! -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu May 3 13:12:58 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:32 2007 Subject: [GHC] #1324: threadDelay can't handle long times Message-ID: <071.e55bbb382c0b28e3e556d5750df944c6@localhost> #1324: threadDelay can't handle long times -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -----------------------------+---------------------------------------------- With (Control.Concurrent.threadDelay :: Int -> IO ()) and the parameter interpreted as microseconds, the longest delay time is some 35 minutes, which I find somewhat short. Of course it's possible to call threadDelay several times to implement longer delays, but I ask whether this is the interface we want to have. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu May 3 14:09:50 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1325: GHC 6.6.1 build fails from MacPorts 1.4.0 on MacOS 10.4.9, internal error "strange closure type" Message-ID: <071.a5dd74dcebd117e7f63bcb46477b37d8@localhost> #1325: GHC 6.6.1 build fails from MacPorts 1.4.0 on MacOS 10.4.9, internal error "strange closure type" ---------------------------------------------+------------------------------ Reporter: michael.j.fromberger@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: powerpc ---------------------------------------------+------------------------------ While attempting to build GHC 6.6.1 via [http://www.macports.org/ MacPorts], I received the following traceback. Apologies for the length of the transcript, but I'm not sure how much of it will be needed to diagnose the trouble. I'm not sure if this is a fault with GHC itself, or an interaction with MacPorts, though the message "ghc-6.4: internal error: evacuate: strange closure type 32782" led me to suspect the former. {{{ [Desktop] 14: sudo port install ghc ---> Fetching ghc ---> Attempting to fetch ghc-6.6.1-src.tar.bz2 from http://www.haskell.org/ghc/dist/6.6.1/ ---> Attempting to fetch ghc-6.6.1-src-extralibs.tar.bz2 from http://www.haskell.org/ghc/dist/6.6.1/ ---> Verifying checksum(s) for ghc ---> Extracting ghc ---> Applying patches to ghc ---> Configuring ghc ---> Building ghc with target all Error: Target com.apple.build returned: shell command "env DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib make all" returned error 2 Command output: /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c rename/RnBinds.lhs -o stage1/rename/RnBinds.o -ohi stage1/rename/RnBinds.hi <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c rename/RnSource.lhs -o stage1/rename/RnSource.o -ohi stage1/rename/RnSource.hi <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c rename/RnNames.lhs -o stage1/rename/RnNames.o -ohi stage1/rename/RnNames.hi <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c types/Generics.lhs -o stage1/types/Generics.o -ohi stage1/types/Generics.hi <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c typecheck/TcExpr.lhs-boot -o stage1/typecheck/TcExpr.o-boot -ohi stage1/typecheck/TcExpr.hi-boot <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c typecheck/TcEnv.lhs -o stage1/typecheck/TcEnv.o -ohi stage1/typecheck/TcEnv.hi <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c typecheck/Inst.lhs -o stage1/typecheck/Inst.o -ohi stage1/typecheck/Inst.hi <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c typecheck/TcUnify.lhs-boot -o stage1/typecheck/TcUnify.o-boot -ohi stage1/typecheck/TcUnify.hi-boot <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c typecheck/TcSimplify.lhs -o stage1/typecheck/TcSimplify.o -ohi stage1/typecheck/TcSimplify.hi <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c typecheck/TcUnify.lhs -o stage1/typecheck/TcUnify.o -ohi stage1/typecheck/TcUnify.hi <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c typecheck/TcHsType.lhs -o stage1/typecheck/TcHsType.o -ohi stage1/typecheck/TcHsType.hi <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c typecheck/TcMatches.lhs-boot -o stage1/typecheck/TcMatches.o-boot -ohi stage1/typecheck/TcMatches.hi-boot <> /opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_lang_ghc/work /ghc-bootstrap/bin/ghc -H16m -O -I/opt/local/include -I/usr/include -L/opt/local/lib -L/usr/lib -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -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 -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 -c typecheck/TcPat.lhs -o stage1/typecheck/TcPat.o -ohi stage1/typecheck/TcPat.hi ghc-6.4: internal error: evacuate: strange closure type 32782 Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ make[1]: *** [stage1/typecheck/TcPat.o] Error 254 make: *** [stage1] Error 1 Error: Status 1 encountered during processing. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu May 3 15:30:33 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1325: GHC 6.6.1 build fails from MacPorts 1.4.0 on MacOS 10.4.9, internal error "strange closure type" In-Reply-To: <071.a5dd74dcebd117e7f63bcb46477b37d8@localhost> References: <071.a5dd74dcebd117e7f63bcb46477b37d8@localhost> Message-ID: <080.ad81e485c7fd48213607f40db22d7ebb@localhost> #1325: GHC 6.6.1 build fails from MacPorts 1.4.0 on MacOS 10.4.9, internal error "strange closure type" -----------------------------------------------+---------------------------- Reporter: michael.j.fromberger@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: Architecture: powerpc | -----------------------------------------------+---------------------------- Changes (by simonmar): * resolution: => fixed * status: new => closed Comment: Looks like a bug in GHC 6.4, probably fixed long ago. Try upgrading to a later release (by downloading binaries), and then upgrading to 6.6.1. Or wait for 6.6.1 binaries for your platform. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu May 3 16:16:41 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1308: Type signature in warning is wrong In-Reply-To: <071.0613799b287df0fa83f790ccb543efae@localhost> References: <071.0613799b287df0fa83f790ccb543efae@localhost> Message-ID: <080.6c62711bd0a31778b20dbebda45a950b@localhost> #1308: Type signature in warning is wrong -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by guest): The NB note about the monomorphism restriction would be fine by me. But in fact, the type variable t is later fixed to a particular type because of how autoChart is used, so it's not really a variable. -- Lennart -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu May 3 20:49:03 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1326: Bindings for POSIX named semaphores and shared memory objects Message-ID: <071.37b2f3b9aa1620023de79cc1dcdd4c1b@localhost> #1326: Bindings for POSIX named semaphores and shared memory objects -----------------------------+---------------------------------------------- Reporter: dfranke | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Multiple Testcase: | Architecture: Multiple -----------------------------+---------------------------------------------- I've written a patch for libraries/unix adding support for POSIX named semaphores and shared memory objects. It's a straightforward wrapper around the POSIX system calls, basically just converting between C types and Haskell types and closing semaphores when they get garbage-collected. I don't plan to implement unnamed semaphores because Control.Concurrent already has perfectly good support for that. Named semaphores, on the other hand, are for IPC, and there's no other alternative if that's what the process on the other end is expecting. The patch is here: [http://www.haskell.org/pipermail/libraries/attachments/20070503/507f7e6c /attachment-0001.bin] -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 03:50:31 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1323: crash when zipping two lists of the same length... In-Reply-To: <071.2d16d53cd539cb4a2feb5b41dc49a4f4@localhost> References: <071.2d16d53cd539cb4a2feb5b41dc49a4f4@localhost> Message-ID: <080.0bf2bec32a1cfd79eb4f398ae7e635b1@localhost> #1323: crash when zipping two lists of the same length... --------------------------------------+------------------------------------- Reporter: matthew@wellquite.org | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Os: Linux | Testcase: Session.hs Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Changes (by simonpj): * resolution: => wontfix * testcase: => Session.hs * status: new => closed Old description: > I've personally not checked this against 6.6.1, but "mauke" on #haskell > says the same crash and same line number appears in the crash report. > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.6 > > $ ghc -v --make Session.hs > Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC > version 6.6 > Using package config file: /usr/lib/ghc-6.6/package.conf > hiding package hinstaller-2007.4.21 to avoid conflict with later version > hinstaller-2007.4.24 > wired-in package base mapped to base-2.0 > wired-in package rts mapped to rts-1.0 > wired-in package haskell98 mapped to haskell98-1.0 > wired-in package template-haskell mapped to template-haskell-2.0 > Hsc static flags: -static > *** Chasing dependencies: > Chasing modules from: Session.hs > Stable obj: [] > Stable BCO: [] > compile: input file Session.hs > Created temporary directory: /tmp/ghc4588_0 > *** Checking old interface for main:Main: > [1 of 1] Compiling Main ( Session.hs, Session.o ) > *** Parser: > *** Renamer/typechecker: > *** Desugar: > Result size = 379 > *** Simplify: > *** Deleting temp files: > Deleting: /tmp/ghc4588_0/ghc4588_0.s > Warning: deleting non-existent /tmp/ghc4588_0/ghc4588_0.s > *** Deleting temp dirs: > Deleting: /tmp/ghc4588_0 > ghc-6.6: panic! (the 'impossible' happened) > (GHC version 6.6 for x86_64-unknown-linux): > Pattern match failure in do expression at > simplCore/Simplify.lhs:1540:8-21 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Now as the comments in the source say, it works fine if you replace > newtype with data, and I am aware that there are differences in what they > do, though I can never quite remember the fine details. So it's quite > possibly my fault, but an error message other than a GHC crash would be > nicer! New description: I've personally not checked this against 6.6.1, but "mauke" on #haskell says the same crash and same line number appears in the crash report. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 $ ghc -v --make Session.hs Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6 Using package config file: /usr/lib/ghc-6.6/package.conf hiding package hinstaller-2007.4.21 to avoid conflict with later version hinstaller-2007.4.24 wired-in package base mapped to base-2.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.0 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Session.hs Stable obj: [] Stable BCO: [] compile: input file Session.hs Created temporary directory: /tmp/ghc4588_0 *** Checking old interface for main:Main: [1 of 1] Compiling Main ( Session.hs, Session.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 379 *** Simplify: *** Deleting temp files: Deleting: /tmp/ghc4588_0/ghc4588_0.s Warning: deleting non-existent /tmp/ghc4588_0/ghc4588_0.s *** Deleting temp dirs: Deleting: /tmp/ghc4588_0 ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for x86_64-unknown-linux): Pattern match failure in do expression at simplCore/Simplify.lhs:1540:8-21 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Now as the comments in the source say, it works fine if you replace newtype with data, and I am aware that there are differences in what they do, though I can never quite remember the fine details. So it's quite possibly my fault, but an error message other than a GHC crash would be nicer! Comment: Good one! What is happening is this. During optimisation, GHC removes impossible alternatives from a case expression. Your program has this: {{{ data List :: * -> * -> * where Nil :: List a Zero Cons :: (TyNum p) => a -> List a p -> List a (Succ p) }}} where `Succ` is a '''newtype'''. GHC 6.6 has a split personality about newtypes. During typechecking it regards a newtype T and its representation type as distinct. But during optimisation it regards them as the same. That's WRONG here, because it makes GHC stupidly remove a case alterantive that is not dead. All this works fine in the HEAD, which regards a newtype and its rep type as distinct throughout (much tidier). So I won't fix 6.6. Meanwhile you'd be better defining your Succ type like this: {{{ data Succ p }}} You aren't using it to carry data, and GHC allows you to define data types with no constructors. I'll add this to the test suite though! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 05:28:40 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1327: internal error: interpretBCO: unknown or unimplemented opcode 35464 Message-ID: <071.c043a03385576b83f08291bc9ece6850@localhost> #1327: internal error: interpretBCO: unknown or unimplemented opcode 35464 -------------------------------------+-------------------------------------- Reporter: gleb.alexeev@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown -------------------------------------+-------------------------------------- Steps to reproduce: 1. Load the following module into ghci: {{{ module Bug where import Test.QuickCheck data Color = Red | Yellow | Blue deriving (Eq, Show) complement :: Color -> Color -> Color complement c1 c2 = f (c1,c2) where f (Red, Yellow) = Blue f (Red, Blue) = Yellow f (Yellow, Blue) = Red f (x,y) = f (y,x) prop_complement c1 c2 = c1/=c2 ==> c3/=c1 && c3/=c2 where c3=complement c1 c2 instance Arbitrary Color where arbitrary = oneof $ map return [Red, Yellow, Blue] coarbitrary = undefined }}} 2. Evaluate 'quickCheck prop_complement' ghci crashes with the following output: {{{ *Bug> quickCheck prop_complement Loading package QuickCheck-1.0 ... linking ... done. : internal error: interpretBCO: unknown or unimplemented opcode 35464 (GHC version 6.6 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The problem disappears if complement function is invoked manually before calling quickCheck. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From maeder at tzi.de Fri May 4 05:31:06 2007 From: maeder at tzi.de (Christian Maeder) Date: Thu Jul 19 09:48:33 2007 Subject: make binary-dist for ghc-6.6.1 shows latex error Message-ID: <463AFD5A.1000204@tzi.de> When making a binary distribution from the official ghc-6.6.1 sources, I get the latex error below for core.tex. I have to skip this error by typing ^D (EOF) explicitly. (I did not find out how to fix this error on line 528 of core.tex, though) The final documentation lacks a core.ps file. But such a file is also missing in: http://www.haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-unknown-linux.tar.bz2 What should happen with core.tex? Cheers Christian Underfull \hbox (badness 10000) in paragraph at lines 511--528 ! You can't use `macro parameter character #' in horizontal mode. ...> b} \par {\tt par x y = case (par## x) of \_ -> lazy y} \par ... l.528 ...boxed type. }{\primoptions{}{}{}{}{}{}{}} ? ! Emergency stop. ...> b} \par {\tt par x y = case (par## x) of \_ -> lazy y} \par ... l.528 ...boxed type. }{\primoptions{}{}{}{}{}{}{}} Output written on core.dvi (34 pages, 104288 bytes). Transcript written on core.log. _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From simon at joyful.com Wed May 2 04:06:43 2007 From: simon at joyful.com (Simon Michael) Date: Thu Jul 19 09:48:33 2007 Subject: profiling tips suggestion Message-ID: <46384693.4020800@joyful.com> > Any comments, suggestions and/or improvements you have are welcome. Recommended ?profiling tricks? would be especially cool! Hi.. here's one, let me know if there's some other way I should send it. Emacs can help make .prof files much clearer. - set up hasktags and M-. so you can jump to any function from it's name - remove unnecessary columns - use macros to delete fields you don't need, such as Module, No., %alloc - use align-regexp to realign the numbers if your long function names have messed up the layout - convert the call graph to a folding, colour-coded outline: use a macro to replace leading spaces with stars and one space, M-x org mode, shift-tab to cycle between all expanded and all collapsed, tab to expand/collapse the current function. - use highlight-regexp and highlight-lines-matching-regexp to mark lines of interest, numbers above a certain threshold etc. Reduces mental work when you are flipping back and forth. Thanks for the glorious ghc! -Simon _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 06:07:58 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1268: GHCi reads from stdin do not handle ^D In-Reply-To: <071.87b69441b9871b26a1313586f406a98d@localhost> References: <071.87b69441b9871b26a1313586f406a98d@localhost> Message-ID: <080.14c688ed407f0a0092161db5801cf396@localhost> #1268: GHCi reads from stdin do not handle ^D -------------------------------------------------+-------------------------- Reporter: Stefan O'Rear | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------------------------------+-------------------------- Changes (by igloo): * component: Compiler => GHCi * milestone: => 6.8 Comment: Thanks for the report, we'll look into it for 6.8. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 06:24:19 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1270: STUArray and IOUArray lack an Eq instance In-Reply-To: <071.e9e63221a1cd00725c85393cbe256dfb@localhost> References: <071.e9e63221a1cd00725c85393cbe256dfb@localhost> Message-ID: <080.1d87479fd6a7b0aa48b495d662f50b69@localhost> #1270: STUArray and IOUArray lack an Eq instance -------------------------------------+-------------------------------------- Reporter: jcpetruzza@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * milestone: => 6.8 Comment: Good point, I can't think of any reason why IOUArray's shouldn't have an Eq instance if IOArrays have one. It would need to be added for hugs, and anything else that implements it, too. As an aside: For some reason `STArray` is defined in `GHC/Arr.lhs` but `STUArray` is defined in `Data/Array/Base.hs`. This seems a little odd! -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 06:31:46 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1272: newStdGen returns the same value on successive calls In-Reply-To: <071.4eae94e6b9e4773aed8f603d1cf9829c@localhost> References: <071.4eae94e6b9e4773aed8f603d1cf9829c@localhost> Message-ID: <080.f37469cb6a893d995e73efc0df549ec7@localhost> #1272: newStdGen returns the same value on successive calls -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * component: Compiler => libraries/base * milestone: => 6.8 Old description: > It seems newStdGen only depends on the second, it should have better > resolution and/or use /dev/random. > > Test program: > > import Random > main = newStdGen >>= print > > compiled with ghc 6.6 or 6.7 (at some point in time) > Running "date; ./random" gives: > > Thu Apr 12 10:51:54 CEST 2007 > 1938403181 6764 > Thu Apr 12 10:51:54 CEST 2007 > 1938403181 6764 > Thu Apr 12 10:51:55 CEST 2007 > 529729936 6762 > Thu Apr 12 10:51:55 CEST 2007 > 529729936 6762 > Thu Apr 12 10:51:56 CEST 2007 > 1023702766 6762 > Thu Apr 12 10:51:56 CEST 2007 > 1023702766 6762 > Thu Apr 12 10:52:03 CEST 2007 > 186545450 6762 > Thu Apr 12 10:52:04 CEST 2007 > 680518280 6762 > Thu Apr 12 10:52:04 CEST 2007 > 680518280 6762 New description: It seems newStdGen only depends on the second, it should have better resolution and/or use /dev/random. Test program: {{{ import Random main = newStdGen >>= print }}} compiled with ghc 6.6 or 6.7 (at some point in time) Running "date; ./random" gives: {{{ Thu Apr 12 10:51:54 CEST 2007 1938403181 6764 Thu Apr 12 10:51:54 CEST 2007 1938403181 6764 Thu Apr 12 10:51:55 CEST 2007 529729936 6762 Thu Apr 12 10:51:55 CEST 2007 529729936 6762 Thu Apr 12 10:51:56 CEST 2007 1023702766 6762 Thu Apr 12 10:51:56 CEST 2007 1023702766 6762 Thu Apr 12 10:52:03 CEST 2007 186545450 6762 Thu Apr 12 10:52:04 CEST 2007 680518280 6762 Thu Apr 12 10:52:04 CEST 2007 680518280 6762 }}} Comment: I see no reason not to use the second component of TOD; it doesn't need a type conversion or anything, and even if it is very low precision it won't hurt to include it. We have a small collection of Random bugs accumulating! Hopefully someone will be able to give the library the once-over for 6.8. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 06:52:22 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1327: internal error: interpretBCO: unknown or unimplemented opcode 35464 In-Reply-To: <071.c043a03385576b83f08291bc9ece6850@localhost> References: <071.c043a03385576b83f08291bc9ece6850@localhost> Message-ID: <080.e815af8c6c19d3b65992c3569458c5d0@localhost> #1327: internal error: interpretBCO: unknown or unimplemented opcode 35464 ---------------------------------------+------------------------------------ Reporter: gleb.alexeev@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ---------------------------------------+------------------------------------ Changes (by thorkilnaur): * resolution: => duplicate * status: new => closed Comment: Thanks a lot for this report. It seems that this is a duplicate of #1013, so I will take the liberty of closing this ticket. For additional details, see http://www.haskell.org/pipermail/glasgow-haskell-bugs/2007- March/008800.html: The error is present in GHC 6.6, but should be fixed in GHC 6.6.1. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 06:54:58 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1279: System.Posix.User.getAllUserEntries should call setpwent In-Reply-To: <071.3b393fb5c891c7dc8e58b0b138444505@localhost> References: <071.3b393fb5c891c7dc8e58b0b138444505@localhost> Message-ID: <080.30e727f8bd66fd05bc4540dfa197a7f9@localhost> #1279: System.Posix.User.getAllUserEntries should call setpwent -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/unix | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Thanks for the patch, now applied! -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 06:58:24 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1281: runghc, runhaskell invoke wrong ghc when not first ghc in PATH In-Reply-To: <071.62122ece11e8eaff957b2a7e980315ca@localhost> References: <071.62122ece11e8eaff957b2a7e980315ca@localhost> Message-ID: <080.15839f24aecedb5df3378cea44704fc3@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.8 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.8 Comment: This is the intended behaviour, but a number of people have been confused by it now. Any objections to changing runghc to run the GHC it is part of? -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 07:20:45 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! In-Reply-To: <071.c9798f94449c1b259d1392fba1df791b@localhost> References: <071.c9798f94449c1b259d1392fba1df791b@localhost> Message-ID: <080.6b90047920b6df23be8a8af777c83a03@localhost> #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! ----------------------------------------------------+----------------------- Reporter: jvlask@hotmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: GHCi | Version: 6.6 Severity: critical | Resolution: Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Os: Windows | Testcase: Architecture: x86 | ----------------------------------------------------+----------------------- Changes (by igloo): * milestone: => 6.8 Comment: Thanks for the (very detailed!) report. We'll look into it for 6.8. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 07:29:38 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1285: panic in HEAD building base library In-Reply-To: <071.1091d8c6cd8fa616503f28ccaca8ad5d@localhost> References: <071.1091d8c6cd8fa616503f28ccaca8ad5d@localhost> Message-ID: <080.6dc08cb59fc6394b9bf56fc0b74712e4@localhost> #1285: panic in HEAD building base library -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * architecture: powerpc => Multiple * milestone: => 6.8 Comment: Thanks for the report; also happens for me on Linux/amd64. The failing assertion is this one: {{{ lookupBinding :: IdEnv HowBound -> Id -> HowBound lookupBinding env v = case lookupVarEnv env v of Just xx -> xx Nothing -> ASSERT2( isGlobalId v, ppr v ) ImportBound }}} The references to `eqString` are: {{{ eqString :: String -> String -> Bool eqString [] [] = True eqString (c1:cs1) (c2:cs2) = c1 == c2 && cs1 `eqString` cs2 eqString cs1 cs2 = False {-# RULES "eqString" (==) = eqString #-} -- eqString also has a BuiltInRule in PrelRules.lhs: -- eqString (unpackCString# (Lit s1)) (unpackCString# (Lit s2) = s1==s2 }}} and it's got a wired-in unique. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 07:37:20 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1251: GADTs with newtype deriving can crash GHCi / cause Core Lint to fail In-Reply-To: <071.12e6c8e84b5a6b247536eeb9ad245ec9@localhost> References: <071.12e6c8e84b5a6b247536eeb9ad245ec9@localhost> Message-ID: <080.18f427022999d22e12be84f0055657ef@localhost> #1251: GADTs with newtype deriving can crash GHCi / cause Core Lint to fail -------------------------------------------------+-------------------------- Reporter: Stefan O'Rear | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.2 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Linux | Testcase: gadt/CasePrune Architecture: x86 | -------------------------------------------------+-------------------------- Changes (by simonpj): * resolution: => fixed * testcase: => gadt/CasePrune * status: new => closed Comment: Interesting bug. Turns out that GHC's optimiser was being to eager about eliminating dead case branches. I've added a long comment to Unify.lhs, reproduced below. Meanwhile, the bug is fixed in HEAD; won't be fixed in 6.6 Meanwhile, you are not justified in assuming that there is no non-bottom value of type (II A). You can't construct one in normal Haskell, but you can with newtype-deriving as you showed, and (more generally) you can in GHC's intermediate lanuage FC. Use a data type you really want to be sure. Thank you for a nice example. newtype deriving is more powerful than I thought! Simon {{{ Note [Pruning dead case alternatives] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider data T a where T1 :: T Int T2 :: T a newtype X = MkX Int newtype Y = MkY Char type family F a type instance F Bool = Int Now consider case x of { T1 -> e1; T2 -> e2 } The question before the house is this: if I know something about the type of x, can I prune away the T1 alternative? Suppose x::T Char. It's impossible to construct a (T Char) using T1, Answer = YES (clearly) Suppose x::T (F a), where 'a' is in scope. Then 'a' might be instantiated to 'Bool', in which case x::T Int, so ANSWER = NO (clearly) Suppose x::T X. Then *in Haskell* it's impossible to construct a (non- bottom) value of type (T X) using T1. But *in FC* it's quite possible. The newtype gives a coercion CoX :: X ~ Int So (T CoX) :: T X ~ T Int; hence (T1 `cast` sym (T CoX)) is a non-bottom value of type (T X) constructed with T1. Hence ANSWER = NO (surprisingly) Furthermore, this can even happen; see Trac #1251. GHC's newtype-deriving mechanism uses a cast, just as above, to move from one dictionary to another, in effect giving the programmer access to CoX. Finally, suppose x::T Y. Then *even in FC* we can't construct a non-bottom value of type (T Y) using T1. That's because we can get from Y to Char, but not to Int. Here's a related question. data Eq a b where EQ :: Eq a a Consider case x of { EQ -> ... } Suppose x::Eq Int Char. Is the alternative dead? Clearly yes. What about x::Eq Int a, in a context where we have evidence that a~Char. Then again the alternative is dead. Summary We are really doing a test for unsatisfiability of the type constraints implied by the match. And that is clearly, in general, a hard thing to do. However, since we are simply dropping dead code, a conservative test suffices. There is a continuum of tests, ranging from easy to hard, that drop more and more dead code. For now we implement a very simple test: type variables match anything, type functions (incl newtypes) match anything, and only distinct data types fail to match. We can elaborate later. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 07:56:34 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1289: gcc error when building haddock with gcc 4.1.2: initializer element is not constant In-Reply-To: <071.919ebb74ae310e2aa5a8ac4698b1995a@localhost> References: <071.919ebb74ae310e2aa5a8ac4698b1995a@localhost> Message-ID: <080.a4dfb6f5b0f09e10f5423ec2a21b7728@localhost> #1289: gcc error when building haddock with gcc 4.1.2: initializer element is not constant -------------------------------+-------------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.4.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: With {{{ The Glorious Glasgow Haskell Compilation System, version 6.6 }}} and {{{ gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) Copyright (C) 2006 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. }}} trying to build haddock gets past this point, so I think this is just an older ghc not being able to cope with newer gccs. I suggest upgrading to ghc 6.6.1 and then you can build haddock 0.8 with that. You won't be able to haddock the libraries until after you've done so, of course, but that isn't necessary to get a working compiler. If you have a similar problem trying to build ghc itself then try either an OS-specific package or the generic Linux binary distribution, for either 6.6 or 6.6.1. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 07:57:41 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1290: ghc runs preprocessor too much In-Reply-To: <071.385e15331165a460fec252648dac573b@localhost> References: <071.385e15331165a460fec252648dac573b@localhost> Message-ID: <080.e797b5154d249d031b07a022c1e91d38@localhost> #1290: ghc runs preprocessor too much ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Driver | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ------------------------+--------------------------------------------------- Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 08:10:17 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1291: Binary Solaris build fails on Solaris 9 In-Reply-To: <071.dd0107a672dea3b323a9a504f5f0b96d@localhost> References: <071.dd0107a672dea3b323a9a504f5f0b96d@localhost> Message-ID: <080.672e8a3f4483aebd300004bbe4b3a610@localhost> #1291: Binary Solaris build fails on Solaris 9 -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Solaris | Testcase: Architecture: sparc | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => _|_ Comment: I'm not a Solaris expert, but http://www.neowin.net/forum/lofiversion/index.php/t378930.html recommends http://www.blastwave.org/. I know nothing about either site, though. If the existing binaries can't be made to work on Solaris 9 then you'll have to follow the porting process, but that would probably be more work. If you do have to do so, then using a Solaris 10 box as the host would probably be simplest, if you have access to one. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 08:14:23 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1293: building ghc 6.6.1 hangs on linux-x86 at Language/Haskell/Syntax.hs In-Reply-To: <071.c4e6c8d60dabe52900e2c03718f5b893@localhost> References: <071.c4e6c8d60dabe52900e2c03718f5b893@localhost> Message-ID: <080.12ef5920abaf4dc1c4bcd5d8e7ef31c7@localhost> #1293: building ghc 6.6.1 hangs on linux-x86 at Language/Haskell/Syntax.hs ----------------------------------+----------------------------------------- Reporter: mm | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: blocker | Resolution: Keywords: hangs compilation | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: => 6.8 Comment: Are you sure it's hung? That file will take a comparatively long time to compile, especially as it's being compiled for profiling. If you are low on memory then it is also likely that that file is causing your machine to swap, and thus taking even longer. What does the output of `free` and `top -n 1` look like when it has hung? -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 08:28:37 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1285: panic in HEAD building base library In-Reply-To: <071.1091d8c6cd8fa616503f28ccaca8ad5d@localhost> References: <071.1091d8c6cd8fa616503f28ccaca8ad5d@localhost> Message-ID: <080.85c56142fd7cd7189113d0a7a9890ac3@localhost> #1285: panic in HEAD building base library -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Linux | Testcase: Compile base with -O0 Architecture: Multiple | -----------------------------+---------------------------------------------- Changes (by simonpj): * resolution: => fixed * testcase: => Compile base with -O0 * status: new => closed Comment: The crash was caused by the eqString rewrite rule creating a '''forward''' reference to GHC.Base.eqString. It's all very specific to the (exactly three) BuiltIn rules. It's also specific to -O0, becuase with -O we do an occasional "`GlomBinds`" to re-do the mutual dependencies. In fact I was surprised to see that RULES fire at all with -O0. I've committed a patch to make `-frewrite-rules` into a dynamic flag, off with -O0 and on with -O. That fixes the crash, so I'm closing this bug. Thanks for pointing it out. Simon PS: there are a few other warnings in compiling the base package, but they are harmless. I think. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 08:49:05 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1297: No LANGUAGE option for # in symbols In-Reply-To: <071.32209f26c6c81b9efad7ddf1ef068724@localhost> References: <071.32209f26c6c81b9efad7ddf1ef068724@localhost> Message-ID: <080.b229cf6e2ed673a995b1c1ac7a1529aa@localhost> #1297: No LANGUAGE option for # in symbols -------------------------+-------------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.8 Comment: I think something like MagicHash would be a better name than Unboxed, as the actual extension is that # can count as either a letter or a symbol. Who's meant to decide these things? -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From Malcolm.Wallace at cs.york.ac.uk Fri May 4 08:43:38 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Jul 19 09:48:33 2007 Subject: Build failures on Mac OS X 10.5 In-Reply-To: References: Message-ID: <20070504134338.57abf515.Malcolm.Wallace@cs.york.ac.uk> Deborah Goldsmith wrote: > /tmp/ghc78351_0/ghc78351_0.split__108.s:unknown: > Undefined local symbol L_strerror$UNIX2003$stub The standard unix symbol 'strerror' is imported by the base package from module Foreign/C/Error.hs like this: foreign import ccall unsafe "string.h" strerror :: Errno -> IO (Ptr CChar) The corresponding prototype for 'strerror' in /usr/include/string.h on MacOS 10.4.9 is: char *strerror(int); Which all looks like it matces up OK. I presume that in MacOS 10.5, something in this area has changed to do with localisation, or internationalisation. Perhaps 'strerror' is no longer implemented as a function, but as a cpp macro. Perhaps 'strerror' is no longer physically located in libc.dylib. Perhaps there are now conditional sections around 'strerror' which mean that we need to set a pre-processing symbol to select the appropriate version of the prototype. Can you give us any snippets from the Leopard version of /usr/include/string.h that might confirm one of these hypotheses? > I can't divulge any confidential information about Leopard but I did > get an OK to work with you folks to try to isolate the cause of this > problem. If it's on our side we'd like to fix it, and if it's on your > side we'd like to help you be ready for Leopard. Thanks for making contact. Can you tell us any more about why Apple is starting to find Haskell of sufficient interest to try to solve these issues? Regards, Malcolm _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 09:06:20 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1301: make install does more than that In-Reply-To: <071.81a4bf4a344d6e26f90d33f17df2805f@localhost> References: <071.81a4bf4a344d6e26f90d33f17df2805f@localhost> Message-ID: <080.8f8ec8171cbfee9572ce890ac6f8a964@localhost> #1301: make install does more than that -------------------------+-------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.8 * owner: => igloo Comment: We run configure on install because we need to tell cabal to (for example) use the ghc-pkg that will be installed, rather than the one is used in- place while building the other libraries and the stage2 compiler. I do intend to look at reducing the amount of work that this second configure run does, though. I haven't seen it hang before. I'll see if I can reproduce it. Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 09:21:14 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1304: Make install fails In-Reply-To: <071.47c88eb287150bd13221028ae281e6c7@localhost> References: <071.47c88eb287150bd13221028ae281e6c7@localhost> Message-ID: <080.c9020a750f4b46468059a7c2582859f4@localhost> #1304: Make install fails -----------------------------+---------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Build System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * component: Compiler => Build System * milestone: => 6.8 * owner: => igloo Comment: Hmm, this certainly worked at one point, but I'm not sure how the directory got created. I'll look into it. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 09:34:44 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:33 2007 Subject: [GHC] #1308: Type signature in warning is wrong In-Reply-To: <071.0613799b287df0fa83f790ccb543efae@localhost> References: <071.0613799b287df0fa83f790ccb543efae@localhost> Message-ID: <080.fbf5a997cdcbd72d6fe06f555963637a@localhost> #1308: Type signature in warning is wrong -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.8 -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 09:35:37 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:34 2007 Subject: [GHC] #1309: 6.6.1 source tarball contains non-executable rts/gmp/configure; breaks build In-Reply-To: <071.b61a46268e109c2a25731e40b5afc697@localhost> References: <071.b61a46268e109c2a25731e40b5afc697@localhost> Message-ID: <080.2d3e458ebc1a84cb9a5e86125b7b7727@localhost> #1309: 6.6.1 source tarball contains non-executable rts/gmp/configure; breaks build -------------------------------------+-------------------------------------- Reporter: paulrbrown@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: MacOS X | Testcase: Architecture: powerpc64 | -------------------------------------+-------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: This is now fixed in the HEAD (./boot makes it executable, and that will get run before the source distribution is created). Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 09:47:39 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:34 2007 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjc4OiBmaWxlcGF0aOKAmXMgbWFrZVJlbGF0?= =?utf-8?q?ive_does_not_work_for_relative_directories?= In-Reply-To: <071.f477afc8bb979d5835d1a9ed128152d5@localhost> References: <071.f477afc8bb979d5835d1a9ed128152d5@localhost> Message-ID: <080.bcc7f686539e564da0b733d384bcff80@localhost> #1278: filepath?s makeRelative does not work for relative directories -----------------------------------------+---------------------------------- Reporter: mail@joachim-breitner.de | Owner: neil Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.6 Severity: minor | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | -----------------------------------------+---------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Neil's fixed this; the fix is included in both 6.6.1 and the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 10:06:08 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:34 2007 Subject: [GHC] #1316: add warning for local type signatures that use the same type variable names as outer type signatures In-Reply-To: <071.81a47e7677ab5bf6b84d6251ba4f9533@localhost> References: <071.81a47e7677ab5bf6b84d6251ba4f9533@localhost> Message-ID: <080.45715efa2c8c07506755892365ade814@localhost> #1316: add warning for local type signatures that use the same type variable names as outer type signatures --------------------------------+------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * milestone: => 6.8 Comment: I don't think this is a warning that we would want in -Wall, as common practice is to reuse the same type variables (a, b, c) for each type signature. However, it would be useful to people want to see how much of an effect scoped type ariables would have on existing code (which it sounds like is Isaac's motivation). -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 10:09:54 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:34 2007 Subject: [GHC] #1317: add warning for the Prelude being imported implicitly In-Reply-To: <071.cd9a0752b3d15704c0210a36ad475fb0@localhost> References: <071.cd9a0752b3d15704c0210a36ad475fb0@localhost> Message-ID: <080.4bd808e6033c4b8b9bbbb5698905e7b3@localhost> #1317: add warning for the Prelude being imported implicitly --------------------------------+------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * milestone: => 6.8 -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 10:56:41 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:34 2007 Subject: [GHC] #1299: "sh boot" should give a better error message if automake isn't installed In-Reply-To: <071.102216a2ef5e1c057aab25a094cade1b@localhost> References: <071.102216a2ef5e1c057aab25a094cade1b@localhost> Message-ID: <080.81b0e5659ce489f3ae409dbfeae09460@localhost> #1299: "sh boot" should give a better error message if automake isn't installed ---------------------------------------------+------------------------------ Reporter: chevalier@alum.wellesley.edu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: Unknown | ---------------------------------------------+------------------------------ Comment (by igloo): Hrm, the reason you get the messages 5 times is that autoreconf doesn't fail as a result of them, so we don't know anything has gone wrong and keep going. As we autoreconf in `ghc` and `libraries/{base,Win32,readline,unix}` the messages are given 5 times. I'm not sure what we can do about that. As for detecting automake, the problem is that we don't call it directly ourselves, so we don't know where it is (particularly when autoreconf isn't installed in the standard location). Has anyone got any suggestions, or should I just close the bug? -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From goldsmit at apple.com Fri May 4 15:13:20 2007 From: goldsmit at apple.com (Deborah Goldsmith) Date: Thu Jul 19 09:48:34 2007 Subject: Build failures on Mac OS X 10.5 In-Reply-To: <20070504134338.57abf515.Malcolm.Wallace@cs.york.ac.uk> References: <20070504134338.57abf515.Malcolm.Wallace@cs.york.ac.uk> Message-ID: Hi Malcolm, I believe what's going on here is that strerror has been changed for better Unix conformance, under the control of the __DARWIN_UNIX03 preprocessor flag. This is something you'll see in 10.4.x too. Here's an excerpt from /usr/include/unistd.h on 10.4.9: #if __DARWIN_UNIX03 pid_t setpgrp(void) __DARWIN_ALIAS(setpgrp); #else /* !__DARWIN_UNIX03 */ int setpgrp(pid_t pid, pid_t pgrp); /* obsoleted by setpgid() */ #endif /* __DARWIN_UNIX03 */ where __DARWIN_ALIAS and __DARWIN_UNIX03 come from /usr/include/sys/ cdefs.h: #if __DARWIN_UNIX03 && !defined(__LP64__) #define __DARWIN_ALIAS(sym) __asm("_" __STRING(sym) "$UNIX2003") #else #define __DARWIN_ALIAS(sym) #endif The idea behind this is that if something is compiled with __DARWIN_UNIX03 (for Unix 2003 conformance) it links to a version of the routine with $UNIX2003 appended (for 32-bit architectures). If not, it gets the old version (for compatibility). In 10.5, strerror() now falls under this switch where it didn't in 10.4: char *strerror(int) __DARWIN_ALIAS(strerror); (In this case the function signature hasn't changed as it did with setpgrp, but presumably the semantics have.) I tried configuring GHC with: ./configure CFLAGS="-O2 -D__DARWIN_UNIX03=0" but it didn't fix the problem for me. > Thanks for making contact. Can you tell us any more about why > Apple is > starting to find Haskell of sufficient interest to try to solve these > issues? No great mystery. I can't say whether Apple is interested in Haskell, but I am, and I've been learning it in my not-so-copious free time. I ran into this when trying to build GHC on 10.5. We try to let open- source developers know if there are problems in their projects on a new version of Mac OS X, because we like the projects to work when the new version comes out. :-) If you can think of something to try I'll be happy to try it for you and report back. Thanks, Deborah On May 4, 2007, at 5:43 AM, Malcolm Wallace wrote: > Deborah Goldsmith wrote: > >> /tmp/ghc78351_0/ghc78351_0.split__108.s:unknown: >> Undefined local symbol L_strerror$UNIX2003$stub > > The standard unix symbol 'strerror' is imported by the base package > from module Foreign/C/Error.hs like this: > > foreign import ccall unsafe "string.h" strerror :: Errno -> IO > (Ptr CChar) > > The corresponding prototype for 'strerror' in /usr/include/string.h > on MacOS 10.4.9 is: > > char *strerror(int); > > Which all looks like it matces up OK. I presume that in MacOS 10.5, > something in this area has changed to do with localisation, or > internationalisation. Perhaps 'strerror' is no longer implemented > as a > function, but as a cpp macro. Perhaps 'strerror' is no longer > physically located in libc.dylib. Perhaps there are now conditional > sections around 'strerror' which mean that we need to set a > pre-processing symbol to select the appropriate version of the > prototype. > > Can you give us any snippets from the Leopard version of > /usr/include/string.h that might confirm one of these hypotheses? > >> I can't divulge any confidential information about Leopard but I did >> get an OK to work with you folks to try to isolate the cause of this >> problem. If it's on our side we'd like to fix it, and if it's on your >> side we'd like to help you be ready for Leopard. > > Thanks for making contact. Can you tell us any more about why > Apple is > starting to find Haskell of sufficient interest to try to solve these > issues? > > Regards, > Malcolm _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 23:34:04 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:34 2007 Subject: [GHC] #1328: ghci accepts ":set -fno-glasgow-exts", but not ":unset -fglasgow-exts" Message-ID: <071.86fe27294a51ba01c4dc490a57d663bc@localhost> #1328: ghci accepts ":set -fno-glasgow-exts", but not ":unset -fglasgow-exts" ------------------------------+--------------------------------------------- Reporter: cdsmith@twu.net | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 6.6 Severity: minor | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 ------------------------------+--------------------------------------------- Using "gchi -fglasgow-exts", I want to turn off glasgow extensions. First I try: Prelude> :unset -fglasgow-exts can't unset GHC command-line flags But then: Prelude> :set -fno-glasgow-exts Prelude> :t 5 5 :: (Num t) => t So GHCi is capable of turning off glasgow extensions, but is apparently really picky about what command is used to do it. sorear suggested I file this as a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Fri May 4 23:35:57 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:34 2007 Subject: [GHC] #1328: ghci accepts ":set -fno-glasgow-exts", but not ":unset -fglasgow-exts" In-Reply-To: <071.86fe27294a51ba01c4dc490a57d663bc@localhost> References: <071.86fe27294a51ba01c4dc490a57d663bc@localhost> Message-ID: <080.68a9d1e4ad4654d9d7d5ac7e5f469f96@localhost> #1328: ghci accepts ":set -fno-glasgow-exts", but not ":unset -fglasgow-exts" --------------------------------+------------------------------------------- Reporter: cdsmith@twu.net | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | --------------------------------+------------------------------------------- Comment (by guest): That should have been: {{{ Prelude> :unset -fglasgow-exts can't unset GHC command-line flags }}} and {{{ Prelude> :set -fno-glasgow-exts Prelude> :t 5 5 :: (Num t) => t }}} -- Ticket URL: GHC The Glasgow Haskell Compiler -------------- next part -------------- _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From t