From trac at galois.com Tue Apr 1 19:19:07 2008 From: trac at galois.com (GHC) Date: Tue Apr 1 19:15:07 2008 Subject: [GHC] #2181: internal error: END_TSO_QUEUE object entered! In-Reply-To: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> References: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> Message-ID: <056.de1abea0b137838080b6920bb0797176@localhost> #2181: internal error: END_TSO_QUEUE object entered! ----------------------+----------------------------------------------------- Reporter: cconnett | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Comment (by cconnett): I've attached a tarball of my project source. I'd narrow it down if I knew how to with haskell tools. `make` in the project directory should build the executable `Solve`. Run: `./Solve bf irv u-3-15` Changing `-optc-O3` to `-optc-O1` in the Makefile causes the bug not to occur. Let me know if I can assist in simplifying the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 01:56:52 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 01:52:51 2008 Subject: [GHC] #2190: unionBuildInfo should not always use nub Message-ID: <042.a0e9a187aa60c1b3182a59d91c6dbe75@localhost> #2190: unionBuildInfo should not always use nub -----------------------------------+---------------------------------------- Reporter: prj | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: normal Keywords: unionBuildInfo nub | Testcase: Architecture: Multiple | Os: Multiple -----------------------------------+---------------------------------------- In libraries/Cabal/Distribution/PackageDescription.hs, the unionBuildInfo function combines, for example, ldOptions from two BuildInfos, using nub to eliminate duplicate arguments. This is wrong for ldOptions and some other elements. For example, if ldOptions contains: {{{-Xlinker -R -Xlinker /dir1 -Xlinker -R -Xlinker /dir2}}} Then the nubbed result is: {{{-Xlinker -R /dir1 /dir2}}} which doesn't work at all. There may be some redundancy that could be eliminated, but for arguments passed to external programs, it can only be done safely by understanding the semantics of the arguments. Similarly for extraLibs, {{{-lfoo -lbar -lfoo}}} may be necessary if {{{libfoo}}} and {{{libbar}}} reference each other's symbols. Using nub is wrong for at least cppOptions, ccOptions, ldOptions, and extraLibs. But I think it is necessary for some other BuildInfo components, like hsSourceDirs, so it can't be removed completely; that results in an error while building GHC: {{{ Preprocessing library unix-2.3.0.0... Generating Makefile unix-2.3.0.0... Setup: makefile: can't cope with multiple hs-source-dirs yet, sorry }}} So {{{combine}}} could take an extra arguments, which would be nub in some cases or id in others. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 03:27:50 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 03:23:57 2008 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> Message-ID: <053.3dec7dcb03ed94adbdd4c311d3cb03c1@localhost> #1475: Adding imports and exports with Template Haskell ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by simonpj): Whoa! Can you give more detail on your example? At the moment you definitely can't write a TH function that generates a Haskell module, compiles it, and imports it. You can generate those definitions in the current module though. Remember too that a TH definition can mention things in scope, and those things do not need to be imported where the TH function is called. Example {{{ module T(f) where import List f = [| null |] module Foo where import T h = $f }}} Here `$f` expands to `null`, but you do not need to import `List` in module `Foo`. In fact `$f` expands to `Data.List.null`, a kind of absolute reference to `null`. As the intro to this ticket says, TH-generated imports are really only useful for a form of dynamic binding. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 06:13:38 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 06:09:46 2008 Subject: [GHC] #2151: GADTs in function Patterns In-Reply-To: <047.2f6478e8e827595da4825a54c1ec722c@localhost> References: <047.2f6478e8e827595da4825a54c1ec722c@localhost> Message-ID: <056.c441db784e3948ec256e5f91643cab76@localhost> #2151: GADTs in function Patterns ----------------------+----------------------------------------------------- Reporter: hpacheco | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Comment (by hpacheco): I found a workaround for this issue: define a sub-function that handles the erroneous pattern matching. I suggest using this style meanwhile. test :: Type a -> a -> a test (PF func) ID = aux func where aux :: Type (a -> a) -> a aux (Func _ _) = ID -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 11:58:29 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 11:54:40 2008 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> Message-ID: <053.9db6cd7c3263f255dbb28db10692973c@localhost> #1475: Adding imports and exports with Template Haskell ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by m4dc4p): I don't need TH to dynamically create a module, compile it and import it in one go (though my message does imply that). Just being able to add import statements would be enough. Continuing with haskelldb, "table" definitions can be stored in separate modules. For example, If I have two tables, customers and orders, then they would normally be in the modules Acme.Customers and Acme.Orders. If I have a third module which defines all my queries, Acme.Queries, then I import the two tables as: {{{ module Acme.Queries where import qualified Acme.Customers as Customers import qualified Acme.Orders as Orders }}} Notice the qualified imports - those are necessary to avoid name clashes between the two modules (e.g., imagine if both tables have an ID column). As I add more tables, I need to add more import statements. Maybe I have a registration table: {{{ import qualified Acme.Registration as Registration }}} And so on, adding more and more clutter. Right now I have a file that imports about 15 "tables" and it's painful. I'd much rather have TH generate the import definition for me. For example: {{{ module Acme.Queries where $(importTables "Acme", ["Registration", "Customers", "Orders"]) }}} This becomes more important when you consider that I am trying to create a tool for other developers in my organization to use. They don't know Haskell, and I'd rather they didn't know they are learning Haskell until it's too late. Having to add these import statements would be a barrier for them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 12:31:52 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 12:27:48 2008 Subject: [GHC] #1423: compilation with profiling makes gcc run out of memory In-Reply-To: <044.607ca4a41a18c713e70e19a6ccf1c74d@localhost> References: <044.607ca4a41a18c713e70e19a6ccf1c74d@localhost> Message-ID: <053.e259019977db9e5b84caafcb74354fcd@localhost> #1423: compilation with profiling makes gcc run out of memory -----------------------------------------+---------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: via-c gcc compile profile | Difficulty: Unknown Testcase: http://malde.org/~ketil/bio | Architecture: x86 Os: Linux | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: No problems here with 6.8.2 and a 200M ulimit. The default is now `-fasm`, but even specifying `-fvia-C` it was fine. If you're still having problems, please reopen this report (or open a new one if that seems more appropriate). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 13:17:00 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 13:12:59 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.3822a577e0d7865b37a31c5f0c24eec4@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * os: Windows => Multiple * architecture: x86 => Multiple Comment: Thanks judah! And that also means it's not a Windows-only problem, which is useful info. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 13:58:48 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 13:54:53 2008 Subject: [GHC] #2181: internal error: END_TSO_QUEUE object entered! In-Reply-To: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> References: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> Message-ID: <056.780c0e2a135b6bfa6cad08a1da99c5db@localhost> #2181: internal error: END_TSO_QUEUE object entered! ----------------------+----------------------------------------------------- Reporter: cconnett | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Comment (by igloo): Can you send the output of `ghc --info` please? If it's a registerised compiler then we don't support changing the optimisations that gcc does, as the assembly mangling we do may get confused. On the other hand, if it's unregisterised then it points to a bug either in gcc or the code that we generate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 14:11:42 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 14:07:38 2008 Subject: [GHC] #2190: unionBuildInfo should not always use nub In-Reply-To: <042.a0e9a187aa60c1b3182a59d91c6dbe75@localhost> References: <042.a0e9a187aa60c1b3182a59d91c6dbe75@localhost> Message-ID: <051.0258c4da7975c087d7c56f34cda6a45f@localhost> #2190: unionBuildInfo should not always use nub --------------------------------+------------------------------------------- Reporter: prj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: unionBuildInfo nub | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks for the report. I've refiled it as a Cabal bug here: http://hackage.haskell.org/trac/hackage/ticket/264 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 15:17:47 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 15:14:33 2008 Subject: [GHC] #2181: internal error: END_TSO_QUEUE object entered! In-Reply-To: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> References: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> Message-ID: <056.6302682045130e940c6c1ffa56faef9f@localhost> #2181: internal error: END_TSO_QUEUE object entered! ----------------------+----------------------------------------------------- Reporter: cconnett | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Comment (by cconnett): [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","6.8.2") ,("Booter version","6.8.1") ,("Stage","2") ,("Interface file version","6") ,("Have interpreter","YES") ,("Object splitting","YES") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("Win32 DLLs","") ,("RTS ways"," debug thr thr_p thr_debug") ,("Leading underscore","NO") ] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 15:33:42 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 15:29:40 2008 Subject: [GHC] #881: Improve space profiling for references In-Reply-To: <046.89fda28d10e4c9bf9885adf9e31162cb@localhost> References: <046.89fda28d10e4c9bf9885adf9e31162cb@localhost> Message-ID: <055.5b9246cbbaa3206c621015ef5af2d00d@localhost> #881: Improve space profiling for references -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Profiling | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by SamB): Isn't the problem here that the retainer profiling is stopping at the IORef and writing the memory off as retained by "SYSTEM", when it should go back and find out who retains the IORef? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 15:44:07 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 15:40:03 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value Message-ID: <043.3641dba02e220ac3643aa7a87adf7815@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Component: Profiling Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- I find that I often wish I could ask GHC to tell me "where did *that* value come from?" as I debug JHC. Since GHC obviously can track this information, it seems like it would be fairly simple to implement a way for it to report this information as instructed by a running program. Perhaps: reportCssFor :: a -> b -> b I wouldn't really have any desire to use this on thunks, since when I want to do this it is usually because I don't like the value (i.e. it isn't in the right normal form), and to know this I must already have evaluated it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 19:19:21 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 19:15:23 2008 Subject: [GHC] #1947: Segmentation fault/access violation in generated code In-Reply-To: <051.7113ffd85120a95cf3f282877a678b8a@localhost> References: <051.7113ffd85120a95cf3f282877a678b8a@localhost> Message-ID: <060.a6bb310fc1ec1a609c86b0eace73626b@localhost> #1947: Segmentation fault/access violation in generated code --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: task | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: simplrun010 | Architecture: x86 Os: Windows | --------------------------+------------------------------------------------- Changes (by igloo): * testcase: => simplrun010 * status: new => closed * resolution: => fixed Comment: I couldn't reproduce the problem with 6.8.2, but I have now added the program as test `simplrun010` nevertheless. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 21:50:56 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 21:47:04 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.39c32935b1fbf1242d178f7cf1dda7db@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Changes (by tim): * cc: chevalier@alum.wellesley.edu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 22:45:07 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 22:41:03 2008 Subject: [GHC] #907: Case sensitive ghci commands In-Reply-To: <058.4e67421e94a7459b62b3dc5e5c82730f@localhost> References: <058.4e67421e94a7459b62b3dc5e5c82730f@localhost> Message-ID: <067.3b1c6df23be8fa6309bb3489c89f46bc@localhost> #907: Case sensitive ghci commands ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: GHCi | Version: 6.4.1 Severity: trivial | Resolution: Keywords: case command colon | Difficulty: Easy (1 hr) Testcase: N/A | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Comment (by SamB): FWIW, I don't think most of us care one way or the other; probably the only people who care are those who want it case-insensitive? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 2 22:55:12 2008 From: trac at galois.com (GHC) Date: Wed Apr 2 22:51:07 2008 Subject: [GHC] #788: Class aliases (as proposaed by John Meacham) In-Reply-To: <046.352573f276ea0b65a1451eea70e3a225@localhost> References: <046.352573f276ea0b65a1451eea70e3a225@localhost> Message-ID: <055.38d6434604d9a3b6b61acfc104f737b7@localhost> #788: Class aliases (as proposaed by John Meacham) -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by SamB): Note that the class alias proposal seems to have some syntax errors. I found these in trying to implement class aliases in John's own compiler, JHC -- which I haven't given up on yet, but I am sidetracked fixing (->) for now... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 3 03:40:37 2008 From: trac at galois.com (GHC) Date: Thu Apr 3 03:36:31 2008 Subject: [GHC] #2141: Internal error on invalid record update In-Reply-To: <041.12bd6af75f291bf77b61c12a037ef054@localhost> References: <041.12bd6af75f291bf77b61c12a037ef054@localhost> Message-ID: <050.4298fc00a55b4899c000545ea1e26ce9@localhost> #2141: Internal error on invalid record update -------------------------------------+-------------------------------------- Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 3 03:41:12 2008 From: trac at galois.com (GHC) Date: Thu Apr 3 03:37:07 2008 Subject: [GHC] #2137: Location of shadowed binding is wrong in warning In-Reply-To: <044.44ee490b4171e22911243bf12a9d127e@localhost> References: <044.44ee490b4171e22911243bf12a9d127e@localhost> Message-ID: <053.0e24a73a617d38f4d367c235e7e04a25@localhost> #2137: Location of shadowed binding is wrong in warning ----------------------+----------------------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rn064 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 3 03:41:44 2008 From: trac at galois.com (GHC) Date: Thu Apr 3 03:37:37 2008 Subject: [GHC] #2136: Not warned about unused recursive bindings In-Reply-To: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> References: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> Message-ID: <053.0455a8e0f488918e61d5efa711f26cd5@localhost> #2136: Not warned about unused recursive bindings ----------------------+----------------------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rn063 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:00:20 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 16:57:02 2008 Subject: [GHC] #783: performance problem compiling large file In-Reply-To: <044.a7a580fed8a85952633cd84570dae070@localhost> References: <044.a7a580fed8a85952633cd84570dae070@localhost> Message-ID: <053.d3936bf0fd57aeb22cdd60ffc79d89c5@localhost> #783: performance problem compiling large file ------------------------------------------+--------------------------------- Reporter: guest | Owner: igloo Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------+--------------------------------- Changes (by igloo): * type: merge => compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:13:32 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:09:29 2008 Subject: [GHC] #2181: internal error: END_TSO_QUEUE object entered! In-Reply-To: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> References: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> Message-ID: <056.82c06337435792484825488dbd575499@localhost> #2181: internal error: END_TSO_QUEUE object entered! ----------------------+----------------------------------------------------- Reporter: cconnett | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: OK, so that says that it's not unregisterised, and therefore using `-optc-O3` isn't supported. If you stick with passing just `-O` of `-O2` to GHC then it should work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:14:11 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:10:09 2008 Subject: [GHC] #2179: Improve error message when `main' is not of the right type In-Reply-To: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> References: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> Message-ID: <056.95c65ef17c579a06048a0242fc3f13e2@localhost> #2179: Improve error message when `main' is not of the right type ----------------------+----------------------------------------------------- Reporter: amiddelk | Owner: simonpj Type: proposal | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:15:16 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:11:06 2008 Subject: [GHC] #2188: TH scoping problem In-Reply-To: <044.2bbd6efb87952e5e65fa7406d244cf0e@localhost> References: <044.2bbd6efb87952e5e65fa7406d244cf0e@localhost> Message-ID: <053.8cc3a50a4f8021bf63a83631281e43f2@localhost> #2188: TH scoping problem ------------------------------+--------------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_scope | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:18:06 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:14:09 2008 Subject: [GHC] #783: performance problem compiling large file In-Reply-To: <044.a7a580fed8a85952633cd84570dae070@localhost> References: <044.a7a580fed8a85952633cd84570dae070@localhost> Message-ID: <053.7baf67643556d0cc91692843ba60f072@localhost> #783: performance problem compiling large file ------------------------------------------+--------------------------------- Reporter: guest | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ------------------------------------------+--------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 17:51:58 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:47:53 2008 Subject: [GHC] #2192: occasional segmentation faults when using Control.Parallel Message-ID: <044.41e146963f3d21c260430274434fb250@localhost> #2192: occasional segmentation faults when using Control.Parallel -----------------------+---------------------------------------------------- Reporter: ivant | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- The attached program fails quite often with segmentation faults or internal errors (unpredictably, in consecutive runs, without changing the source): {{{ % time ./parallel +RTS -N2 zsh: segmentation fault (core dumped) ./parallel +RTS -N2 ./parallel +RTS -N2 2.79s user 0.42s system 107% cpu 2.988 total % time ./parallel +RTS -N2 parallel: internal error: evacuate: strange closure type 65284 (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./parallel +RTS -N2 ./parallel +RTS -N2 3.60s user 0.51s system 108% cpu 3.781 total % time ./parallel +RTS -N2 zsh: segmentation fault (core dumped) ./parallel +RTS -N2 ./parallel +RTS -N2 5.09s user 0.46s system 111% cpu 4.982 total % time ./parallel +RTS -N2 500000 ./parallel +RTS -N2 8.34s user 0.14s system 108% cpu 7.796 total }}} The program can fail both when it is compiled with and without -O2. Changing the value of maxSparks makes a difference (with value 2 it is finishing successfully always (or probably more often)). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 18:00:08 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 17:56:10 2008 Subject: [GHC] #2192: occasional segmentation faults when using Control.Parallel In-Reply-To: <044.41e146963f3d21c260430274434fb250@localhost> References: <044.41e146963f3d21c260430274434fb250@localhost> Message-ID: <053.09ccd4f6a3e5f3c9f9539f6dfbb3a3e3@localhost> #2192: occasional segmentation faults when using Control.Parallel -------------------------+-------------------------------------------------- Reporter: ivant | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: par | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by dons): * keywords: => par * severity: normal => major Comment: I wasn't able to reproduce this on OpenBSD/amd64 with ghc 6.8.2. The program runs to completion: {{{ $ ./A +RTS -N2 500000 }}} On a 4 core linux box, however, I triggered some faults: {{{ $ ./A +RTS -N2 500000 $ ./A +RTS -N2 A: internal error: evacuate: strange closure type 23552 (GHC version 6.8.1.20071114 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ ./A +RTS -N4 zsh: segmentation fault ./A +RTS -N4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 18:35:42 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 18:31:31 2008 Subject: [GHC] #2193: Monomorphic Pattern Bindings and Error Messages Message-ID: <043.34ccdeb27bebe4aa866d2df9503f28c8@localhost> #2193: Monomorphic Pattern Bindings and Error Messages -------------------------+-------------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Not clear to me if the following should be a type error or if it should be allowed to unify properly. In either case, the error message is borked. {{{ {-# OPTIONS -fglasgow-exts #-} module Test where data Foo x y = Foo {foo1 :: x, foo2 :: y} instance Functor (Foo x) where fmap f (Foo x y) = Foo x (f y) bar :: a -> Foo (forall s. s) a bar a = Foo undefined a main = print (foo2 (fmap (*2) (bar 2))) {- sclv.hs:12:20: Cannot match a monotype with `forall s. s' When matching `forall s. s' and `forall s. s' Expected type: Foo (forall s1. s1) a Inferred type: Foo (forall s1. s1) a In the first argument of `foo2', namely `(fmap ((* 2)) (bar 2))' -} }}} {{{ *Test> :t bar (2 :: Integer) bar (2 :: Integer) :: Foo (forall s. s) Integer *Test> :t foo2 (bar (2 :: Integer)) foo2 (bar (2 :: Integer)) :: Integer *Test> :t fmap (*2) (bar (2 :: Integer)) fmap (*2) (bar (2 :: Integer)) :: Foo (forall s. s) Integer *Test> :t foo2 (fmap (*2) (bar (2 :: Integer))) :1:6: Cannot match a monotype with `forall s. s' When matching `forall s. s' and `forall s. s' Expected type: Foo (forall s1. s1) Integer Inferred type: Foo (forall s1. s1) Integer In the first argument of `foo2', namely `(fmap ((* 2)) (bar (2 :: Integer)))' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Apr 4 19:11:06 2008 From: trac at galois.com (GHC) Date: Fri Apr 4 19:06:58 2008 Subject: [GHC] #1657: throwTo + unsafeInterleaveIO oddness In-Reply-To: <044.21440a48538e444ebfd4d18aeba61e97@localhost> References: <044.21440a48538e444ebfd4d18aeba61e97@localhost> Message-ID: <053.d24d4c2b49944bbfe895160c3ddf393d@localhost> #1657: throwTo + unsafeInterleaveIO oddness ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 01:43:19 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 01:39:08 2008 Subject: [GHC] #2194: internal error: R_X86_64_32 relocation out of range Message-ID: <046.dc336ddb5330040c8ab47ea2ef281042@localhost> #2194: internal error: R_X86_64_32 relocation out of range -------------------------------+-------------------------------------------- Reporter: alatter | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- $ ghci Stub.hs Whirlpool.o GHCi, version 6.8.2.20080316: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading object (static) Whirlpool.o ... done ghc-6.8.2.20080316: internal error: R_X86_64_32 relocation out of range: (noname) = 0x7fc20c2c3010 (GHC version 6.8.2.20080316 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) ----- I'm running Ubuntu 8.4 Beta on some sort of Intel 64-bit platform (Core, maybe?). To reproduce, you'll want the files from http://planeta.terra.com.br/informatica/paulobarreto/whirlpool.zip And in the same directory, the attached files Stub.hs and Whirlpool.h (not needed just to compile the .c file, but it makes the haskell FFI happy). There are a couple things I tried First: $ gcc Whirlpool.c -c $ ghci Stub Whirlpool.o Second: $ rm *.o $ ghc --make Stub Whirlpool.c $ ghci Stub Whirlpool.o -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 05:24:27 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 05:20:17 2008 Subject: [GHC] #2141: Internal error on invalid record update In-Reply-To: <041.12bd6af75f291bf77b61c12a037ef054@localhost> References: <041.12bd6af75f291bf77b61c12a037ef054@localhost> Message-ID: <050.719793d205f6194a00c47799f5ff2565@localhost> #2141: Internal error on invalid record update -------------------------------------+-------------------------------------- Reporter: rl | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Wed Apr 2 06:20:57 PDT 2008 simonpj@microsoft.com * Fix Trac #2141: invalid record update }}} Ian: can you add a test case as well as merging? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 05:25:34 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 05:21:23 2008 Subject: [GHC] #2137: Location of shadowed binding is wrong in warning In-Reply-To: <044.44ee490b4171e22911243bf12a9d127e@localhost> References: <044.44ee490b4171e22911243bf12a9d127e@localhost> Message-ID: <053.6a687b7bc8291fc6e9fb32b71d797812@localhost> #2137: Location of shadowed binding is wrong in warning ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rn064 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Wed Apr 2 08:34:10 PDT 2008 simonpj@microsoft.com * Fix Trac #2137: report correct location for shadowed binding }}} Ian: can you change the test to 'should pass'? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 05:27:00 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 05:22:49 2008 Subject: [GHC] #2136: Not warned about unused recursive bindings In-Reply-To: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> References: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> Message-ID: <053.803e54ac4a3873a677801846a9e286c7@localhost> #2136: Not warned about unused recursive bindings ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rn063 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Thu Apr 3 04:02:50 PDT 2008 simonpj@microsoft.com * Fix Trac #2136: reporting of unused variables }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 05:28:09 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 05:24:08 2008 Subject: [GHC] #2179: Improve error message when `main' is not of the right type In-Reply-To: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> References: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> Message-ID: <056.3f855064aa74df99445485e6cbda5b72@localhost> #2179: Improve error message when `main' is not of the right type ----------------------+----------------------------------------------------- Reporter: amiddelk | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: proposal => merge Comment: Fixed by {{{ Thu Apr 3 10:37:46 PDT 2008 simonpj@microsoft.com * Fix Trac #2179: error message for main }}} Ian, can you add a test case please? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 05:29:03 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 05:24:50 2008 Subject: [GHC] #2188: TH scoping problem In-Reply-To: <044.2bbd6efb87952e5e65fa7406d244cf0e@localhost> References: <044.2bbd6efb87952e5e65fa7406d244cf0e@localhost> Message-ID: <053.590342dfbfe029db16f923d9479cff11@localhost> #2188: TH scoping problem ------------------------------+--------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_scope | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Fri Apr 4 13:55:56 PDT 2008 simonpj@microsoft.com * Fix Trac #2188: scoping in TH declarations quotes }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 12:05:36 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 12:01:31 2008 Subject: [GHC] #1717: ghc-6.8 configure does not recognise 32bit userland on ppc64 In-Reply-To: <059.9ba98474c2b63eccc55349ae913ba846@localhost> References: <059.9ba98474c2b63eccc55349ae913ba846@localhost> Message-ID: <068.b4e4f3efa69c0d7f3e48011b428b1906@localhost> #1717: ghc-6.8 configure does not recognise 32bit userland on ppc64 ----------------------------------+----------------------------------------- Reporter: kahl@cas.mcmaster.ca | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: normal build | Architecture: powerpc64 Os: Linux | ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: 6.8.3 => 6.10 branch Comment: It looks like some normalisation would be necessary: {{{ ian@matrix:~$ uname -m i686 ian@matrix:~$ gcc -dumpmachine i486-linux-gnu }}} {{{ $ uname -m i686 $ gcc -dumpmachine mingw32 }}} I'm moving this to the 6.10 branch, as I don't think there's much advantage to doing this in 6.8.3, but there is the potential for the build to abort in some cases that are OK but that we didn't test. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 13:53:35 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 13:49:22 2008 Subject: [GHC] #2045: Link error when compiling with -fhpc In-Reply-To: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> References: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> Message-ID: <053.65cbfe2f3be06c5ab67644750e23f3d3@localhost> #2045: Link error when compiling with -fhpc ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 16:46:13 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 16:42:00 2008 Subject: [GHC] #2045: Link error when compiling with -fhpc In-Reply-To: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> References: <044.3e291c48a73368cfaa2c03d4b6685800@localhost> Message-ID: <053.9d9e7c877569e4244651fa3fc663a4c9@localhost> #2045: Link error when compiling with -fhpc ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: igloo => Comment: `Vhdl.hs` is a small, self-contained example. Compile with: {{{ ghc --make Vhdl.hs -o gencirc }}} As I understand it GHC is supposed to generate large tuples and then have them disappear later on. My guess is that the HPC ticks are interfering with the elimination, but I'm not sure where that is supposed to happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 17:11:58 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 17:07:45 2008 Subject: [GHC] #2195: yi: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c436730a Message-ID: <044.cc96d7cce62f73d5dee217e7be0e7f3f@localhost> #2195: yi: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c436730a -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: linker | Testcase: Architecture: x86_64 (amd64) | Os: FreeBSD -------------------------------+-------------------------------------------- FreeBSD 7.0 kmacy@pandemonium [~/devel/tmp/yi-0.3|14:09|30] yi Loading package base ... linking ... done. Loading package array-0.1.0.0 ... linking ... done. Loading package bytestring-0.9.0.1 ... linking ... done. Loading package regex-base-0.72.0.1 ... linking ... done. Loading package regex-posix-0.72.0.2 ... linking ... done. Loading package regex-compat-0.71.0.1 ... linking ... done. Loading package fingertree-0.0 ... linking ... done. Loading package mtl-1.1.0.0 ... linking ... done. Loading package glib-0.9.12.1 ... linking ... done. Loading package cairo-0.9.12.1 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. yi: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c436730a (GHC version 6.8.2 for x86_64_unknown_freebsd) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) yi backtrace of core is ~2500 frames of rubbish -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 18:03:31 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 17:59:18 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.7f925207ec41e6b7a541fcefdbe6b14f@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * owner: => simonpj Comment: ...but not with the HEAD. This program: {{{ {-# LANGUAGE ScopedTypeVariables, ExistentialQuantification #-} import Control.Monad.ST.Strict import Data.Array.ST rsRandom :: ST s a rsRandom = undefined write :: Int -> ST s (forall ss . (STUArray ss Int Double) -> ST ss ()) write i = rsRandom >>= \x -> return (\buf -> writeArray buf i x) }}} is accepted by the 6.8 branch, but not the HEAD. I'd expect it to be rejected too (`x` is monomorphic, and generalisation won't make a higher rank type), so I think the HEAD is right, but I will let Simon PJ have the last word... I don't think this is worth fixing just for 6.8.3, unless there are other programs that the HEAD also accepts that trigger the problem, so if the program ought to be rejected then I think that we can close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 18:53:03 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 18:48:49 2008 Subject: [GHC] #2015: SOE samples crash when running from ghci rather than compiling and running with ghc In-Reply-To: <047.485ea5c57b8e879f2c33305a489b8545@localhost> References: <047.485ea5c57b8e879f2c33305a489b8545@localhost> Message-ID: <056.5037571e017862704357747d84e8c3e8@localhost> #2015: SOE samples crash when running from ghci rather than compiling and running with ghc ----------------------+----------------------------------------------------- Reporter: justinhj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: SOE ghci | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: It works fine for me, with GLFW installed using Cabal: {{{ C:\cygwin\home\ian\soe\SOE\src>ghci Snowflake.lhs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 2] Compiling SOE ( SOE.hs, interpreted ) [2 of 2] Compiling Snowflake ( Snowflake.lhs, interpreted ) Ok, modules loaded: SOE, Snowflake. *Snowflake> main Loading package OpenGL-2.2.1.1 ... linking ... done. Loading package GLFW-0.3 ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. }}} I don't know what your `test.hs` is; SOE doesn't seem to come with one. I notice that your GLFW is an older version than mine, so perhaps this problem has been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 20:28:46 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 20:24:32 2008 Subject: [GHC] #2196: Errors in output from formatTime Message-ID: <044.a53cada5d60b5b73662375cb432c3e02@localhost> #2196: Errors in output from formatTime -------------------------+-------------------------------------------------- Reporter: laney | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Unknown -------------------------+-------------------------------------------------- Hi, I have discovered two errors in the Date/Time libraries distributed with GHC. When running the attached testcase: *Main> timebug Loading package old-locale-1.0.0.0 ... linking ... done. Loading package time-1.1.2.0 ... linking ... done. "Sun, d Apr 2008 00:16:45 UTC" There are two problems here: * Returns "d" for day of month, certainly not right. * Returns "UTC" instead of "UT", incorrect per RFC 822 - http://www.faqs.org/rfcs/rfc822.html section 5.1 Iain -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 20:38:06 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 20:34:04 2008 Subject: [GHC] #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' In-Reply-To: <054.f4411cf09d2804f4c2a24a7055f19618@localhost> References: <054.f4411cf09d2804f4c2a24a7055f19618@localhost> Message-ID: <063.523b92678fe39880bbb668f087fcf2da@localhost> #2083: linker reports missing symbols Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' -----------------------------+---------------------------------------------- Reporter: Andrew U. Frank | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: No reply from submitter, and probably caused by an incorrect module header, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 20:39:07 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 20:34:53 2008 Subject: [GHC] #2084: GHC panic In-Reply-To: <047.2af7ef94b11d6e7558fa16d6fcecb781@localhost> References: <047.2af7ef94b11d6e7558fa16d6fcecb781@localhost> Message-ID: <056.a8b20380ad3f6afb1e34178139ca18c2@localhost> #2084: GHC panic ----------------------+----------------------------------------------------- Reporter: stimberm | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: No response from submitter, and no testcase, so closing bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 23:10:12 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 23:05:57 2008 Subject: [GHC] #2197: GHCi doesn't work when built with way=p Message-ID: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> #2197: GHCi doesn't work when built with way=p ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- I don't really mind so much that Cabal etc. don't support building GHCi profiling libs (it would be easy enough to do by hand), but the fact that GHCi tries to load the un-profiling GHCi libs is a bit annoying... it doesn't work too well... naesten@hydrogen:~/hacking/haskell/ghc-hashedrepo% ./compiler/stage2/ghc- inplace_p --interactive GHCi, version 6.9.20080305: http://www.haskell.org/ghc/ :? for help ghc_p-6.9.20080305: /home/naesten/hacking/haskell/ghc-hashedrepo/libraries /ghc-prim/dist/build/HSghc-prim-0.1.o: unknown symbol `traceCcszh_fast' Loading package ghc-prim ... linking ... ghc_p-6.9.20080305: unable to load package `ghc-prim' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 23:12:55 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 23:08:41 2008 Subject: [GHC] #2197: GHCi doesn't work when built with way=p In-Reply-To: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> References: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> Message-ID: <052.df7b821f9805ae697d1a9b2ef7e3a19f@localhost> #2197: GHCi doesn't work when built with way=p ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- Comment (by SamB): Btw, the symbol mentioned in the error is from something I'm working on... but the non_p ghci loads fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 23:22:58 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 23:18:43 2008 Subject: [GHC] #1580: Get GHC happy with alternate base packages (split base) In-Reply-To: <043.678042925abbf66332cc75519a97afa0@localhost> References: <043.678042925abbf66332cc75519a97afa0@localhost> Message-ID: <052.b0621229af76d68a9986101292ed4442@localhost> #1580: Get GHC happy with alternate base packages (split base) ----------------------+----------------------------------------------------- Reporter: SamB | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by SamB): Replying to [comment:1 igloo]: > Other than splitting up base (#1338), I'm not clear on exactly what you want. Is it more rebindable syntax? For example, the wiki page you point at says you want to replace Read, but I'm not sure exactly what you mean by that. You can make a class called Read, but GHC isn't going to know how to derive instances of it. > > If you could give a more concrete list of changes you want then that would be very helpful. Well, this ghc-prim package I'm seeing in HEAD is a step in the direction I meant ;-). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Apr 5 23:59:18 2008 From: trac at galois.com (GHC) Date: Sat Apr 5 23:55:35 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.e71eb0922171462711cf4c4d621051f4@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by SamB): The primitive above appears to do essentially what I want... at least, it prints something in pointy brackets that looks like a CCS when I call it... hmm. Doesn't always work... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 01:15:41 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 01:12:00 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.fc99a194d1569a165526052c9a644700@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by SamB): Okay, either I've done something stupid, or I'm missing something really subtle about the css field's validity... shouldn't it always be valid? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 05:49:02 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 05:44:46 2008 Subject: [GHC] #2198: Build failure on Mac OS X Tiger Intel Message-ID: <044.e669693b0e2d8babbb9829cda3557205@localhost> #2198: Build failure on Mac OS X Tiger Intel -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- The ghc in Macports fails to build on my Intel MacBook, running Mac OS 10.5.2. Here's what Gregory Wright, the ghc macports maintainer had to say: ''It is possible that this is yet another file locking bug, which seem especially easy to trigger when running OS X on faster hardware. The warning from PackageConfig.hs may be spurious, the result of the import from InstalledPackageInfo.hi silently failing. There are a few places where important error messages are discarded, on the assumption that the cause of the failure will be obvious.'' I've attached the build log. I'd be happy to provide more information, if it might help. Wouter Swierstra -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 13:55:33 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 13:51:21 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.a91a5233500673bd8630727218d0cf0c@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: patch | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Changes (by SamB): * keywords: => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 14:58:48 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 14:54:31 2008 Subject: [GHC] #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout Message-ID: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: th32SnapEnumProcesses | Testcase: Architecture: Unknown | Os: Windows --------------------------------------+------------------------------------- TSIA, pretty much. I suspect that when the author was developing this function he put in some putStrLn calls for his own use and simply forgot to remove them. For my application I just took the code out of the library and ripped out the offending statements, but I don't think they're really supposed to be there and ought to be either removed or #ifdef'd out somehow. Here's my cleaned up version (I also removed some extraneous parenthesis, FWIW). th32SnapEnumProcesses :: Th32SnapHandle -> IO [ProcessEntry32] th32SnapEnumProcesses h = allocaBytes 556 $ \pe -> do pokeByteOff pe 0 (556 :: DWORD) ok <- c_Process32First h pe readAndNext ok pe [] where errStr = "th32SnapEnumProcesses: Process32First/Process32Next" readAndNext ok pe res | not ok = do err <- getLastError if err == 18 then return $ reverse res else failWith errStr err | otherwise = do entry <- peekProcessEntry32 pe ok' <- c_Process32Next h pe readAndNext ok' pe (entry:res) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 14:59:53 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 14:55:36 2008 Subject: [GHC] #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout In-Reply-To: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> References: <044.b8fbd1c67ea8e923433d5eaf1eaa88db@localhost> Message-ID: <053.851703c62139d9e222a1c7c0e6eba852@localhost> #2199: th32SnapEnumProcesses in System.Win32.Process prints debugging information to stdout --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: th32SnapEnumProcesses | Testcase: Architecture: Unknown | Os: Windows --------------------------------------+------------------------------------- Comment (by guest): Sorry about that formatting, let me try again: {{{ th32SnapEnumProcesses :: Th32SnapHandle -> IO [ProcessEntry32] th32SnapEnumProcesses h = allocaBytes 556 $ \pe -> do pokeByteOff pe 0 (556 :: DWORD) ok <- c_Process32First h pe readAndNext ok pe [] where errStr = "th32SnapEnumProcesses: Process32First/Process32Next" readAndNext ok pe res | not ok = do err <- getLastError if err == 18 then return $ reverse res else failWith errStr err | otherwise = do entry <- peekProcessEntry32 pe ok' <- c_Process32Next h pe readAndNext ok' pe (entry:res) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 15:51:17 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 15:47:01 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.389192385ec899bd7a7278d6fa38e49c@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 16:39:23 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 16:35:09 2008 Subject: [GHC] #2200: big static random access arrays Message-ID: <043.a925e7306d93d3b9993abaf14c0d8674@localhost> #2200: big static random access arrays --------------------------------+------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: static array | Testcase: Architecture: Multiple | Os: Multiple --------------------------------+------------------------------------------- These would be unlike `StorableArray`s because they would be available at compile time, and would be pure values. They would amount to arrays of bytes, of course, but it'd be nice if they could be `(Storable a) => StaticArray a` and we could walk down them or randomly access them to get the `a` values out of them. They should be capable of storing hundreds of thousands of `Int`s. What are some functions that work on these arrays? We need just one: {{{ indexInto :: (Storable a) => StaticArray a -> Word -> a }}} Then we can make a `Monad` to walk up and down the array. It will be some `State` hybrid. No `IO`. A bright person could implement static `Trie`s, `RoseTree`s and other things using this `Monad` -- storing the offsets mixed in with the data in an unholy mess and skipping forward or backward, leveraging "the world?s most beautiful imperative language." It's been suggested (SamB) that this should be implemented in Template Haskell. Important features of this array relative to other arrays and lists in Haskell: Specificity of Index:: A machine `Word` since that contains the finest grained pointer. When indexing into a `Storable a`, the index is multiplied by `sizeOf (undefined :: a)`. Static Nature:: Exists to facilitate large static constants. The array does not support any append or delete operations, there is no way to change any of its values and it can not be copied. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 16:44:15 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 16:39:59 2008 Subject: [GHC] #2200: big static random access arrays In-Reply-To: <043.a925e7306d93d3b9993abaf14c0d8674@localhost> References: <043.a925e7306d93d3b9993abaf14c0d8674@localhost> Message-ID: <052.f11f97ccfd348d86b095284c8ea772ff@localhost> #2200: big static random access arrays --------------------------------+------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: static array | Testcase: Architecture: Multiple | Os: Multiple --------------------------------+------------------------------------------- Comment (by dons): See this recent thread on compile time data structures, http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/14059/focus=37186 In particular, the solutions using Data.Binary to encode data structures. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 16:56:47 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 16:52:29 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.7831219085fd2db56eca5a6d88286606@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * type: bug => merge Comment: Fixed: {{{ Sun Apr 6 21:50:51 BST 2008 Ian Lynagh * malloc a big enough buffer for the registry functions. Fixes trac #2097. We were mallocing a byte per tchar, but tchars are normally 2 bytes big... I think they are at most 4 bytes, so we now malloc 4 * #tchars. Not sure if there is a proper function I should be using for this? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 17:44:33 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 17:40:16 2008 Subject: [GHC] #2091: heap corruption in ghc-6.8.2? In-Reply-To: <044.3e0a988db69b0177d74a97127f5c474c@localhost> References: <044.3e0a988db69b0177d74a97127f5c474c@localhost> Message-ID: <053.c131116b424dadca538a7d81e8a4068d@localhost> #2091: heap corruption in ghc-6.8.2? ----------------------+----------------------------------------------------- Reporter: jeffz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: I can't reproduce this with Debian's wine 0.9.41-1, so it sounds like a wine bug to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 17:52:30 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 17:48:13 2008 Subject: [GHC] #2201: "ghc-pkg --user describe '*'" fails with empty user db Message-ID: <045.673a6cc9904f9063d50fb7c9230e5305@localhost> #2201: "ghc-pkg --user describe '*'" fails with empty user db ------------------------+--------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- With ghc 6.9 and later Cabal uses the new "`ghc-pkg describe '*'`" interface to get info out of `ghc-pkg` about all the installed packages. It makes one call for each package db, for `--global` and `--user` (and any other dbs the user specifies). The `--user` flag now means to list only the packages from the user db and not the ones from the global one too. It's quite possible that the user package db is empty (or equivalently that the file does not exist yet). So what goes wrong is that the new search feature treats an empty search result as a failure. That's obviously a useful thing for some queries but is extremely unhelpful for what Cabal wants. It means Cabal fails to configure anything when the user package db is empty because it does not expect ghc-pkg to fail. This blocks the current Cabal HEAD from working with ghc HEAD. I'd like to put in another request for the `ghc-pkg dump` feature that I suggested originally. It would just dump all the packages in the `describe` format. The difference is that it is not a query so we do not fail if the result set is empty. Also, `dump` should not produce helpful human readable error output like "{{{ghc-pkg: cannot find package matching *}}}" because that will upset Cabal's parser. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 18:54:16 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 18:50:21 2008 Subject: [GHC] #2036: Show for Double and Float doesn't use parenthesis for negative zero. In-Reply-To: <047.9085fb42c7e7997d5332318ebe9470cc@localhost> References: <047.9085fb42c7e7997d5332318ebe9470cc@localhost> Message-ID: <056.77f0b20da795aaed73e3c70398d4d859@localhost> #2036: Show for Double and Float doesn't use parenthesis for negative zero. ---------------------------------+------------------------------------------ Reporter: clanehin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/haskell98 | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Malcolm agrees that this looks like a language defn bug, so we should just fix the -0 case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 21:45:47 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 21:41:30 2008 Subject: [GHC] #2153: GHCi does not have a :source command to load further .ghci files In-Reply-To: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost> References: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost> Message-ID: <052.3c4132b63087efb25d0e1dd5966447d6@localhost> #2153: GHCi does not have a :source command to load further .ghci files ---------------------+------------------------------------------------------ Reporter: SamB | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Comment (by SamB): Wow, that simple??? What needs to be done to get this in ":?" output? (It should be in the manual, at least...) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Apr 6 23:14:58 2008 From: trac at galois.com (GHC) Date: Sun Apr 6 23:10:43 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.a966d4467684e5ee021b59e011079073@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Comment (by r6144): -XImpredicativeTypes (implied by -fglasgow-exts) appears to be necessary for array1.hs as well as igloo's simpler example. To make the original array1.hs compile with GHC 6.9.20080323, I have to expand the do statements involving polymorphic lambda-bound variables, e.g. "do { w <- writeRandoms ; return (newArray_ (0,n-1) >>= w) }" into "writeRandoms >>= \w -> return (newArray_ (0,n-1) >>= w)". If I understand correctly, -XImpredicativeTypes allows w to be polymorphic. After this modification, array1.hs (called array1-orig.hs below) compiles, but the original problem persists: {{{ [haskell]$ ~/apps/ghc-6.9.20080323/bin/ghci GHCi, version 6.9.20080323: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :load array1-orig.hs [1 of 1] Compiling Main ( array1-orig.hs, interpreted ) Ok, modules loaded: Main. *Main> :break rsRandomArray Breakpoint 0 activated at array1-orig.hs:(32,0)-(43,86) *Main> main Loading package array-0.1 ... linking ... done. Loading package old-locale-1.0 ... linking ... done. Loading package old-time-1.0 ... linking ... done. Loading package random-1.0 ... linking ... done. Array 1: array Stopped at array1-orig.hs:(32,0)-(43,86) _result :: ST s (UArray Idx Double) = _ [array1-orig.hs:(32,0)-(43,86)] *Main> :step Stopped at array1-orig.hs:32:21-53 ghc-6.9.20080323: panic! (the 'impossible' happened) (GHC version 6.9.20080323 for i386-unknown-linux): Can't unify Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [array1-orig.hs:32:21-53] *Main> :quit Leaving GHCi. [ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 05:32:54 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 05:28:35 2008 Subject: [GHC] #2097: bug in regEnumKeys (System.Win32.Registry) In-Reply-To: <053.154a24ca3b071941575751aaf8747feb@localhost> References: <053.154a24ca3b071941575751aaf8747feb@localhost> Message-ID: <062.063f80c94ab8fd0c33937a7eb40f1428@localhost> #2097: bug in regEnumKeys (System.Win32.Registry) -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Comment (by MagnusTherning): Replying to [comment:5 igloo]: > Fixed: > {{{ > Sun Apr 6 21:50:51 BST 2008 Ian Lynagh > * malloc a big enough buffer for the registry functions. Fixes trac #2097. > We were mallocing a byte per tchar, but tchars are normally 2 bytes big... > I think they are at most 4 bytes, so we now malloc 4 * #tchars. Not sure > if there is a proper function I should be using for this? > }}} One way to be sure is to switch to using wide characters explicitly, i.e. to use RegOpenKeyExW rather than RegOpenKeyEx. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 06:40:53 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 06:36:44 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.518eca29ad50081ef2b6a5da06c40496@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: patch | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by SamB): And now I have no clue what in the world this is doing, because when I try to use it to trace the cause of errors in JHC, the trace appears, but the "fail" or "error" call passed as the second argument to traceCcs# doesn't seem to happen :-(. Please assist! Did I do something really stupid? Is something missing from the documentation? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 07:15:44 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 07:11:27 2008 Subject: [GHC] #2177: Can Data.Unique safely derive Typeable? In-Reply-To: <045.8724b926d6549afcfc85d1a3ada0af59@localhost> References: <045.8724b926d6549afcfc85d1a3ada0af59@localhost> Message-ID: <054.516b478d913478282255f6cf6aaef105@localhost> #2177: Can Data.Unique safely derive Typeable? -----------------------------+---------------------------------------------- Reporter: japple | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by japple): I was asking for the first. The second seems unreasonable. The third would be lovely. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 17:47:04 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 17:42:48 2008 Subject: [GHC] #2195: yi: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c436730a In-Reply-To: <044.cc96d7cce62f73d5dee217e7be0e7f3f@localhost> References: <044.cc96d7cce62f73d5dee217e7be0e7f3f@localhost> Message-ID: <053.c7560d33e91b5f6c9616dc9f83be3ba1@localhost> #2195: yi: internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c436730a ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: linker | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: see #2013 upshot: we need a way to do `mmap(... MAP_32BIT ...)` on FreeBSD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 17:47:36 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 17:43:23 2008 Subject: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of range. In-Reply-To: <044.2f007075e8a3e652be5aa7c77056c714@localhost> References: <044.2f007075e8a3e652be5aa7c77056c714@localhost> Message-ID: <053.3083a7a4bfcc7e0148b3e57b1d929f2a@localhost> #2013: ghci crash on startup: R_X86_64_32S relocation out of range. ---------------------+------------------------------------------------------ Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ---------------------+------------------------------------------------------ Comment (by simonmar): See also #2195 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 17:57:27 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 17:53:12 2008 Subject: [GHC] #2191: A way to programmatically cause GHC to report the cost center stack associated with a value In-Reply-To: <043.3641dba02e220ac3643aa7a87adf7815@localhost> References: <043.3641dba02e220ac3643aa7a87adf7815@localhost> Message-ID: <052.abff1e2991e596a8cdccd1078c1bb8cc@localhost> #2191: A way to programmatically cause GHC to report the cost center stack associated with a value --------------------------------+------------------------------------------- Reporter: SamB | Owner: SamB Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: patch | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Changes (by SamB): * owner: => SamB -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 18:03:46 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 17:59:27 2008 Subject: [GHC] #2197: GHCi doesn't work when built with way=p In-Reply-To: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> References: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> Message-ID: <052.4187069be581a7f543f347e5a3bd4f5c@localhost> #2197: GHCi doesn't work when built with way=p --------------------+------------------------------------------------------- Reporter: SamB | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------+------------------------------------------------------- Changes (by simonmar): * priority: normal => low * difficulty: => Unknown * owner: => simonmar * milestone: => 6.10 branch Comment: GHCi + profiling doesn't work for deeper reasons than this: it would require a lot of work in the byte-code compiler and interpreter. If you try 'ghci -prof' you get an error message, but in this case you built GHCi itself with -prof and tried to use it. I'll make it so that GHCi fails with a helpful error message earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Apr 7 20:53:59 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 20:49:44 2008 Subject: [GHC] #2202: type error causes type checker stack overflow Message-ID: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> #2202: type error causes type checker stack overflow -----------------------+---------------------------------------------------- Reporter: chiral | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- The following code causes {{{ *** Exception: stack overflow }}} during type checking. I've tried to whittle the test case down, this may not be minimal. The {{{(Ord a)}}} instances and the unused {{{vertexID}}} member of the datatype seem to be necessary, otherwise the infinite type is correctly caught. Does not occur under 6.6.1 {{{ module GHCBug( MeshVertex(..) ) where data (Ord a) => MeshVertex a b = MeshVertex { vertexID :: a, vertexChildren :: [a] } deriving (Show) split :: (Ord a) => a -> [MeshVertex a b] -> [MeshVertex a b] split a m = let av = head m newVTs = preSplit a m av' = av { vertexChildren = newVTs } newMVs = av' : m newMesh = newMVs in newMesh preSplit :: (Ord a) => a -> [MeshVertex a b] -> [MeshVertex a b] preSplit a m = preSplit a $ split a m }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:03:39 2008 From: trac at galois.com (GHC) Date: Mon Apr 7 23:59:27 2008 Subject: [GHC] #2203: TFs in class instances heads Message-ID: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> #2203: TFs in class instances heads -------------------------+-------------------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Ganesh posted the following example on haskell-cafe: {{{ {-# LANGUAGE ScopedTypeVariables, TypeFamilies, FlexibleInstances #-} module Test1a where class Foo a where type TheFoo a foo :: TheFoo a -> a foo' :: a -> Int class Bar b where bar :: b -> Int instance Foo a => Bar (Either a (TheFoo a)) where bar (Left a) = foo' a bar (Right b) = foo' (foo b :: a) instance Foo Int where type TheFoo Int = Int foo = id foo' = id val :: Either Int Int val = Left 5 res :: Int res = bar val }}} It fails to type check as the type of `bar` cannot be inferred. However, GHC should reject the instance due to the TF in the head despite `FlexibleInstances`. Moreover, the corrected code {{{ {-# LANGUAGE ScopedTypeVariables, TypeFamilies, UndecidableInstances #-} module Test1a where class Foo a where type TheFoo a foo :: TheFoo a -> a foo' :: a -> Int class Bar b where bar :: b -> Int instance (b ~ TheFoo a, Foo a) => Bar (Either a b) where bar (Left a) = foo' a bar (Right b) = foo' (foo b :: a) instance Foo Int where type TheFoo Int = Int foo = id foo' = id val :: Either Int Int val = Left 5 res :: Int res = bar val }}} requires `UndecidableInstances`, although it shouldn't. We should be able to allow equalities of the form `tv ~ F tv1 .. tvn` with tv and tvi being distinct type variables without requiring `UndecidableInstances`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:11:19 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 00:07:40 2008 Subject: [GHC] #1673: Template Haskell support for type families In-Reply-To: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> References: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> Message-ID: <074.5a8f5cdee5185f586e21b3ef3a6621c5@localhost> #1673: Template Haskell support for type families ----------------------------------------+----------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.10 branch Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Changes (by hpacheco): * cc: ganesh@earth.li (removed) * cc: hpacheco@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:11:45 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 00:08:00 2008 Subject: [GHC] #1673: Template Haskell support for type families In-Reply-To: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> References: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> Message-ID: <074.c06eb8216cf2af4275455f4eb05a7165@localhost> #1673: Template Haskell support for type families ----------------------------------------+----------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.10 branch Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Changes (by hpacheco): * cc: ganesh@earth.li (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:12:19 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 00:08:05 2008 Subject: [GHC] #2151: GADTs in function Patterns In-Reply-To: <047.2f6478e8e827595da4825a54c1ec722c@localhost> References: <047.2f6478e8e827595da4825a54c1ec722c@localhost> Message-ID: <056.8ab7dda91bf3150ce10c293122aee09e@localhost> #2151: GADTs in function Patterns ----------------------+----------------------------------------------------- Reporter: hpacheco | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by hpacheco): * cc: hpacheco@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:12:40 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 00:08:25 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.d59337f27253f933d228a8600b60e13d@localhost> #2157: Equality Constraints with Type Families -------------------------------------+-------------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by hpacheco): * cc: hpacheco@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 00:19:00 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 00:15:16 2008 Subject: [GHC] #1673: Template Haskell support for type families In-Reply-To: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> References: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> Message-ID: <074.99414017f6e3209afb1dc59d80a29f65@localhost> #1673: Template Haskell support for type families ----------------------------------------+----------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.10 branch Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Comment (by hpacheco): Myself, I would simply like to be able to write TH code to automatically generate type family instances. However, I understand it is not a very important feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 06:53:00 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 06:48:51 2008 Subject: [GHC] #2203: TFs in class instances heads In-Reply-To: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> References: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> Message-ID: <052.06b6b48feb1cab964a2a4132b336760f@localhost> #2203: TFs in class instances heads ----------------------------------------+----------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Changes (by claus): * cc: claus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 13:17:45 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 13:13:23 2008 Subject: [GHC] #2204: Improve 'patterns not matched' warnings Message-ID: <047.57470c7515f5d78414f8813f455c57a5@localhost> #2204: Improve 'patterns not matched' warnings -------------------------+-------------------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: trivial Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Compiling the following with `-fwarn-incomplete-patterns`: {{{ module Asdf where f :: String -> Int f "0" = 0 g :: Int -> Int g 0 = 0 }}} Yields: {{{ asdf.hs:4:0: Warning: Pattern match(es) are non-exhaustive In the definition of `f': Patterns not matched: [] (GHC.Base.C# #x) : _ with #x `notElem` ['0'] (GHC.Base.C# '0') : (_ : _) asdf.hs:7:0: Warning: Pattern match(es) are non-exhaustive In the definition of `g': Patterns not matched: GHC.Base.I# #x with #x `notElem` [0#] }}} Losing the 'GHC.Base' stuff along with the various octothorpes would make the error messages a lot nicer. Ideally it'd be something like `Patterns not matched: x where x `notElem` [0]` for the second case, for instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 21:08:00 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 21:03:42 2008 Subject: [GHC] #2205: infix type constructors seem to ignore associativity Message-ID: <047.d51a18254711f69f4bc5b63ba9a2a2c6@localhost> #2205: infix type constructors seem to ignore associativity -------------------------+-------------------------------------------------- Reporter: gckeller | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- In the following program, fst3 and fst3' should be equivalent, but fst3' but fst3' leads to type error: {{{ module Main where infixr 0 :-> data a :-> b = P a b fst3:: (a :-> (b :-> c)) -> a fst3 (P a (P b c)) = a fst3':: (a :-> b :-> c) -> a fst3' (P a (P b c)) = a main = putStrLn $ show $ fst3 (P True (P False True)) }}} the type error is: {{{ TypeConstr.hs:11:0: Occurs check: cannot construct the infinite type: a = a :-> b When generalising the type(s) for `fst3'' }}} pulled last changes on 7/4/2008 (used to work correctly before) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Apr 8 23:49:39 2008 From: trac at galois.com (GHC) Date: Tue Apr 8 23:45:30 2008 Subject: [GHC] #2202: type error causes type checker stack overflow In-Reply-To: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> References: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> Message-ID: <054.5d8033dbb9ac6da31e08e6346bf5f310@localhost> #2202: type error causes type checker stack overflow ----------------------------------------+----------------------------------- Reporter: chiral | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Other | Os: Other ----------------------------------------+----------------------------------- Changes (by chak): * owner: => chak * os: MacOS X => Other * architecture: x86 => Other -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 9 11:51:13 2008 From: trac at galois.com (GHC) Date: Wed Apr 9 11:46:46 2008 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@localhost> References: <047.bea78f01cbb904765ad77c751bc8d3af@localhost> Message-ID: <056.d1bc960876c1e9b3e84002394074792f@localhost> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: normal | Resolution: None Keywords: warnings | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): And #2204 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 9 11:52:30 2008 From: trac at galois.com (GHC) Date: Wed Apr 9 11:48:04 2008 Subject: [GHC] #2204: Improve 'patterns not matched' warnings In-Reply-To: <047.57470c7515f5d78414f8813f455c57a5@localhost> References: <047.57470c7515f5d78414f8813f455c57a5@localhost> Message-ID: <056.60098b7006ba497946e26242955638d9@localhost> #2204: Improve 'patterns not matched' warnings ----------------------+----------------------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by simonpj): * priority: normal => low * difficulty: => Unknown * milestone: => _|_ Comment: Yes indeed. I think it'd make sense to do this as part of #595. Which is currently awaiting a keen author. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 9 12:21:18 2008 From: trac at galois.com (GHC) Date: Wed Apr 9 12:17:18 2008 Subject: [GHC] #2202: type error causes type checker stack overflow In-Reply-To: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> References: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> Message-ID: <054.c68af448c1ddcbfa2e272c22ae50e0bf@localhost> #2202: type error causes type checker stack overflow -------------------------------------+-------------------------------------- Reporter: chiral | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Other Os: Other | -------------------------------------+-------------------------------------- Changes (by simonpj): * cc: bdonlan@gmail.com (added) * difficulty: => Unknown Comment: I believe this bug from Bryan Donlan is closely related. (He sent the report by email; I don't think there's a ticket for it.) I propose not to chase it down until Manuel has fixed this ticket (he is on the job). Then let's re-investigate. Simon I've found a case where GHC will hang (consuming more and more memory) when it should report an occurs check error. The test case is at [http://fushizen.net/~bd/kaos-ghc-loop.tgz] - the error in question is that the arguments in the `StateT` instance for `HOLift` are reversed like so: {{{ diff --git a/src/Kaos/KaosM.hs b/src/Kaos/KaosM.hs index ec4e69a..268250a 100644 --- a/src/Kaos/KaosM.hs +++ b/src/Kaos/KaosM.hs @@ -88,7 +88,7 @@ genlift' unbox box f m = box $ \s -> f (unbox m s) class HOLift m b | m -> b where genlift :: (forall r'. b r' -> b r') -> (forall r. m r -> m r) -instance HOLift m (StateT s m) where +instance HOLift (StateT s m) m where genlift = genlift' runStateT StateT instance (HOLift m b, KaosDiagM r b) => KaosDiagM r m where }}} I'm using GHC 6.8.2 on ubuntu hardy. Bryan Donlan -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Apr 9 15:13:09 2008 From: trac at galois.com (GHC) Date: Wed Apr 9 15:08:46 2008 Subject: [GHC] #2052: hpc ignores files containing LINES pragmas that refer to .hsc files In-Reply-To: <043.13a31077ae5ebb133355743a92fc5086@localhost> References: <043.13a31077ae5ebb133355743a92fc5086@localhost> Message-ID: <052.8e37976422bccd14c154c8c4d0d2d8d1@localhost> #2052: hpc ignores files containing LINES pragmas that refer to .hsc files ---------------------------+------------------------------------------------ Reporter: dons | Owner: AndyGill Type: bug | Status: assigned Priority: normal | Milestone: 6.8.3 Component: Code Coverage | Version: 6.8.2 Severity: normal | Resolution: Keywords: hpc, hsc2hs | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Changes (by AndyGill): * status: new => assigned * owner: andy@galois.com => AndyGill Comment: It is not quite that easy, because the Span info has been messed up. Typically this just effects the error messages, but here the info *has* to be correct for hpc to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 05:03:02 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 04:58:37 2008 Subject: [GHC] #2205: infix type constructors seem to ignore associativity In-Reply-To: <047.d51a18254711f69f4bc5b63ba9a2a2c6@localhost> References: <047.d51a18254711f69f4bc5b63ba9a2a2c6@localhost> Message-ID: <056.4e0264f4cc7aa92816487949483aa2c6@localhost> #2205: infix type constructors seem to ignore associativity -------------------------------+-------------------------------------------- Reporter: gckeller | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2205 | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonpj): * testcase: => T2205 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Caused by {{{ Fri Apr 4 13:55:56 PDT 2008 simonpj@microsoft.com * Fix Trac #2188: scoping in TH declarations quotes }}} Fixed by {{{ Thu Apr 10 09:58:03 BST 2008 simonpj@microsoft.com * Fix Trac #2205, which I introduced recently }}} I will push shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 05:58:51 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 05:54:23 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.cceace0a78cffe9eadd600633c23f5e2@localhost> #2044: "Can't unify" error in debugger --------------------+------------------------------------------------------- Reporter: r6144 | Owner: pepe Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by simonpj): * owner: simonpj => pepe Comment: The "can't unify" message comes from `RtsClosureInspect`, which is Pepe and Simon's debugger. I suspect it's confused by the for-all in the type. Ian is right, incidentally, that the short program he gives should be rejected unless you specify `-XImpredicativeTypes`. So I'm assigning this bug to Pepe. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Apr 10 05:59:40 2008 From: trac at galois.com (GHC) Date: Thu Apr 10 05:55:13 2008 Subject: [GHC] #2044: "Can't unify" error in debugger In-Reply-To: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> References: <044.9de84d1571c81bf2b4030ee1192776b2@localhost> Message-ID: <053.abe9a775ca35281fae928eea8799615e@localhost> #2044: "Can't unify" error in debugger --------------------+--------------