From trac at galois.com Sun Feb 1 07:07:06 2009 From: trac at galois.com (GHC) Date: Sun Feb 1 06:57:21 2009 Subject: [GHC] #2995: ghc -Wall does not complain about unnecessary data constructor imports Message-ID: <048.f0e44db11fec5519d682367c28fd6c91@localhost> #2995: ghc -Wall does not complain about unnecessary data constructor imports -----------------------------+---------------------------------------------- Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- If it is enough to import: import SomeModule(SomeType) Then ghc should complain (warn) when importing: import SomeModule(SomeType(..)) or: import SomeModule(SomeType(SomeConstructor)) But it doesn't output any complaint or warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 1 09:08:30 2009 From: trac at galois.com (GHC) Date: Sun Feb 1 08:58:52 2009 Subject: [GHC] #2658: Extreme memory usage (probably type functions) In-Reply-To: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> References: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> Message-ID: <053.9bc22f8ab99b6e83e931eb19d90e9b8f@localhost> #2658: Extreme memory usage (probably type functions) ----------------------------------------+----------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (Type checker) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ----------------------------------------+----------------------------------- Comment (by guest): Any news on this? It's been outstanding for a while and is still present and is hampering research I'm doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 1 12:41:32 2009 From: trac at galois.com (GHC) Date: Sun Feb 1 12:31:46 2009 Subject: [GHC] #2996: Network.Socket.sClose should change socket status Message-ID: <046.41f89e25a108f554724958983d75e152@localhost> #2996: Network.Socket.sClose should change socket status -----------------------------+---------------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The current implementation of sClose in Network.Socket leaves the socket in a Connected state but frees the underlying OS resource. Thus, any further operations on the socket may apply to a ''different'' OS object if something else was assigned the same FD after the socket was closed. For example, sClose'ing the socket a second time can lead to some arbitrary other file or socket being closed. The attached test case was run in ghci 6.8.2 on Debian Linux sid, though by inspection of the Network.Socket source in 6.10.1, this is still present and the test case should work. It takes advantage of the way *NIX allocates file descriptors to demonstrate specific misbehaviors, so may or may not misbehave in the intended way on other platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 1 13:19:28 2009 From: trac at galois.com (GHC) Date: Sun Feb 1 13:09:43 2009 Subject: [GHC] #2997: Package names starting with a numeric character cause assembler errors Message-ID: <044.06fddb0d2b915fea9056d01f9dd6ea43@localhost> #2997: Package names starting with a numeric character cause assembler errors -----------------------------+---------------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Hi, When trying to compile a package named 9pH, I get the following error: {{{ /usr/bin/ghc -O -package-name 9pH-0.1 --make -XOverloadedStrings -XPatternGuards -XTemplateHaskell Network.GpH.Protocol.Derive [1 of 1] Compiling Network.GpH.Protocol.Derive ( Network/GpH/Protocol/Derive.hs, Network/GpH/Protocol/Derive.o ) /tmp/ghc4263_0/ghc4263_0.s: Assembler messages: /tmp/ghc4263_0/ghc4263_0.s:18137:0: Error: junk at end of line, first unrecognized character is `9' /tmp/ghc4263_0/ghc4263_0.s:18165:0: Error: junk at end of line, first unrecognized character is `9' /tmp/ghc4263_0/ghc4263_0.s:18166:0: Error: unrecognized symbol type "9" /tmp/ghc4263_0/ghc4263_0.s:18166:0: Error: junk at end of line, first unrecognized character is `p' /tmp/ghc4263_0/ghc4263_0.s:18167:0: Error: junk at end of line, first unrecognized character is `9' /tmp/ghc4263_0/ghc4263_0.s:18168:0: Error: junk at end of line, first unrecognized character is `p' /tmp/ghc4263_0/ghc4263_0.s:18172:0: Error: junk at end of line, first unrecognized character is `p' /tmp/ghc4263_0/ghc4263_0.s:18245:0: Error: junk at end of line, first unrecognized character is `p' ... }}} It turns out that if I remove '-package-name 9pH-0.1' from the command line, or change the package name, then the compilation completes without error. It seems that either: 1. Package names starting with numeric characters should be banned. In which case it should be clearly documented in the user's guide and/or in the cabal manual and the compiler should check this early on in the compilation. 2. Package names starting with a numeric character should be allowed. In which case package names should be mangled appropriately to avoid having the assembler complain. In my view option 2 would be preferable. Many thanks, Mathieu -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 1 17:20:58 2009 From: trac at galois.com (GHC) Date: Sun Feb 1 17:11:12 2009 Subject: [GHC] #2996: Network.Socket.sClose should change socket status In-Reply-To: <046.41f89e25a108f554724958983d75e152@localhost> References: <046.41f89e25a108f554724958983d75e152@localhost> Message-ID: <055.7d81ac13f6da535e83cec2375f639fe7@localhost> #2996: Network.Socket.sClose should change socket status -------------------------------+-------------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by amthrax): I should mention that closed-state.patch is against the 6.8.2 network library. It applies cleanly (with offsets) against the 6.10.1 library, but I can't test it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 1 18:13:00 2009 From: trac at galois.com (GHC) Date: Sun Feb 1 18:03:13 2009 Subject: [GHC] #2998: Expose the internals of the network library to make it more extensible Message-ID: <044.38e242663cf791489f4226de94cd9e56@localhost> #2998: Expose the internals of the network library to make it more extensible -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- When creating new libraries on top of the network library it would be convenient if the library exposed some functions that hide platform variations so that the new libraries can be written in a portable manner. Take for example the currently un-exported `pokeSockAddr` function which marshalls a `SockAddr` into a `sockaddr` struct. This function would be useful when e.g. writing a binding for the `sendmsg` system call. However, it's not exported so libraries are forced to define their own version. This is unfortunate. I propose we add a new module, `Network.Socket.Internal`, to the network library, that exposes these portable marshalling functions. It might also be a good idea to expose some internal data representations in the same way bytestring currently does. People who write code that uses this internal do so knowing that there is a risk that the interface and data representations might change. I've written a patch that exposes some of the library's internal functions. There are still some documentation to write and perhaps a few more functions to expose but I think we should reach consensus on whether this is a good idea to begin with before continuing. Since this change isn't disruptive I propose a two week consideration deadline. Cabal package: http://johantibell.com/network-2.2.1.tar.gz Haddock: http://johantibell.com/network/doc/html/network/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 1 18:35:07 2009 From: trac at galois.com (GHC) Date: Sun Feb 1 18:25:22 2009 Subject: [GHC] #2709: System.Directory.doesDirectoryExist "\\" is False on Windows In-Reply-To: <047.62ffe3d738f377c87f772b23e67bd03b@localhost> References: <047.62ffe3d738f377c87f772b23e67bd03b@localhost> Message-ID: <056.43c80ba169095b7b6e91031b31f4695f@localhost> #2709: System.Directory.doesDirectoryExist "\\" is False on Windows ------------------------------------+--------------------------------------- Reporter: Deewiant | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * cc: ndmitchell@gmail.com (added) Comment: I think treating "\\" as not a drive is probably the right behaviour, so a patch along these lines should be applied to `System/FilePath/Internal.hs`; Neil, does that sound good to you? {{{ -- > dropTrailingPathSeparator "file/test/" == "file/test" -- > not (hasTrailingPathSeparator (dropTrailingPathSeparator x)) || isDrive x -- > Posix: dropTrailingPathSeparator "/" == "/" +-- > Windows: dropTrailingPathSeparator "\\" == "\\" dropTrailingPathSeparator :: FilePath -> FilePath dropTrailingPathSeparator x = if hasTrailingPathSeparator x && not (isDrive x) - then reverse $ dropWhile isPathSeparator $ reverse x + then let x' = reverse $ dropWhile isPathSeparator $ reverse x + in if null x' then [pathSeparator] else x' else x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 1 19:36:10 2009 From: trac at galois.com (GHC) Date: Sun Feb 1 19:26:27 2009 Subject: [GHC] #2913: OldException's catch etc should treat new Exception types as DynException's In-Reply-To: <044.32b88c5c6278c8a1dcec6524f5b05c54@localhost> References: <044.32b88c5c6278c8a1dcec6524f5b05c54@localhost> Message-ID: <053.26fd31b7e44c59f3f2f3eb8aaa47c1f2@localhost> #2913: OldException's catch etc should treat new Exception types as DynException's ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 04:09:10 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 03:59:22 2009 Subject: [GHC] #2986: :info printing instances often isn't wanted In-Reply-To: <043.cc7348275a1e64e6491d1ee94042b0a6@localhost> References: <043.cc7348275a1e64e6491d1ee94042b0a6@localhost> Message-ID: <052.fb806a567f7585886c2f412c8b1d1964@localhost> #2986: :info printing instances often isn't wanted ---------------------------------+------------------------------------------ Reporter: Remi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: :info instances | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): I don't particularly care either! But as your follow-up comment points out, it's easy to design a UI and forget something -- in this case I'd forgotten the useful :i abbreviation. So there is real design work to do. It's easier to point out a missing feature than to design the feature to fill the hole. So what I'm suggesting is that someone (you, if you like) incites a debate and helps it towards a consensus. That doesn't need GHC HQ. Then we (or indeed someone else) can implement it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 06:22:17 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 06:12:30 2009 Subject: [GHC] #2997: Package names starting with a numeric character cause assembler errors In-Reply-To: <044.06fddb0d2b915fea9056d01f9dd6ea43@localhost> References: <044.06fddb0d2b915fea9056d01f9dd6ea43@localhost> Message-ID: <053.ccae35831d34174bfdfe4d7ee8e009f5@localhost> #2997: Package names starting with a numeric character cause assembler errors ---------------------------------+------------------------------------------ Reporter: mboes | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => igloo * difficulty: => Unknown Comment: I agree with (2). If digits aren't acceptable as leading characters we'd better encode them. I think the fix is simple: * In `Encoding.zEncodeString` treat the first character specially, by z-encoding even digits (which are not otherwise encode). A good encoding would be `0 --> z0` etc. * Similarly in decoding we'd need to treat the first character specially. Alternatively we could *always* z-encode digits. But that seems overkill (eg `base-3.5` would become `basezmz3ziz5` rather than (as now) `basezm3zi5`). But it's no big deal either way. Ian would you like to decide and execute? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 06:24:08 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 06:14:21 2009 Subject: [GHC] #2267: Bogus "unused import" warning In-Reply-To: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> References: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> Message-ID: <055.ac872c5ef62c67ccc4c2bc7d36911905@localhost> #2267: Bogus "unused import" warning ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): See also #2995 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 08:16:20 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 08:06:31 2009 Subject: [GHC] #2990: "GHC Commentary: The byte-code interpreter and dynamic linker " is empty In-Reply-To: <043.129af6995c79ba29401862c98a48b859@localhost> References: <043.129af6995c79ba29401862c98a48b859@localhost> Message-ID: <052.4f2e0a9ebb1bc1fab312f078545a01e7@localhost> #2990: "GHC Commentary: The byte-code interpreter and dynamic linker " is empty ------------------------------+--------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by SamB): Actually, there are a number of empty commentary pages, so I created wiki:CategoryStub to help keep track of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 08:25:03 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 08:15:13 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.5e605054bd392ac1317b7fb58959dfa5@localhost> #2953: deriving Functor, Foldable, Traversable ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: twanvl Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: igloo => twanvl * difficulty: => Unknown Comment: Dear twanval Thanks for doing this. I've taken a look, polished a little, and will commit shortly. What is missing is a section in the user manual describing the changes. You need a section in 8.5 describing the feature, and suitable update in the flag-reference parts too. By "describing the feature" I mean that you should explain what does and doesn't work; in particular, about the special cases for tuples and functions. I've added some comments in the code, in `TcGenDeriv` for `Functor` to help myself understand, that may help as a starting point. Could you manage to do that? I will commit the patch meanwhile, but it's really incomplete without the documentation. Many thanks Simon PS: Looking at the code, I do agree with you that * Checking the side conditions * Generating the constraints could be combined. Perhaps the `CanDerive` constructor should contain a list of constraints? If you felt like doing this, great. That would eliminate one traversal, and tidy up the code a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 08:36:10 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 08:26:21 2009 Subject: [GHC] #2987: panic when compiling again In-Reply-To: <047.ad4a56debe0fa0023bf1923dd30e1509@localhost> References: <047.ad4a56debe0fa0023bf1923dd30e1509@localhost> Message-ID: <056.e242287fa5536f77451554aeaa6e967a@localhost> #2987: panic when compiling again ---------------------------------+------------------------------------------ Reporter: dsrogers | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => igloo Comment: Simon and I investigated. There are two different things going on. * First, Cabal triggers a complete rebuild for `cabal install` because Cabal gives different package flags to GHC in `cabal build` and `cabal install`. This is because its package-planning algorithm is different in the two cases. Apparently this infelicity has now been fixed. For reasons I don't fully understand, Cabal doesn't always do this; it broke for Simon M, but did not break for me, although we were using the exact same GHC. * However, GHC should not crash, regardless. Turns out that it was tricky consequence of this patch: {{{ Tue Feb 5 16:55:07 GMT 2008 simonpj@microsoft.com * Inject implicit bindings before the simplifier (Trac #2070) }}} This patch was an unequivocally bad idea. I reversed it in the HEAD a few weeks back, and commented why in `Note [Injecting implicit bindings]` in `TidyPgm`. I fixed #2070 in a different way: {{{ Fri Jan 2 14:28:51 GMT 2009 simonpj@microsoft.com * Make record selectors into ordinary functions }}} So I think the bug should not happen in the HEAD. For the 6.10 branch I suggest that we simply reverse the above patch ''on the branch only''; it was only an optimisation thing anyway. Ian, would you like to do that? It's a bit hard to test whether it fixes the bug, because of the delicacy about Cabal above. I'd settle for just reversing the patch and checking that the branch still validates. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 08:53:34 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 08:43:46 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.e069e37ea84ba2d27da8ff09ae6f7f4f@localhost> #2953: deriving Functor, Foldable, Traversable ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: twanvl Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): PS: there's just one flag to control all three new classes, namely `-XDeriveFunctor`. Is that the right name? Is there a term that would cover all three? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 08:54:59 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 08:45:10 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.e5b6e3b3dd85c9e21e1d1f05e5a4276a@localhost> #2953: deriving Functor, Foldable, Traversable ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: twanvl Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): PPS: The patch I have pushed is: {{{ Mon Feb 2 13:48:29 GMT 2009 simonpj@microsoft.com * Add the ability to derive instances of Functor, Foldable, Traversable }}} DO NOT use twanvl's patches! I un-recorded them, polished, and re- recorded a single patch. If you use twanvl's as well, chaos will result. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 09:26:57 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 09:17:09 2009 Subject: [GHC] #2990: "GHC Commentary: The byte-code interpreter and dynamic linker " is empty In-Reply-To: <043.129af6995c79ba29401862c98a48b859@localhost> References: <043.129af6995c79ba29401862c98a48b859@localhost> Message-ID: <052.7446cfbe7dea7a953df5eb73e86308d1@localhost> #2990: "GHC Commentary: The byte-code interpreter and dynamic linker " is empty ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks for making the wiki page. It sounds more useful than this bug report, so I'm closing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 09:56:17 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 09:46:29 2009 Subject: [GHC] #2588: Missed suggestion with context on foralls In-Reply-To: <051.f82176fc0c07b1750e90df780f097cc7@localhost> References: <051.f82176fc0c07b1750e90df780f097cc7@localhost> Message-ID: <060.e8a10c98c733126f79bf5c7727bd9b7a@localhost> #2588: Missed suggestion with context on foralls ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Good idea. would work nicely for {{{ f :: forall -> forall }}} The difficulty is that the ''parser'' reports a parse '''error''' in your example, and errors trump warnings. So I'm still not sure how to do this neatly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 12:16:33 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 12:06:43 2009 Subject: [GHC] #2993: Precedence errors are reported for undefined operators In-Reply-To: <045.dc49aabd93adad128f189ed9b9b23308@localhost> References: <045.dc49aabd93adad128f189ed9b9b23308@localhost> Message-ID: <054.39c62af375eb77825fb8403a4b1d663a@localhost> #2993: Precedence errors are reported for undefined operators -----------------------------------------+---------------------------------- Reporter: Olathe | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rename/should_fail/T2993 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * testcase: => rename/should_fail/T2993 * difficulty: => Unknown * type: feature request => merge * owner: => igloo Comment: A good idea for a snowy day {{{ Mon Feb 2 16:44:50 GMT 2009 simonpj@microsoft.com * Improve error reporting for precedence errors }}} Possibly worth merging. But watch out... `TypeRep` now exports `funTyConName` so there's an import patch to Haddock that must go too: {{{ Mon Feb 2 16:47:42 GMT 2009 simonpj@microsoft.com * Hide funTyConName, now exported by TypeRep }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 14:58:03 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 14:48:20 2009 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.20fd6b5f887f9954cfbbc3dd3b0479ab@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -------------------------------+-------------------------------------------- Reporter: tim | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 15:00:23 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 14:50:33 2009 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@localhost> References: <042.bfabde61c4aa31a17887ff9436d679ab@localhost> Message-ID: <051.8a4177cf104a8b3057315822a837f5fa@localhost> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work ---------------------------------+------------------------------------------ Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 15:28:57 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 15:19:08 2009 Subject: [GHC] #2860: Redundant unblocking in POSIX generic_handler In-Reply-To: <042.2727ad23f19fb18f0134c48d09681776@localhost> References: <042.2727ad23f19fb18f0134c48d09681776@localhost> Message-ID: <051.cf3883d11a11ebac3d02923c51efb8fe@localhost> #2860: Redundant unblocking in POSIX generic_handler --------------------------------------+------------------------------------- Reporter: dsh | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: trivial | Resolution: Keywords: POSIX generic_handler | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Referring to: {{{ sigprocmask(SIG_UNBLOCK, &signals, NULL); }}} at the end of `generic_handler` in `rts/posix/Signals.c`, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 15:37:08 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 15:27:19 2009 Subject: [GHC] #2870: User signals are not blocked before 'fork' in runInteractiveProcess In-Reply-To: <042.e53acc7954108a66f75c2330d39f6f71@localhost> References: <042.e53acc7954108a66f75c2330d39f6f71@localhost> Message-ID: <051.a8ae54083ae7203277605f3e9957b60e@localhost> #2870: User signals are not blocked before 'fork' in runInteractiveProcess -----------------------------------------------+---------------------------- Reporter: dsh | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/process | Version: 6.10.1 Severity: normal | Resolution: Keywords: threaded runInteractiveProcess | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -----------------------------------------------+---------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the patch! We'll take a look for 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 15:43:23 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 15:33:33 2009 Subject: [GHC] #2871: "Prologue junk?" error when building GHC In-Reply-To: <047.340efbd5b95f62aac88650d45afdbdde@localhost> References: <047.340efbd5b95f62aac88650d45afdbdde@localhost> Message-ID: <056.727fc2041d1941cdf722b0b4c5a50da8@localhost> #2871: "Prologue junk?" error when building GHC -------------------------+-------------------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report, we'll take a look -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 15:44:43 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 15:34:53 2009 Subject: [GHC] #2872: sparc -mcpu=v9 is not used in assembly phase In-Reply-To: <045.560447626eec7a2ff3f9465e35a5352d@localhost> References: <045.560447626eec7a2ff3f9465e35a5352d@localhost> Message-ID: <054.a89bf1311bbd2471c6b50ad51e190aa3@localhost> #2872: sparc -mcpu=v9 is not used in assembly phase -------------------------+-------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 15:53:56 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 15:44:14 2009 Subject: [GHC] #2874: Error message doesn't mention extension that is missing In-Reply-To: <044.244748ee082046ce491869b3d395636a@localhost> References: <044.244748ee082046ce491869b3d395636a@localhost> Message-ID: <053.0e02c097e50836019a2a8cd6fdfb921c@localhost> #2874: Error message doesn't mention extension that is missing ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: Unreproducible, and no testcase, so closing this ticket. Please reopen if you have a testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 15:56:50 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 15:47:04 2009 Subject: [GHC] #2877: crash when printig a list (IO ()) In-Reply-To: <044.0933e1ca77e0ef5175110397abfb4837@localhost> References: <044.0933e1ca77e0ef5175110397abfb4837@localhost> Message-ID: <053.e97610cf411c0f0aace6430af184944f@localhost> #2877: crash when printig a list (IO ()) -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:00:07 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 15:50:17 2009 Subject: [GHC] #2878: panic while compiling Cabal-1.6.0.1 In-Reply-To: <045.546c16a32de57181a9229bd36cb27ab8@localhost> References: <045.546c16a32de57181a9229bd36cb27ab8@localhost> Message-ID: <054.86f3d3407566c74aaf092e853ffaf40d@localhost> #2878: panic while compiling Cabal-1.6.0.1 -------------------------------+-------------------------------------------- Reporter: dvogel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: major | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:01:06 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 15:51:16 2009 Subject: [GHC] #2879: ghci : set - unset In-Reply-To: <049.d50946bf3230c8feb2683a1944bd9785@localhost> References: <049.d50946bf3230c8feb2683a1944bd9785@localhost> Message-ID: <058.8763d8014e3cc9a17043edd6d59983e4@localhost> #2879: ghci : set - unset ---------------------------------+------------------------------------------ Reporter: rileyrgdev | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:01:51 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 15:52:24 2009 Subject: [GHC] #2883: setitimer(ITIMER_VIRTUAL) is not always available In-Reply-To: <047.b40f4ae8b455c2e4eb614a1510a0781b@localhost> References: <047.b40f4ae8b455c2e4eb614a1510a0781b@localhost> Message-ID: <056.4fe44231126233fed776236e7b6ec5e2@localhost> #2883: setitimer(ITIMER_VIRTUAL) is not always available ---------------------------------+------------------------------------------ Reporter: sthibaul | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the patch! We'll take a look -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:10:29 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:00:40 2009 Subject: [GHC] #2889: Compilation fails - Can't opne temporary In-Reply-To: <046.8fe469503d4d0471dd07d5bc59e9501a@localhost> References: <046.8fe469503d4d0471dd07d5bc59e9501a@localhost> Message-ID: <055.96287d9e82e2cea661a0d9c1c8c9b467@localhost> #2889: Compilation fails - Can't opne temporary -------------------------+-------------------------------------------------- Reporter: fobrock | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:11:01 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:01:20 2009 Subject: [GHC] #2892: (threadDelay (-1)) hangs In-Reply-To: <045.cacf950ebeacdae764843c5be42d3ce1@localhost> References: <045.cacf950ebeacdae764843c5be42d3ce1@localhost> Message-ID: <054.cbe85d5e499fbba453ffd5f6acf7bf14@localhost> #2892: (threadDelay (-1)) hangs -------------------------+-------------------------------------------------- Reporter: dancor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > threadDelay silently hangs forever given a negative delay interval. It > seems like this should at least be documented, but further is probably > suboptimal magical behavior that leads to harder-to-find bugs; instead > this should be an error. Conceivably threadDelay could take Maybe Int > but that seems kind of out there. > > Here is some discussion from #haskell: > 06:39 < dancor> do other ppl agree that (threadDelay (-1)) hanging > silently is > bug? > 06:39 < dancor> i guess you might want infinite hang, hm > 06:39 < Cale> dancor: I think I might agree with that, though now that > you > mention it, it's very handy. > 06:39 < Cale> dancor: A lot of things which would cause a thread to block > forever will throw an exception and kill the thread. > 06:40 < Cale> (an exception which you'd often wish were silent) > 06:40 < Cale> But threadDelay is the wrong place for that > 06:40 < b_jonas> dancor: yeah, the thread should just be garbage- > collected > 06:42 * quicksilver uses "forever (threadDelay maxBound)" > > I'm on Debian lenny: > ~ uname -a > Linux pima 2.6.26-1-686-bigmem #1 SMP Sat Nov 8 19:46:36 UTC 2008 i686 > GNU/Linux > ~ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.10.1 > ~ cat threadHang.hs > import Control.Concurrent > main = threadDelay (-1) New description: threadDelay silently hangs forever given a negative delay interval. It seems like this should at least be documented, but further is probably suboptimal magical behavior that leads to harder-to-find bugs; instead this should be an error. Conceivably threadDelay could take Maybe Int but that seems kind of out there. Here is some discussion from #haskell: {{{ 06:39 < dancor> do other ppl agree that (threadDelay (-1)) hanging silently is bug? 06:39 < dancor> i guess you might want infinite hang, hm 06:39 < Cale> dancor: I think I might agree with that, though now that you mention it, it's very handy. 06:39 < Cale> dancor: A lot of things which would cause a thread to block forever will throw an exception and kill the thread. 06:40 < Cale> (an exception which you'd often wish were silent) 06:40 < Cale> But threadDelay is the wrong place for that 06:40 < b_jonas> dancor: yeah, the thread should just be garbage-collected 06:42 * quicksilver uses "forever (threadDelay maxBound)" }}} I'm on Debian lenny: {{{ ~ uname -a Linux pima 2.6.26-1-686-bigmem #1 SMP Sat Nov 8 19:46:36 UTC 2008 i686 GNU/Linux ~ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 ~ cat threadHang.hs import Control.Concurrent main = threadDelay (-1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:11:20 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:01:41 2009 Subject: [GHC] #2892: (threadDelay (-1)) hangs In-Reply-To: <045.cacf950ebeacdae764843c5be42d3ce1@localhost> References: <045.cacf950ebeacdae764843c5be42d3ce1@localhost> Message-ID: <054.17c88967ef72c78b3ca18f1df5ade6ab@localhost> #2892: (threadDelay (-1)) hangs -------------------------+-------------------------------------------------- Reporter: dancor | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:15:47 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:05:58 2009 Subject: [GHC] #2894: Documentation for "even" missing In-Reply-To: <051.915bb1c85de628cda06f20972aedc55e@localhost> References: <051.915bb1c85de628cda06f20972aedc55e@localhost> Message-ID: <060.1182687efd4b3aed2de769144773e6e5@localhost> #2894: Documentation for "even" missing ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report. This is better now, but still not fully fixed. `even` is listed in the `Synopsis` and the main body, but in both cases it hasn't been given a type signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:22:03 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:12:23 2009 Subject: [GHC] #2900: Confusing error message for monadic function with wrong number of arguments In-Reply-To: <042.cbd4b88a3fe2bde042fd065b7021c09a@localhost> References: <042.cbd4b88a3fe2bde042fd065b7021c09a@localhost> Message-ID: <051.258ce35144ad67eb5fdab4a17b2f5c44@localhost> #2900: Confusing error message for monadic function with wrong number of arguments ----------------------------------------+----------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:42:10 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:32:26 2009 Subject: [GHC] #2902: Example where ghc 6.10.1 fails to optimize recursive instance function calls In-Reply-To: <047.82275b0f80fb63e95aa6dfb32e5bfe1f@localhost> References: <047.82275b0f80fb63e95aa6dfb32e5bfe1f@localhost> Message-ID: <056.f2e618f5dcfa6a7e324dda98ddfa6c01@localhost> #2902: Example where ghc 6.10.1 fails to optimize recursive instance function calls -----------------------------------------+---------------------------------- Reporter: Syzygies | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: class instance | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:46:20 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:36:31 2009 Subject: [GHC] #2903: Incorrect length for CWStringLen on Win32 In-Reply-To: <047.0158a89ccdee21aca9b74548b424b8b7@localhost> References: <047.0158a89ccdee21aca9b74548b424b8b7@localhost> Message-ID: <056.9b88ab3f144cb559e806c65bd23a76d3@localhost> #2903: Incorrect length for CWStringLen on Win32 ---------------------------------+------------------------------------------ Reporter: asklinge | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:49:04 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:39:16 2009 Subject: [GHC] #2905: require -XGADTs in order to pattern-match GADTs In-Reply-To: <044.e288cc24bdc7d119176c55c76be624e8@localhost> References: <044.e288cc24bdc7d119176c55c76be624e8@localhost> Message-ID: <053.549a0ed6953f499f0b7a915b4dad3c56@localhost> #2905: require -XGADTs in order to pattern-match GADTs ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:49:30 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:39:43 2009 Subject: [GHC] #2906: .hc code generated for Parser.hs is 2MB big In-Reply-To: <043.64c088340779512ef40025c8e0908a45@localhost> References: <043.64c088340779512ef40025c8e0908a45@localhost> Message-ID: <052.f0ff2013af54f0a168082fcbbba9ac94@localhost> #2906: .hc code generated for Parser.hs is 2MB big -------------------------+-------------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:50:01 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:40:11 2009 Subject: [GHC] #2915: Arity is smaller than need be In-Reply-To: <046.a17f452375c6b159ed122bce785e3f8a@localhost> References: <046.a17f452375c6b159ed122bce785e3f8a@localhost> Message-ID: <055.cc53f564def173d48cf91a060aac4fb7@localhost> #2915: Arity is smaller than need be -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: simonpj Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:57:49 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:47:59 2009 Subject: [GHC] #2916: Adding "-auto-all" when using "-O2 -prof" causes "<>" In-Reply-To: <049.104e5ce0692c10d94ee0be86a698b1ee@localhost> References: <049.104e5ce0692c10d94ee0be86a698b1ee@localhost> Message-ID: <058.ac1a6d0a0d7938802bee32367e202695@localhost> #2916: Adding "-auto-all" when using "-O2 -prof" causes "<>" ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: loop auto-all | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 16:59:08 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:49:29 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.70f5637628305dd90d5b32a0e06e0b99@localhost> #2917: alloca and allocaArray do not respect alignment -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * priority: normal => high * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 17:05:16 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 16:55:38 2009 Subject: [GHC] #2918: Storable alignment for Double is 4 In-Reply-To: <044.13a85fce6c4d3b10c8f7973ca5cbd3d7@localhost> References: <044.13a85fce6c4d3b10c8f7973ca5cbd3d7@localhost> Message-ID: <053.a70225e1bc7f60c0b9aa28555b08598d@localhost> #2918: Storable alignment for Double is 4 -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report; we'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 17:21:09 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 17:11:19 2009 Subject: [GHC] #2920: old-time on hackage is incorrectly packaged In-Reply-To: <043.fc91947b3a4dcf1c67f768ea035c6866@localhost> References: <043.fc91947b3a4dcf1c67f768ea035c6866@localhost> Message-ID: <052.00be491a267329299ba5883004db7b39@localhost> #2920: old-time on hackage is incorrectly packaged -----------------------------------+---------------------------------------- Reporter: dons | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/old-time | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * owner: => igloo * milestone: => 6.10.2 Comment: Need to check if this is fixed in the source before 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 17:45:07 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 17:35:24 2009 Subject: [GHC] #2918: Storable alignment for Double is 4 In-Reply-To: <044.13a85fce6c4d3b10c8f7973ca5cbd3d7@localhost> References: <044.13a85fce6c4d3b10c8f7973ca5cbd3d7@localhost> Message-ID: <053.3bbaa36ae7f06610c017ce0abb0b0f18@localhost> #2918: Storable alignment for Double is 4 -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by guest): I don't really care if this gets changed or now, it was just an observation. -- Lennart -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 17:45:23 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 17:35:33 2009 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@localhost> References: <046.ba154de3cf0c400fb0723e1948282304@localhost> Message-ID: <055.b834928b1a6cb69d536c970d003ec285@localhost> #2940: Do CSE after CorePrep -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: simonpj Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 17:48:52 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 17:39:01 2009 Subject: [GHC] #2921: __GLASGOW_HASKELL__ undefined In-Reply-To: <044.5d41f7fb4e60b06c4b614bb62c74874c@localhost> References: <044.5d41f7fb4e60b06c4b614bb62c74874c@localhost> Message-ID: <053.41f529c0af2d59dac4b3478b76c8568d@localhost> #2921: __GLASGOW_HASKELL__ undefined ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Can you please give complete instructions for reproducing the problem you're seeing? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 18:03:13 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 17:53:23 2009 Subject: [GHC] #2923: Documentation contains (broken) links to /home/ian In-Reply-To: <047.8599083b3310893fae769d528dbb6224@localhost> References: <047.8599083b3310893fae769d528dbb6224@localhost> Message-ID: <056.0c096d7174dc42554f491b3e9950b5c5@localhost> #2923: Documentation contains (broken) links to /home/ian ---------------------------------+------------------------------------------ Reporter: matthijs | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * owner: => igloo * milestone: => 6.10.2 Comment: Thanks for the report. I'll check everything looks OK for 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 18:16:03 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 18:06:13 2009 Subject: [GHC] #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets In-Reply-To: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> References: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> Message-ID: <056.0621f1cc0ffce48a4cd43978b3635381@localhost> #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets ----------------------------------+----------------------------------------- Reporter: tphyahoo | Owner: bos Type: bug | Status: assigned Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: ipv6 | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 18:18:16 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 18:08:30 2009 Subject: [GHC] #2999: yi darcs crashes ghc 6.11.20090201 Message-ID: <048.5ff08366c6b8c63b4b675c1919d9e549@localhost> #2999: yi darcs crashes ghc 6.11.20090201 ---------------------------+------------------------------------------------ Reporter: wolverian | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.11 | Severity: normal Keywords: xen, linux, yi | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---------------------------+------------------------------------------------ {{{Building yi-0.5.3... [ 1 of 107] Compiling System.FriendlyPath ( System/FriendlyPath.hs, dist/build/System/FriendlyPath.o ) [ 2 of 107] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs, dist/build/Shim/ProjectContent.o ) WARNING: file simplCore/SimplCore.lhs line 545 Simplifier still going after 4 iterations; bailing out. Size = 4969 [ 3 of 107] Compiling Parser.Incremental ( Parser/Incremental.hs, dist/build/Parser/Incremental.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.11.20090201 for x86_64-unknown-linux): ASSERT failed! file typecheck/TcTyFuns.lhs line 286 [Wanted t_a89i{tv} [tau] :: a{tv a89b} [sk] ~ a{tv a89a} [sk] -> t_a89h{tv} [tau]] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 18:19:33 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 18:09:44 2009 Subject: [GHC] #2999: yi darcs crashes ghc 6.11.20090201 In-Reply-To: <048.5ff08366c6b8c63b4b675c1919d9e549@localhost> References: <048.5ff08366c6b8c63b4b675c1919d9e549@localhost> Message-ID: <057.525b653dcabdf4b29b61bc92a7a6cb6f@localhost> #2999: yi darcs crashes ghc 6.11.20090201 -------------------------------------+-------------------------------------- Reporter: wolverian | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: Keywords: xen, linux, yi | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------------------------+-------------------------------------- Comment (by wolverian): Ugh. Let's try that again. {{{ Building yi-0.5.3... [ 1 of 107] Compiling System.FriendlyPath ( System/FriendlyPath.hs, dist/build/System/FriendlyPath.o ) [ 2 of 107] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs, dist/build/Shim/ProjectContent.o ) WARNING: file simplCore/SimplCore.lhs line 545 Simplifier still going after 4 iterations; bailing out. Size = 4969 [ 3 of 107] Compiling Parser.Incremental ( Parser/Incremental.hs, dist/build/Parser/Incremental.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.11.20090201 for x86_64-unknown-linux): ASSERT failed! file typecheck/TcTyFuns.lhs line 286 [Wanted t_a89i{tv} [tau] :: a{tv a89b} [sk] ~ a{tv a89a} [sk] -> t_a89h{tv} [tau]] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 18:47:37 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 18:37:46 2009 Subject: [GHC] #2942: witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case-sensitive file system In-Reply-To: <050.2d88d56a844b36381f7e789271b08f2d@localhost> References: <050.2d88d56a844b36381f7e789271b08f2d@localhost> Message-ID: <059.2fa570962bf16182a4f596a07755ab19@localhost> #2942: witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case- sensitive file system ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: None | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report; I'll try to look into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 18:56:35 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 18:46:44 2009 Subject: [GHC] #2920: old-time on hackage is incorrectly packaged In-Reply-To: <043.fc91947b3a4dcf1c67f768ea035c6866@localhost> References: <043.fc91947b3a4dcf1c67f768ea035c6866@localhost> Message-ID: <052.aa1478834a87de1e459ef1d3eb469a24@localhost> #2920: old-time on hackage is incorrectly packaged -----------------------------------+---------------------------------------- Reporter: dons | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: libraries/old-time | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by ross): * status: new => closed * resolution: => fixed Comment: The fix for the .cabal file was {{{ Sun Aug 24 01:27:32 BST 2008 Ross Paterson * add extra-source-files }}} which was included in old-time-1.0.0.1 (released with ghc-6.10.1 as a core package and thus not on hackage). I've patched the old-time-1.0.0.0 package on hackage to include the missing files, because it was supposed to faithfully reflect the version released with ghc-6.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 19:06:17 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 18:56:29 2009 Subject: [GHC] #2945: trace history should be global or add command :mergetrace In-Reply-To: <046.a1eed06b62edc58c92c0397ae05d5c35@localhost> References: <046.a1eed06b62edc58c92c0397ae05d5c35@localhost> Message-ID: <055.0a01f0f85b23337ede7f7e517ba6ad6c@localhost> #2945: trace history should be global or add command :mergetrace ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 19:07:21 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 18:57:30 2009 Subject: [GHC] #2946: tracing should be controled by a global flag (it should not be resume context specific) In-Reply-To: <046.683eb7b4d5d0c38dcae8da9a304188ed@localhost> References: <046.683eb7b4d5d0c38dcae8da9a304188ed@localhost> Message-ID: <055.b5e08580360d32122f8dda756d6d8904@localhost> #2946: tracing should be controled by a global flag (it should not be resume context specific) ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 19:09:43 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 18:59:53 2009 Subject: [GHC] #2947: infix precedence of backtick functions defined in ghci is not reported by :info In-Reply-To: <048.ac55607c7d8b9643c6c08e90e9bdf49b@localhost> References: <048.ac55607c7d8b9643c6c08e90e9bdf49b@localhost> Message-ID: <057.0797609375ae45df7df5adfab011338d@localhost> #2947: infix precedence of backtick functions defined in ghci is not reported by :info ---------------------------------+------------------------------------------ Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 19:18:48 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 19:09:01 2009 Subject: [GHC] #2950: show breakpoint numbers of breakpoints which were ignored during :force In-Reply-To: <046.8fc12104263edfe21a0114a0a4deb184@localhost> References: <046.8fc12104263edfe21a0114a0a4deb184@localhost> Message-ID: <055.9176694730a1a31a83df33ec84e6fb4d@localhost> #2950: show breakpoint numbers of breakpoints which were ignored during :force ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: trivial | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 2 19:24:45 2009 From: trac at galois.com (GHC) Date: Mon Feb 2 19:14:54 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.4194b51a2d2256067de42b7d4fdbb07d@localhost> #2953: deriving Functor, Foldable, Traversable ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: twanvl Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 07:41:18 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 07:31:27 2009 Subject: [GHC] #2946: tracing should be controled by a global flag (it should not be resume context specific) In-Reply-To: <046.683eb7b4d5d0c38dcae8da9a304188ed@localhost> References: <046.683eb7b4d5d0c38dcae8da9a304188ed@localhost> Message-ID: <055.4f94d41fb18c836e2a7e401ecd8f19fd@localhost> #2946: tracing should be controled by a global flag (it should not be resume context specific) ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by phercek): I asked for ":force " in the second bullet of the ticket description. It was an insight by accident. It would be really cool if we could force expressions and not only a list of variables. The main reason is user defined conditional breakpoints. A breakpoint condition may contain thunks which need to be forced to compute the condition result. This may result in hitting other breakpoints in nested contexts. This may be required or not. It depends, but it is almost never required if we query some expression containing _result variable. The problem is we stop at the same breakpoint we are just now at. With ":foce " we could force the breakpoint stop condition first and then query its result by checking the "it" variable.[[BR]] This is convenient for scripts, not that interesting for manual interaction. But scripts can disable breakpoints before evaluating the stop condition and enable them after the condition evaluation finished so there is a workaround. I just did not add :enable and :disable to my .ghci yet :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 09:08:30 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 08:58:40 2009 Subject: [GHC] #2860: Redundant unblocking in POSIX generic_handler In-Reply-To: <042.2727ad23f19fb18f0134c48d09681776@localhost> References: <042.2727ad23f19fb18f0134c48d09681776@localhost> Message-ID: <051.2f1533f53dee1b34e2d662ee0a97075d@localhost> #2860: Redundant unblocking in POSIX generic_handler --------------------------------------+------------------------------------- Reporter: dsh | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: trivial | Resolution: Keywords: POSIX generic_handler | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 09:11:24 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 09:01:31 2009 Subject: [GHC] #3000: :break command should recognize also nonexported top level symbols in qualified IDs Message-ID: <046.5f67b9fe1551f660bf15282b9129ff0d@localhost> #3000: :break command should recognize also nonexported top level symbols in qualified IDs -----------------------------+---------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- When a breakpoint is defined for a qualified function name ('' (''' conid . ''')+ '''varid''' ''). Then the name should be found even when it is not exported (i.e. when varid is not in the export list).[[BR]] The qualification ensures no ambiguity can happen so it should be allowed since it is line number independent which means breakpoint definitions sourced with ":." would be more robust against code modifications. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 09:22:26 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 09:12:43 2009 Subject: [GHC] #2918: Storable alignment for Double is 4 In-Reply-To: <044.13a85fce6c4d3b10c8f7973ca5cbd3d7@localhost> References: <044.13a85fce6c4d3b10c8f7973ca5cbd3d7@localhost> Message-ID: <053.b9421d49705551ba96022c72fd3f9cdf@localhost> #2918: Storable alignment for Double is 4 -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: The alignment for `Storable` instances is determined by configure tests. The test currently generates a C struct like {{{ struct foo { char c; TYPE t; } }}} for the `TYPE` of interest, and then determines what alignment the C compiler uses. For double on x86, it turns out that it uses 4 (though on x86_64 it uses 8). So perhaps gcc would like to use 8 but is constrained by the ABI here, I'm not quite sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 09:26:23 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 09:16:31 2009 Subject: [GHC] #2803: bring full top level of a module in scope when a breakpoint is hit in the module In-Reply-To: <046.652e8c43925e61f6025ee776347b88e6@localhost> References: <046.652e8c43925e61f6025ee776347b88e6@localhost> Message-ID: <055.978876e3a83c9cd6e9126f49027ccd4f@localhost> #2803: bring full top level of a module in scope when a breakpoint is hit in the module ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by phercek): In addition to adding all the symbols (even the nonexported ones) from the module where breakpoint was hit, consider "executing" all the import directives of the module where the breakpoint was hit. I would like it. Though this is not critical since I can just fully qualify all the names which are imported in my breakpoint scripts. Since the list of all the import directives can be long this would increase command prompt a lot. That means the modules introduced with import directives should be represented by one token in the command prompt (e.g. bpContext). This would also allow to add/remove all the imports easily with {{{:module (+|-)bpContext}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 10:30:50 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 10:21:09 2009 Subject: [GHC] #2918: Storable alignment for Double is 4 In-Reply-To: <044.13a85fce6c4d3b10c8f7973ca5cbd3d7@localhost> References: <044.13a85fce6c4d3b10c8f7973ca5cbd3d7@localhost> Message-ID: <053.463294ef117a0964bca8dddea2504e00@localhost> #2918: Storable alignment for Double is 4 -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by guest): Yes, there are really two kinds of alignment (or even three), and LLVM distinguishes them: the ABI alignment an the optimal alignment (and then there's also the minimal alignment). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 10:36:15 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 10:26:24 2009 Subject: [GHC] #1531: _result can get bound to the wrong value in a breakpoint In-Reply-To: <047.277cbd70ff981bfc206e02cf688d22da@localhost> References: <047.277cbd70ff981bfc206e02cf688d22da@localhost> Message-ID: <056.0d20bfb66a9ff0bc111491cb3953d8e2@localhost> #1531: _result can get bound to the wrong value in a breakpoint ---------------------------------+------------------------------------------ Reporter: mnislaih | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: result001 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by phercek): * cc: phercek@gmail.com (added) Comment: I think I hit the same problem (ghci 6.10.1). {{{ Ok, modules loaded: Main. *Main> :! cat b.hs fn :: Int -> Int fn x = if x > 10 then 10 else x *Main> :break 3 Breakpoint 0 activated at b.hs:3:5-10 *Main> fn 5 Stopped at b.hs:3:5-10 _result :: Int = _ x :: Int = 5 2 fn x = 3 if x > 10 4 then 10 [b.hs:3:5-10] *Main> :force _result *** Ignoring breakpoint _result = 5 [b.hs:3:5-10] *Main> }}} _result should have been False and not 5.[[BR]] _result does not correspond to the selected expression ('''x > 10'''). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 10:55:38 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 10:45:47 2009 Subject: [GHC] #3001: Biographical profiling segfaults Message-ID: <042.14ab8fad2945eacc99233583472e718a@localhost> #3001: Biographical profiling segfaults -------------------+-------------------------------------------------------- Reporter: nad | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- {{{ $ echo "main = print $ replicate 40000 'x'" > Test.hs $ ghc-6.10.1 --make -prof Test.hs -o test [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking test ... $ ./test +RTS -hb Segmentation fault }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 11:26:55 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 11:17:03 2009 Subject: [GHC] #2812: For ghci, drop editline in favour of haskeline In-Reply-To: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> References: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> Message-ID: <053.addbf864a6df187c457669d8ea4bd042@localhost> #2812: For ghci, drop editline in favour of haskeline ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): See also #2058 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 17:19:24 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 17:09:31 2009 Subject: [GHC] #2987: panic when compiling again In-Reply-To: <047.ad4a56debe0fa0023bf1923dd30e1509@localhost> References: <047.ad4a56debe0fa0023bf1923dd30e1509@localhost> Message-ID: <056.9f940b300d55bb58d80561b85a1831b1@localhost> #2987: panic when compiling again ---------------------------------+------------------------------------------ Reporter: dsrogers | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Done: {{{ Mon Feb 2 11:47:49 PST 2009 Ian Lynagh * Revert: Inject implicit bindings before the simplifier (Trac #2070) simonpj@microsoft.com**20080205165507 6.10-branch only. The patch caused problems; see trac #2987 for details. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 19:07:32 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 18:57:39 2009 Subject: [GHC] #2903: Incorrect length for CWStringLen on Win32 In-Reply-To: <047.0158a89ccdee21aca9b74548b424b8b7@localhost> References: <047.0158a89ccdee21aca9b74548b424b8b7@localhost> Message-ID: <056.b0ead065466d569405c5283c0d57e6b9@localhost> #2903: Incorrect length for CWStringLen on Win32 ---------------------------------+------------------------------------------ Reporter: asklinge | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed (thanks Ross!) in HEAD and 6.10 branch: {{{ Tue Feb 3 01:10:26 GMT 2009 Ross Paterson * Fix #2903: ensure CWStringLen contains the length of the array rather than the String }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 19:08:55 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 18:59:01 2009 Subject: [GHC] #2993: Precedence errors are reported for undefined operators In-Reply-To: <045.dc49aabd93adad128f189ed9b9b23308@localhost> References: <045.dc49aabd93adad128f189ed9b9b23308@localhost> Message-ID: <054.dfb7abcbbf7fafad83c1d7a912f6a675@localhost> #2993: Precedence errors are reported for undefined operators -----------------------------------------+---------------------------------- Reporter: Olathe | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rename/should_fail/T2993 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 22:08:19 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 21:58:35 2009 Subject: [GHC] #2999: yi darcs crashes ghc 6.11.20090201 In-Reply-To: <048.5ff08366c6b8c63b4b675c1919d9e549@localhost> References: <048.5ff08366c6b8c63b4b675c1919d9e549@localhost> Message-ID: <057.e883244d2190ddc6b994d1e96c4a17e4@localhost> #2999: yi darcs crashes ghc 6.11.20090201 -------------------------------------+-------------------------------------- Reporter: wolverian | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: Keywords: xen, linux, yi | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------------------------+-------------------------------------- Comment (by chak): Do you have the same problem with 6.10.1, or is this specific to the development version aka HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 3 22:28:17 2009 From: trac at galois.com (GHC) Date: Tue Feb 3 22:18:29 2009 Subject: [GHC] #2999: yi darcs crashes ghc 6.11.20090201 In-Reply-To: <048.5ff08366c6b8c63b4b675c1919d9e549@localhost> References: <048.5ff08366c6b8c63b4b675c1919d9e549@localhost> Message-ID: <057.c2979a14a3e6d49aa0a9eefb3238df09@localhost> #2999: yi darcs crashes ghc 6.11.20090201 -------------------------------------+-------------------------------------- Reporter: wolverian | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: Keywords: xen, linux, yi | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------------------------+-------------------------------------- Changes (by chak): * owner: => chak Comment: On second thought, it's not really important whether it happend in 6.10.1. You should see this problem '''only''' when you use a version of GHC that has been compiled with debugging (of the compiler) enabled - i.e., the compiler was compiled with `-DDEBUG`. Due to an infelicity in the type checker, some type variables (represented by IORefs) are currently updated twice in certain contexts. This is usually a harmless -if annoying- problem as the type variable should be updated twice with the same type term. However, a debugging compiler has assertions that catch repeated updates, which is why you see this panic. We have been planning to clean up the relevant code (by using side effects less liberally than they are at the moment - surely a Good Thing!), but it involves quite a bit of code rewriting, which is why it hasn't happend yet. For the moment, I can only suggest to use a compiler that hasn't been compiled with `-DDEBUG`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 03:44:50 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 03:35:04 2009 Subject: [GHC] #2999: yi darcs crashes ghc 6.11.20090201 In-Reply-To: <048.5ff08366c6b8c63b4b675c1919d9e549@localhost> References: <048.5ff08366c6b8c63b4b675c1919d9e549@localhost> Message-ID: <057.5d50f788a39f693a24e3e22bad44d48c@localhost> #2999: yi darcs crashes ghc 6.11.20090201 ----------------------------------------+----------------------------------- Reporter: wolverian | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: fixed Keywords: xen, linux, yi | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ----------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Old description: > {{{Building yi-0.5.3... > [ 1 of 107] Compiling System.FriendlyPath ( System/FriendlyPath.hs, > dist/build/System/FriendlyPath.o ) > [ 2 of 107] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs, > dist/build/Shim/ProjectContent.o ) > WARNING: file simplCore/SimplCore.lhs line 545 > Simplifier still going after 4 iterations; bailing out. Size = 4969 > > [ 3 of 107] Compiling Parser.Incremental ( Parser/Incremental.hs, > dist/build/Parser/Incremental.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 6.11.20090201 for x86_64-unknown-linux): > ASSERT failed! file typecheck/TcTyFuns.lhs line 286 > [Wanted t_a89i{tv} [tau] :: a{tv a89b} [sk] > ~ > a{tv a89a} [sk] -> t_a89h{tv} [tau]] > }}} New description: {{{ Building yi-0.5.3... [ 1 of 107] Compiling System.FriendlyPath ( System/FriendlyPath.hs, dist/build/System/FriendlyPath.o ) [ 2 of 107] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs, dist/build/Shim/ProjectContent.o ) WARNING: file simplCore/SimplCore.lhs line 545 Simplifier still going after 4 iterations; bailing out. Size = 4969 [ 3 of 107] Compiling Parser.Incremental ( Parser/Incremental.hs, dist/build/Parser/Incremental.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.11.20090201 for x86_64-unknown-linux): ASSERT failed! file typecheck/TcTyFuns.lhs line 286 [Wanted t_a89i{tv} [tau] :: a{tv a89b} [sk] ~ a{tv a89a} [sk] -> t_a89h{tv} [tau]] }}} Comment: I've pushed a patch that makes it a warning only. That should resolve it. {{{ Wed Feb 4 08:38:00 GMT 2009 simonpj@microsoft.com * Fix Trac #2999: change an ASSERT to a WARN }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 04:53:44 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 04:43:51 2009 Subject: [GHC] #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix In-Reply-To: <044.33b296bee16ac04eb53e73148864ea5b@localhost> References: <044.33b296bee16ac04eb53e73148864ea5b@localhost> Message-ID: <053.f583e416f6296d9dfd0043f6979da21b@localhost> #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix ----------------------------------+----------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/process | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 Comment: We'll fix the docs for 6.10.2, and add a killProcess for 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 04:57:57 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 04:48:28 2009 Subject: [GHC] #2883: setitimer(ITIMER_VIRTUAL) is not always available In-Reply-To: <047.b40f4ae8b455c2e4eb614a1510a0781b@localhost> References: <047.b40f4ae8b455c2e4eb614a1510a0781b@localhost> Message-ID: <056.93240f243fafba588541bc5ed1b08595@localhost> #2883: setitimer(ITIMER_VIRTUAL) is not always available ---------------------------------+------------------------------------------ Reporter: sthibaul | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => igloo Comment: Patch looks ok to me - Ian, could you apply please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 05:11:21 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 05:01:27 2009 Subject: [GHC] #2870: User signals are not blocked before 'fork' in runInteractiveProcess In-Reply-To: <042.e53acc7954108a66f75c2330d39f6f71@localhost> References: <042.e53acc7954108a66f75c2330d39f6f71@localhost> Message-ID: <051.59c28a267282cdce917141710835158d@localhost> #2870: User signals are not blocked before 'fork' in runInteractiveProcess -----------------------------------------------+---------------------------- Reporter: dsh | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/process | Version: 6.10.1 Severity: normal | Resolution: Keywords: threaded runInteractiveProcess | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -----------------------------------------------+---------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 05:13:35 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 05:03:41 2009 Subject: [GHC] #2678: hLookAhead + hSetBuffering = unsupported operation (Illegal seek) In-Reply-To: <044.ebc0cd7ca21089d8e742f250c2a46ae6@localhost> References: <044.ebc0cd7ca21089d8e742f250c2a46ae6@localhost> Message-ID: <053.d2424448eb37d7f1164b3eee01aba4d1@localhost> #2678: hLookAhead + hSetBuffering = unsupported operation (Illegal seek) ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * milestone: 6.10.2 => 6.12 branch Comment: This is fixed in the unicode IO library; bumping to 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 05:19:52 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 05:09:58 2009 Subject: [GHC] #2958: ghc-pkg describe is lying In-Reply-To: <044.023b948739e8319ec2c8f330e0539713@localhost> References: <044.023b948739e8319ec2c8f330e0539713@localhost> Message-ID: <053.e72c71f973ab096e592aaba454c50565@localhost> #2958: ghc-pkg describe is lying ---------------------------------+------------------------------------------ Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * cc: duncan.coutts@worc.ox.ac.uk (added) * difficulty: => Unknown Comment: Duncan - is this really a bug in Cabal/cabal-install? If so could you move it to the appropriate Trac? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 06:47:43 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 06:37:49 2009 Subject: [GHC] #3000: :break command should recognize also nonexported top level symbols in qualified IDs In-Reply-To: <046.5f67b9fe1551f660bf15282b9129ff0d@localhost> References: <046.5f67b9fe1551f660bf15282b9129ff0d@localhost> Message-ID: <055.a2d5e74a0f9cfb67cdc2228c67d51bb1@localhost> #3000: :break command should recognize also nonexported top level symbols in qualified IDs ------------------------------+--------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by phercek): Actually it would be cool if function names of the form'' ( '''conid .''' )* ( '''varid .''' )* '''varid''' '' could be recognized too.[[BR]] The identifer can have a sequence of '''varid'''s at the end. The idea is to identify a function which is defined in a where clause (or even a let clause (the first let function with given name)).[[BR]] E.g. for this source file: {{{ fn s = 'a' : add s where add = (++"z") }}} it could look like ''':break Main.fn.add''' and it would be tha same as ''':break 2''' (breakpoint on 'add'). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 06:48:02 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 06:38:07 2009 Subject: [GHC] #3002: Documentation for Data.Map.unionWithKey makes reference to "new" and "old" values which have no meaning in a union. Message-ID: <044.1d80fe5dfcd11073b7f22437a5d4d912@localhost> #3002: Documentation for Data.Map.unionWithKey makes reference to "new" and "old" values which have no meaning in a union. -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.1 | Severity: trivial Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The example given for unionWithKey uses rather odd names "new_value" and "old_value" for the values in the two maps. Perhaps more appropriate names would be leftValue and rightValue. This has been commented on in #haskell that where the values come from is not clear. let f key new_value old_value = (show key) ++ ":" ++ new_value ++ "|" ++ old_value unionWithKey f (fromList [(5, "a"), (3, "b")]) (fromList [(5, "A"), (7, "C")]) == fromList [(3, "b"), (5, "5:a|A"), (7, "C")] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 07:37:09 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 07:27:15 2009 Subject: [GHC] #2958: ghc-pkg describe is lying In-Reply-To: <044.023b948739e8319ec2c8f330e0539713@localhost> References: <044.023b948739e8319ec2c8f330e0539713@localhost> Message-ID: <053.ba6a6d3ba268ef0df6f0e9603a189765@localhost> #2958: ghc-pkg describe is lying ---------------------------------+------------------------------------------ Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Yep, it's in the Cabal trac (it's been open a year): http://hackage.haskell.org/trac/hackage/ticket/236 I've marked it easy so hopefully some volunteer will pick it up. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 08:37:45 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 08:27:53 2009 Subject: [GHC] #2980: Data.Generics reports wrong package? In-Reply-To: <046.f7418eb0a17f24f43c739702ff117886@localhost> References: <046.f7418eb0a17f24f43c739702ff117886@localhost> Message-ID: <055.cbbef52d5ba63ed411d8d2548a92d0aa@localhost> #2980: Data.Generics reports wrong package? ----------------------------------+----------------------------------------- Reporter: Martijn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10.2 Comment: Is this better? {{{ Prelude> import Data.Generics Could not find module `Data.Generics': it is a member of the hidden package `base-3.0.3.0' it is a member of the hidden package `syb' Use -v to see a list of the files searched for. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 08:51:27 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 08:41:31 2009 Subject: [GHC] #2958: ghc-pkg describe is lying In-Reply-To: <044.023b948739e8319ec2c8f330e0539713@localhost> References: <044.023b948739e8319ec2c8f330e0539713@localhost> Message-ID: <053.19b64f7b4928f1c8017c8b8c6a508279@localhost> #2958: ghc-pkg describe is lying ---------------------------------+------------------------------------------ Reporter: josef | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 10:13:55 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 10:04:02 2009 Subject: [GHC] #2905: require -XGADTs in order to pattern-match GADTs In-Reply-To: <044.e288cc24bdc7d119176c55c76be624e8@localhost> References: <044.e288cc24bdc7d119176c55c76be624e8@localhost> Message-ID: <053.16f5e6c51dc69f4974660aa64ab5c5fd@localhost> #2905: require -XGADTs in order to pattern-match GADTs ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: proposal | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Done {{{ Wed Feb 4 15:09:19 GMT 2009 simonpj@microsoft.com * Check -XGADTs in (a) type family decls (b) pattern matches }}} Don't merge to the branch; it's a small change in behaviour. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 10:15:23 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 10:05:30 2009 Subject: [GHC] #2994: give better error messages for instance declarations with the wrong number of parameters In-Reply-To: <047.7c1f3570de5b9324f1c6d8cab58ffeb9@localhost> References: <047.7c1f3570de5b9324f1c6d8cab58ffeb9@localhost> Message-ID: <056.6c1000011311338e2e501ecc96c34e36@localhost> #2994: give better error messages for instance declarations with the wrong number of parameters --------------------------------------------+------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T2994 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T2994 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Your wish is my command. I spent way too long on this, but it was fun. {{{ Wed Feb 4 15:07:36 GMT 2009 simonpj@microsoft.com * Improve error reports for kind checking (Trac #2994) }}} Let's not merge to 6.10. It's an unforced change, and quite a lot of lines of code are touched. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 4 11:36:13 2009 From: trac at galois.com (GHC) Date: Wed Feb 4 11:26:22 2009 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.80cbd0d08e22fb4af4f0b6085124969d@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: See also #2924, uncovered while testing this patch. To merge: {{{ Thu Dec 18 14:47:04 GMT Standard Time 2008 Duncan Coutts * Alternative implementation of createDirectoryIfMissing Mon Dec 22 16:41:05 GMT Standard Time 2008 Duncan Coutts * Fix createDirectoryIfMissing to not throw if the dir got deleted When we call createDirectory and some file system object already exists we have a problem. We need to distinguish if it is a file that already exists or if it is a directory because in the latter case it is not an error. Previously we called doesDirectoryExist however that does not distinguish the dir not existing (due to another thread deleting it) and an ordinary file existing. We now use withFileStatus to throw the original AlreadyExistsError only if a non-directory object exists. So now the only time we should get a spurious exception is if another thread deletes the directory and puts a file in its place between our call to createDirectory and withFileStatus. It should now be safe to race createDirectoryIfMissing with itself or deleteDirectoryRecursive. Wed Feb 4 16:33:19 GMT Standard Time 2009 Simon Marlow * fix this test for the new version of createDirectoryIfMissing (#2808) - add another race test, for two threads both doing create;cleanup - ignore isDoesNotExistErrors in create }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 04:51:54 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 04:42:01 2009 Subject: [GHC] #2658: Extreme memory usage (probably type functions) In-Reply-To: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> References: <044.e9d0778983f3efa5257edab0ca1c5901@localhost> Message-ID: <053.89f1830f80050f28e14aeb7196f662e2@localhost> #2658: Extreme memory usage (probably type functions) ----------------------------------------+----------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (Type checker) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ----------------------------------------+----------------------------------- Comment (by chak): Matthew, I had a look at this. However, the code base is pretty big including a lot of overlapping and (at least for GHC) undecidable instances of type classes with FDs. It is hard for me to make much sense of the typechecker trace without understanding your code. If you could cut this down to a smaller, more manageable example, that would make finding the problem much easier. From what I could see, the type checker gets into a loop when trying to infere the type signatures for the mutually recursive binding group consisting of `doMenu`, `one`, and `two` (in `Test/Tests`). I would suggest trying to add type signatures to these three functions. This might give us a better idea of what is happening. Again, it's hard for me to add these signatures without first understanding your library - I assume, it's not hard for you to give these signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:19:40 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:09:42 2009 Subject: [GHC] #2930: System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch In-Reply-To: <044.0a1fdac704adf497121070f9c08f89a0@localhost> References: <044.0a1fdac704adf497121070f9c08f89a0@localhost> Message-ID: <053.d0218cb4892c1d82f4735655f49d89ad@localhost> #2930: System.Time.formatCalendarTime: %s isn't the number of seconds since the Epoch -----------------------------------+---------------------------------------- Reporter: wferi | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/old-time | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------+---------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report. This bug is also mentioned in a comment in `System/Time.hsc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:19:56 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:09:58 2009 Subject: [GHC] #2949: ghci suddenly won't start In-Reply-To: <044.adacb64fb251885d51e98c63b57e2c71@localhost> References: <044.adacb64fb251885d51e98c63b57e2c71@localhost> Message-ID: <053.dbed297f074477ec418095adbc95a344@localhost> #2949: ghci suddenly won't start ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Old description: > I've no clue what is wrong or what I have changed, but when I tried to > fire up GHCI today, I got the below message. I've tried removing .ghci > and .ghc to no avail. The compiler is the default shipped by Ubuntu. > > % ghci > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > ghc-6.8.2: internal error: evacuate(static): strange closure type 0 > (GHC version 6.8.2 for i386_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort ghci New description: I've no clue what is wrong or what I have changed, but when I tried to fire up GHCI today, I got the below message. I've tried removing .ghci and .ghc to no avail. The compiler is the default shipped by Ubuntu. {{{ % ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help ghc-6.8.2: internal error: evacuate(static): strange closure type 0 (GHC version 6.8.2 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort ghci }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:21:30 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:11:32 2009 Subject: [GHC] #2949: ghci suddenly won't start In-Reply-To: <044.adacb64fb251885d51e98c63b57e2c71@localhost> References: <044.adacb64fb251885d51e98c63b57e2c71@localhost> Message-ID: <053.8e839a02ae35dfc080d5830d6d4d4aa4@localhost> #2949: ghci suddenly won't start ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: No response from submitter, so closing. Please reopen if you can reproduce the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:22:49 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:12:50 2009 Subject: [GHC] #2952: ghci fails to start from start menu on windows 7 In-Reply-To: <044.ff62699b4016eeac0215e90934c5496e@localhost> References: <044.ff62699b4016eeac0215e90934c5496e@localhost> Message-ID: <053.6a8ab72fcb015127ac0d35517065ba99@localhost> #2952: ghci fails to start from start menu on windows 7 -----------------------+---------------------------------------------------- Reporter: larsv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:30:38 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:20:40 2009 Subject: [GHC] #2962: Reduce space usage of genericLength for common Num instances In-Reply-To: <050.56d33139a9874005c965ed3f7cb60dae@localhost> References: <050.56d33139a9874005c965ed3f7cb60dae@localhost> Message-ID: <059.4ad6f38c6d84675de86c002813d8e183@localhost> #2962: Reduce space usage of genericLength for common Num instances ---------------------------------+------------------------------------------ Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:31:19 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:21:20 2009 Subject: [GHC] #2963: Exception if current path has national symbols In-Reply-To: <044.20cd1d7dd4607528a617f9d3d52f59f8@localhost> References: <044.20cd1d7dd4607528a617f9d3d52f59f8@localhost> Message-ID: <053.8b1ee73a0d9ace31c2fc065d9219636f@localhost> #2963: Exception if current path has national symbols -----------------------+---------------------------------------------------- Reporter: Tonal | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:25:12 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:21:47 2009 Subject: [GHC] #2957: GHC head build fails on non-GNU system assuming `patch' command is GNU patch In-Reply-To: <046.69b0f585273150506f0caa1d5b147736@localhost> References: <046.69b0f585273150506f0caa1d5b147736@localhost> Message-ID: <055.3e7bed83332dbbc2d8f1aa0df166b42f@localhost> #2957: GHC head build fails on non-GNU system assuming `patch' command is GNU patch -------------------------------+-------------------------------------------- Reporter: kgardas | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.10.2 Comment: Fixed in HEAD by: {{{ Fri Jan 23 18:00:15 GMT 2009 Ian Lynagh * Make the libffi patch files portable Solaris's patch can't apply them if the lines beginning "---" aren't preceeded by a "diff -ur foo bar" line. }}} TODO: Also apply a patch similar to kgardas's in the new build system. Merge patch to 6.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:30:18 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:26:46 2009 Subject: [GHC] #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) In-Reply-To: <046.4436609d3a414ddff94df71de1efe346@localhost> References: <046.4436609d3a414ddff94df71de1efe346@localhost> Message-ID: <055.88e31c41a8b7115c4124627c878233e7@localhost> #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) ---------------------------------+------------------------------------------ Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: The problem with merging it in (apart from the initial work to do the merge) is that then people working on GHC need to keep it working. Could it be easily modified to use the GHC API instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:44:45 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:34:50 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.b192b9b4c8af41877bd3313b1c37e2e9@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:45:10 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:35:10 2009 Subject: [GHC] #2966: build system does not respect --with-gcc= In-Reply-To: <045.38910ced362f70db06ad52953362394b@localhost> References: <045.38910ced362f70db06ad52953362394b@localhost> Message-ID: <054.32757a17718c3564094698e3f74be8fa@localhost> #2966: build system does not respect --with-gcc= ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:46:13 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:36:14 2009 Subject: [GHC] #2969: unix package built wrong on Solaris In-Reply-To: <045.0d30450289e14ebfae501919df8c4ac3@localhost> References: <045.0d30450289e14ebfae501919df8c4ac3@localhost> Message-ID: <054.d1b384e52ab0cea55b8f783d64e159d6@localhost> #2969: unix package built wrong on Solaris -------------------------+-------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:47:12 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:37:19 2009 Subject: [GHC] #2970: detecting readline in top-level ./configure is no guarantee of readline support In-Reply-To: <045.071488a2ab1aa6304b45ea4e23fd8c3b@localhost> References: <045.071488a2ab1aa6304b45ea4e23fd8c3b@localhost> Message-ID: <054.656a1cf99e6673523c189129b167a8aa@localhost> #2970: detecting readline in top-level ./configure is no guarantee of readline support ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:47:46 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:37:47 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.6955b10c7c1b540446500fc9a264e09e@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ---------------------------------+------------------------------------------ Reporter: dsf | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for tracking down the problem -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 10:56:11 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:46:12 2009 Subject: [GHC] #2972: GHCi broken in GHC 6.10.1 In-Reply-To: <046.36c84703d6f462149fdd781bf29492ec@localhost> References: <046.36c84703d6f462149fdd781bf29492ec@localhost> Message-ID: <055.f8fe2dedfc8715df6fd393e9183f3df6@localhost> #2972: GHCi broken in GHC 6.10.1 ------------------------+--------------------------------------------------- Reporter: cemeyer | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: powerpc | ------------------------+--------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report. Unfortunately, powerpc/Linux is not one of our core platforms, so I'm not sure if we'll be able to look into this. If you build GHC unregisterised then it should work, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:08:17 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 10:58:28 2009 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@localhost> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@localhost> Message-ID: <055.2439202d971eda1054b04ffee7b3b29b@localhost> #367: Infinite loops can hang Concurrent Haskell ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: nobody Type: bug | Status: assigned Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by SamB): This is just a gratuitous comment to add the word "scheduler" to the page. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:18:19 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:08:21 2009 Subject: [GHC] #2976: :show bindings give wrong results when a variable was redefined In-Reply-To: <046.67cbe4a77482922fe0ecb159593d1d6b@localhost> References: <046.67cbe4a77482922fe0ecb159593d1d6b@localhost> Message-ID: <055.b12dea9b5432b39722d94c52f5b50496@localhost> #2976: :show bindings give wrong results when a variable was redefined ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:18:53 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:09:29 2009 Subject: [GHC] #2977: Install phase fails when using --enable-shared In-Reply-To: <045.994e869e093bd3112bffee0662aa176e@localhost> References: <045.994e869e093bd3112bffee0662aa176e@localhost> Message-ID: <054.f7e24f63e1bea9a790995b681b80689f@localhost> #2977: Install phase fails when using --enable-shared -------------------------------+-------------------------------------------- Reporter: ingmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > Using todays snapshot (6.11.20090123), --enable-shared fails to install > because the ghc-pkg we just built can't find its shared objects when run > from the build directory. > > The install command used is: > make -j5 -l5 -j1 DESTDIR=/var/tmp/paludis/build/dev-lang- > ghc-6.11.20090123/image/ install-docs install > > Output snippet: > ------------------------------------------------------------------------ > == make install -rl 5; > in /var/tmp/paludis/build/dev-lang- > ghc-6.11.20090123/work/ghc-6.11.20090123/libffi > ------------------------------------------------------------------------ > x86_64-pc-linux-gnu-gcc -E -undef -traditional -P -DINSTALLING \ > -DIMPORT_DIR='"/usr/lib64/ghc-6.11.20090123/imports"' \ > -DLIB_DIR='"/usr/lib64/ghc-6.11.20090123"' \ > -DINCLUDE_DIR='"/usr/lib64/ghc-6.11.20090123/include"' \ > -DDATA_DIR='"/usr/lib64/ghc-6.11.20090123"' \ > -DHTML_DIR='"/usr/lib64/ghc-6.11.20090123/html/libraries/ffi"' \ > -DHADDOCK_IFACE='"/usr/lib64/ghc-6.11.20090123/html/libraries/ffi/ffi.haddock"' > \ > -I../includes \ > -x c -I../includes -Iinclude -DPACKAGE=ffi -DVERSION= > -DPKG_LIBDIR='"/usr/lib64/ghc-6.11.20090123"' > -DPKG_DATADIR='"/usr/lib64/ghc-6.11.20090123"' package.conf.in \ > | grep -v '^#pragma GCC' \ > | sed -e 's/""//g' -e 's/:[ ]*,/: /g' \ > | /var/tmp/paludis/build/dev-lang- > ghc-6.11.20090123/work/ghc-6.11.20090123/utils/ghc-pkg/dist-install/build > /ghc-pkg/ghc-pkg --global-conf /var/tmp/paludis/build/dev-lang- > ghc-6.11.20090123/image//usr/lib64/ghc-6.11.20090123/package.conf update > - --force > /var/tmp/paludis/build/dev-lang- > ghc-6.11.20090123/work/ghc-6.11.20090123/utils/ghc-pkg/dist-install/build > /ghc-pkg/ghc-pkg: error while loading shared libraries: > libHShaskell98-1.0.1.0-ghc6.11.20090123.so: cannot open shared object > file: No such file or directory > make[1]: *** [install] Error 127 > make: *** [install] Error 1 > > > I'll attach a full build log New description: Using todays snapshot (6.11.20090123), --enable-shared fails to install because the ghc-pkg we just built can't find its shared objects when run from the build directory. The install command used is: {{{ make -j5 -l5 -j1 DESTDIR=/var/tmp/paludis/build/dev-lang- ghc-6.11.20090123/image/ install-docs install }}} Output snippet: {{{ ------------------------------------------------------------------------ == make install -rl 5; in /var/tmp/paludis/build/dev-lang- ghc-6.11.20090123/work/ghc-6.11.20090123/libffi ------------------------------------------------------------------------ x86_64-pc-linux-gnu-gcc -E -undef -traditional -P -DINSTALLING \ -DIMPORT_DIR='"/usr/lib64/ghc-6.11.20090123/imports"' \ -DLIB_DIR='"/usr/lib64/ghc-6.11.20090123"' \ -DINCLUDE_DIR='"/usr/lib64/ghc-6.11.20090123/include"' \ -DDATA_DIR='"/usr/lib64/ghc-6.11.20090123"' \ -DHTML_DIR='"/usr/lib64/ghc-6.11.20090123/html/libraries/ffi"' \ -DHADDOCK_IFACE='"/usr/lib64/ghc-6.11.20090123/html/libraries/ffi/ffi.haddock"' \ -I../includes \ -x c -I../includes -Iinclude -DPACKAGE=ffi -DVERSION= -DPKG_LIBDIR='"/usr/lib64/ghc-6.11.20090123"' -DPKG_DATADIR='"/usr/lib64/ghc-6.11.20090123"' package.conf.in \ | grep -v '^#pragma GCC' \ | sed -e 's/""//g' -e 's/:[ ]*,/: /g' \ | /var/tmp/paludis/build/dev-lang- ghc-6.11.20090123/work/ghc-6.11.20090123/utils/ghc-pkg/dist-install/build /ghc-pkg/ghc-pkg --global-conf /var/tmp/paludis/build/dev-lang- ghc-6.11.20090123/image//usr/lib64/ghc-6.11.20090123/package.conf update - --force /var/tmp/paludis/build/dev-lang- ghc-6.11.20090123/work/ghc-6.11.20090123/utils/ghc-pkg/dist-install/build /ghc-pkg/ghc-pkg: error while loading shared libraries: libHShaskell98-1.0.1.0-ghc6.11.20090123.so: cannot open shared object file: No such file or directory make[1]: *** [install] Error 127 make: *** [install] Error 1 }}} I'll attach a full build log -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:19:55 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:10:28 2009 Subject: [GHC] #2977: Install phase fails when using --enable-shared In-Reply-To: <045.994e869e093bd3112bffee0662aa176e@localhost> References: <045.994e869e093bd3112bffee0662aa176e@localhost> Message-ID: <054.34aaf500ab9bcf7d3bb91c6df6dd898d@localhost> #2977: Install phase fails when using --enable-shared -------------------------------+-------------------------------------------- Reporter: ingmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.12 branch Comment: We probably won't fix this before moving to the new build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:21:57 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:11:57 2009 Subject: [GHC] #2978: Add support for more characters to UnicodeSyntax In-Reply-To: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> References: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> Message-ID: <054.b24c428f76bd7b6bf563f72d5044717e@localhost> #2978: Add support for more characters to UnicodeSyntax ---------------------------------+------------------------------------------ Reporter: porges | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the patch! We'll take a look -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:23:42 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:13:43 2009 Subject: [GHC] #2979: better support for FFI C wrappers for macros in system headers In-Reply-To: <045.050d142d1954d12d764c4cd94c9c38c8@localhost> References: <045.050d142d1954d12d764c4cd94c9c38c8@localhost> Message-ID: <054.62f0f122626e48f19ba844dbf429d3b7@localhost> #2979: better support for FFI C wrappers for macros in system headers ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:24:15 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:14:21 2009 Subject: [GHC] #2981: ".space" directive not recognised by solaris assembler In-Reply-To: <045.06c53c97857dc8d5e429d261e87cfc23@localhost> References: <045.06c53c97857dc8d5e429d261e87cfc23@localhost> Message-ID: <054.3ecccacddce180d530dc893394dee759@localhost> #2981: ".space" directive not recognised by solaris assembler -------------------------------+-------------------------------------------- Reporter: duncan | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.12 branch Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:26:32 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:16:36 2009 Subject: [GHC] #2983: Segmentation fault in ray tracer with certain options In-Reply-To: <052.ab008e7a26a83a06094f6364ea685223@localhost> References: <052.ab008e7a26a83a06094f6364ea685223@localhost> Message-ID: <061.7aeaba9f03a25030ab8738484fb167e1@localhost> #2983: Segmentation fault in ray tracer with certain options --------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: seg fault, ray tracer | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | --------------------------------------+------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report, I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:27:04 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:17:05 2009 Subject: [GHC] #2984: Vectorized dph code doesn't terminate In-Reply-To: <042.776c42012cc46c4d8dc7e12433e5e6d8@localhost> References: <042.776c42012cc46c4d8dc7e12433e5e6d8@localhost> Message-ID: <051.6219bed58915af479cff1de50f08e6e3@localhost> #2984: Vectorized dph code doesn't terminate --------------------------------------+------------------------------------- Reporter: fre | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Data Parallel Haskell | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | --------------------------------------+------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:31:48 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:21:50 2009 Subject: [GHC] #2986: :info printing instances often isn't wanted In-Reply-To: <043.cc7348275a1e64e6491d1ee94042b0a6@localhost> References: <043.cc7348275a1e64e6491d1ee94042b0a6@localhost> Message-ID: <052.7184ad63416210f3bbffce92df18d123@localhost> #2986: :info printing instances often isn't wanted ---------------------------------+------------------------------------------ Reporter: Remi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: :info instances | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.10 branch Comment: There is actually no requirement that command abbreviations are unique, i.e. we could make `:i` mean `:info` even if we also had a `:instances` command. For example, `:b` means `:break` even though we also have `:back`, `:browse` and `:browse!`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:37:36 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:27:37 2009 Subject: [GHC] #2988: Improve float-in In-Reply-To: <046.83e28bfdd70de8fbe4dfb2a2f0f105d9@localhost> References: <046.83e28bfdd70de8fbe4dfb2a2f0f105d9@localhost> Message-ID: <055.11a45ef2729e78245293a1819c5787bc@localhost> #2988: Improve float-in ---------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:39:52 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:29:53 2009 Subject: [GHC] #2989: ByteString causes C stack overflow in generated code In-Reply-To: <045.e817821e697fd12e025d388665fba1f4@localhost> References: <045.e817821e697fd12e025d388665fba1f4@localhost> Message-ID: <054.04bf4307ac6ead3f2e29a92cd2b76548@localhost> #2989: ByteString causes C stack overflow in generated code ---------------------------------+------------------------------------------ Reporter: Olathe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: I agree, doesn't look like a bug to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:40:53 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:30:55 2009 Subject: [GHC] #2991: .mix files generation broken with -fhpc and --make flags with lhs modules In-Reply-To: <045.fbdf830be4083dc434ba708ecd719a55@localhost> References: <045.fbdf830be4083dc434ba708ecd719a55@localhost> Message-ID: <054.1561bcce9f06b40b5980e0d28798cfc2@localhost> #2991: .mix files generation broken with -fhpc and --make flags with lhs modules ---------------------------------+------------------------------------------ Reporter: ppavel | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: hpc make lhs | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:43:33 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:33:36 2009 Subject: [GHC] #2992: GHCi Memory Leak in Windows Vista In-Reply-To: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> References: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> Message-ID: <053.f2500d268e36086d22da5aa5e7565ae8@localhost> #2992: GHCi Memory Leak in Windows Vista -----------------------+---------------------------------------------------- Reporter: Andir | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Old description: > If use ghci.exe and separating compiling via ghc.exe, memory leak in ghci > occurred. After exhausting available memory Vista has no any respond. > > Steps for reproduce: > 1) Run GHCi: process list has 2 processes: ghci.exe (a), ghc.exe > (b), > 2) Run separated compilation process 20 times: > Command Line: > for /L %i in (1,1,20) do ghc -fforce-recomp -O --make "problem.hs" -o > "problem.exe" > Sample Haskell Program listing (problem.hs): > main :: IO () > main = do > print $ [x | x <- [1..]] > putStrLn "Hello, world!" > > 3) In process list (taskmgr.exe) you can see processor activity and > increased value of "Memory (Private Working Set)" for process (b). > 4) As run result "Memory (Private Working Set)" increased about > 100Mb. New description: If use ghci.exe and separating compiling via ghc.exe, memory leak in ghci occurred. After exhausting available memory Vista has no any respond. Steps for reproduce: * Run GHCi: process list has 2 processes: ghci.exe (a), ghc.exe (b), * Run separated compilation process 20 times: Command Line: {{{ for /L %i in (1,1,20) do ghc -fforce-recomp -O --make "problem.hs" -o "problem.exe" }}} Sample Haskell Program listing (problem.hs): {{{ main :: IO () main = do print $ [x | x <- [1..]] putStrLn "Hello, world!" }}} * In process list (taskmgr.exe) you can see processor activity and increased value of "Memory (Private Working Set)" for process (b). * As run result "Memory (Private Working Set)" increased about 100Mb. Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:44:02 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:34:06 2009 Subject: [GHC] #2995: ghc -Wall does not complain about unnecessary data constructor imports In-Reply-To: <048.f0e44db11fec5519d682367c28fd6c91@localhost> References: <048.f0e44db11fec5519d682367c28fd6c91@localhost> Message-ID: <057.d4a43395e9ab4fd3fbffc7eeb3e2ddf7@localhost> #2995: ghc -Wall does not complain about unnecessary data constructor imports ---------------------------------+------------------------------------------ Reporter: EyalLotem | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Old description: > If it is enough to import: > > import SomeModule(SomeType) > > Then ghc should complain (warn) when importing: > > import SomeModule(SomeType(..)) > > or: > > import SomeModule(SomeType(SomeConstructor)) > > But it doesn't output any complaint or warning. New description: If it is enough to import: {{{ import SomeModule(SomeType) }}} Then ghc should complain (warn) when importing: {{{ import SomeModule(SomeType(..)) }}} or: {{{ import SomeModule(SomeType(SomeConstructor)) }}} But it doesn't output any complaint or warning. Comment: thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:47:31 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:37:33 2009 Subject: [GHC] #2996: Network.Socket.sClose should change socket status In-Reply-To: <046.41f89e25a108f554724958983d75e152@localhost> References: <046.41f89e25a108f554724958983d75e152@localhost> Message-ID: <055.deef450ea6b45fced8546128f61641eb@localhost> #2996: Network.Socket.sClose should change socket status ----------------------------------+----------------------------------------- Reporter: amthrax | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the patches! We'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:48:00 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:38:05 2009 Subject: [GHC] #2997: Package names starting with a numeric character cause assembler errors In-Reply-To: <044.06fddb0d2b915fea9056d01f9dd6ea43@localhost> References: <044.06fddb0d2b915fea9056d01f9dd6ea43@localhost> Message-ID: <053.3d09fd7b6f6ec52a7513c63de09e5de1@localhost> #2997: Package names starting with a numeric character cause assembler errors ---------------------------------+------------------------------------------ Reporter: mboes | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.10.2 Comment: Will do -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 11:49:00 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:39:04 2009 Subject: [GHC] #2982: GHCi crashes if a :def command gets a pattern-match error In-Reply-To: <046.80931cceccca77f15ec37ce09ae8c426@localhost> References: <046.80931cceccca77f15ec37ce09ae8c426@localhost> Message-ID: <055.807b251c98cf6650459544a611e9902d@localhost> #2982: GHCi crashes if a :def command gets a pattern-match error ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10 branch by {{{ Fri Jan 30 09:19:19 GMT 2009 Simon Marlow * Force the result of user-defined commands Ignore-this: f756d00cc062072e1945d63cfbbeb98 so that exceptions are reported with "*** Exception" instead of as a panic. }}} {{{ Prelude> :def err (\_->return $ concat $ replicate (read "\"1\"") "a") Prelude> :err *** Exception: Prelude.read: no parse }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 12:07:21 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:57:23 2009 Subject: [GHC] #3000: :break command should recognize also nonexported top level symbols in qualified IDs In-Reply-To: <046.5f67b9fe1551f660bf15282b9129ff0d@localhost> References: <046.5f67b9fe1551f660bf15282b9129ff0d@localhost> Message-ID: <055.3835a91a00ba9042b44cb6523ce5ec36@localhost> #3000: :break command should recognize also nonexported top level symbols in qualified IDs ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 12:07:38 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:57:43 2009 Subject: [GHC] #3001: Biographical profiling segfaults In-Reply-To: <042.14ab8fad2945eacc99233583472e718a@localhost> References: <042.14ab8fad2945eacc99233583472e718a@localhost> Message-ID: <051.7b1e8aba7efc04e7eae447717c241a86@localhost> #3001: Biographical profiling segfaults -------------------------+-------------------------------------------------- Reporter: nad | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report; we'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 12:07:55 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:57:55 2009 Subject: [GHC] #3002: Documentation for Data.Map.unionWithKey makes reference to "new" and "old" values which have no meaning in a union. In-Reply-To: <044.1d80fe5dfcd11073b7f22437a5d4d912@localhost> References: <044.1d80fe5dfcd11073b7f22437a5d4d912@localhost> Message-ID: <053.17e871ef82f88bfedc3e31d2d04b78e8@localhost> #3002: Documentation for Data.Map.unionWithKey makes reference to "new" and "old" values which have no meaning in a union. ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.1 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > The example given for unionWithKey uses rather odd names "new_value" and > "old_value" for the values in the two maps. Perhaps more appropriate > names would be leftValue and rightValue. This has been commented on in > #haskell that where the values come from is not clear. > > let f key new_value old_value = (show key) ++ ":" ++ new_value ++ "|" ++ > old_value > unionWithKey f (fromList [(5, "a"), (3, "b")]) (fromList [(5, "A"), (7, > "C")]) == fromList [(3, "b"), (5, "5:a|A"), (7, "C")] New description: The example given for unionWithKey uses rather odd names "new_value" and "old_value" for the values in the two maps. Perhaps more appropriate names would be leftValue and rightValue. This has been commented on in #haskell that where the values come from is not clear. {{{ let f key new_value old_value = (show key) ++ ":" ++ new_value ++ "|" ++ old_value unionWithKey f (fromList [(5, "a"), (3, "b")]) (fromList [(5, "A"), (7, "C")]) == fromList [(3, "b"), (5, "5:a|A"), (7, "C")] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 12:08:21 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 11:58:22 2009 Subject: [GHC] #3002: Documentation for Data.Map.unionWithKey makes reference to "new" and "old" values which have no meaning in a union. In-Reply-To: <044.1d80fe5dfcd11073b7f22437a5d4d912@localhost> References: <044.1d80fe5dfcd11073b7f22437a5d4d912@localhost> Message-ID: <053.df6894a47a64fbcc42e41093c37d4adc@localhost> #3002: Documentation for Data.Map.unionWithKey makes reference to "new" and "old" values which have no meaning in a union. ----------------------------------+----------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries (other) | Version: 6.10.1 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * owner: => igloo * milestone: => 6.10.2 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 12:50:58 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 12:40:59 2009 Subject: [GHC] #3003: Happy does not reject pragmas Message-ID: <043.1fd1758c7687447f05a74bae43d4e79c@localhost> #3003: Happy does not reject pragmas -----------------------------+---------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I was about to report a bug in GHC's handling of -fno-warn-missing signatures in pragmas, but wasn't able to reproduce it. Then I noticed it: the problem was that the pragma was at the very top of a {{{.y}}} file, where it was simply discarded, like this: {{{ {-# OPTIONS_GHC -fno-warn-missing-signatures #-} {- -*- Haskell -*- -} { }}} Happy should probably not just silently discard pragmas. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 13:59:30 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 13:49:37 2009 Subject: [GHC] #2972: GHCi broken in GHC 6.10.1 In-Reply-To: <046.36c84703d6f462149fdd781bf29492ec@localhost> References: <046.36c84703d6f462149fdd781bf29492ec@localhost> Message-ID: <055.fcf2a6cc3f195c268db9c94550cd1382@localhost> #2972: GHCi broken in GHC 6.10.1 ------------------------+--------------------------------------------------- Reporter: cemeyer | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: powerpc | ------------------------+--------------------------------------------------- Comment (by cemeyer): Replying to [comment:1 igloo]: > Thanks for the report. Unfortunately, powerpc/Linux is not one of our core platforms, so I'm not sure if we'll be able to look into this. That's unfortunate. > If you build GHC unregisterised then it should work, though. I don't understand. GHC works fine, are you saying this should make GHCi work? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 17:19:47 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 17:09:53 2009 Subject: [GHC] #2775: Type Family panic In-Reply-To: <044.cf027f74305f326c967336b8f3c587bd@localhost> References: <044.cf027f74305f326c967336b8f3c587bd@localhost> Message-ID: <053.18652793dbdea6c2e0c3b3b02aefc91d@localhost> #2775: Type Family panic ---------------------------------+------------------------------------------ Reporter: camio | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ganesh): * cc: ganesh (added) Comment: I think this is another example of the same problem: {{{ {-# LANGUAGE RankNTypes, TypeFamilies #-} module Main where data A = A { unA :: forall p . p ~ Int => p -> p } conv :: A -> Int conv a = unA a 0 }}} BTW both examples work in ghc 6.11.20090130, so perhaps there's something that can be merged or perhaps this bug should be punted to 6.12. [To try the original example above in 6.11 you need to insert dummy declarations for {{{VectorSpace}}} and {{{Scalar}}} as the vector-space package from hackage fails to install due to a different GHC panic] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 17:21:30 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 17:11:33 2009 Subject: [GHC] #3004: Makefile needs to improve treatment of HsColour Message-ID: <041.599d5d545611d75bbe675a894a5ae12b@localhost> #3004: Makefile needs to improve treatment of HsColour -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Fresh checkout, a few new patches, sh boot & configure are OK, but 'make' results in {{{ : nr@labrador 10435 ; make HsColour needed but wasn't found. Set HSCOLOUR_SRCS=NO if you don't want to use it exit 1 make: *** [check-tools] Error 1 }}} Things that are wrong here: 1. 'sh boot; ./configure; make' failed. This should never happen. 1. I'm not told ''where'' to set {{{HSCOLOUR_SRCS=NO}}}. 1. The missing software should be detected by ./configure and the variable set then. 1. The error message (which should be a warning message from configure) does not tell me how to get and install the HsColour software. The error message should include information along the following lines: {{{ If you do want to use the software, the source is at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hscolour If you've got cabal-install then: $ cabal update $ cabal install hscolour }}} 5. Finally, the message should say what {{{HsColour}}} is so that the rank amateur (me) can figure out if it's worth installing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 20:54:50 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 20:44:54 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.91d392a23a9cd336267765b6b5f47c28@localhost> #2953: deriving Functor, Foldable, Traversable ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: twanvl Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by twanvl): I'll get to work on the documentation. Regarding the flag name: * In a sense Functor and Foldable are specializations of Traversable, so -XDeriveTraversable might make more sense. On the other hand, it is possible to derive Functor instances for some types containing functions, where it is not possible to make a Traversable instance. * For Data and Typeable the flag is -XDeriveDataTypeable, so we could also go with -XDeriveFunctorFoldableTraversable, but that is a bit long. * The last alternative is to make three flags, one for each class. This is slightly more work for the programmer if he wants to derive all three instances. If I had to choose, I think I would prefer the last alternative. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 5 21:19:18 2009 From: trac at galois.com (GHC) Date: Thu Feb 5 21:09:23 2009 Subject: [GHC] #3004: Makefile needs to improve treatment of HsColour In-Reply-To: <041.599d5d545611d75bbe675a894a5ae12b@localhost> References: <041.599d5d545611d75bbe675a894a5ae12b@localhost> Message-ID: <050.afdb3f897334f4c011ac4f8d5d7631a7@localhost> #3004: Makefile needs to improve treatment of HsColour ------------------------------+--------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by chak): I actually still don't even see the point of requiring !HsColour by default. As Norman writes, !HsColour should be detected by ./configure like everything else. If it's not installed, ./configure should print a warning about Haddock code not being nicely marked up and the build continue. What's so special about !HsColour, say compared to the docbook tools, that it deserves different treatment? If it is really '''that''' important, it's source should be included into the GHC repo, just like gmp. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 6 09:12:38 2009 From: trac at galois.com (GHC) Date: Fri Feb 6 09:02:56 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.a29f139ca103f0ac85367d7bb0ad4f7f@localhost> #2953: deriving Functor, Foldable, Traversable ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: twanvl Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): The other possibility is to change `-XDeriveDataTypeable` to `-XDeriveExtraClasses`, and give up on specifying exactly ''which'' extra classes. That'd be my personal inclination. What do others think? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 6 10:03:24 2009 From: trac at galois.com (GHC) Date: Fri Feb 6 09:53:25 2009 Subject: [GHC] #2803: bring full top level of a module in scope when a breakpoint is hit in the module In-Reply-To: <046.652e8c43925e61f6025ee776347b88e6@localhost> References: <046.652e8c43925e61f6025ee776347b88e6@localhost> Message-ID: <055.5d0e0a3dea3c74c31ae266944aa1d6f1@localhost> #2803: bring full top level of a module in scope when a breakpoint is hit in the module ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:3 phercek]: > In addition to adding all the symbols (even the nonexported ones) from the module where breakpoint was hit, consider "executing" all the import directives of the module where the breakpoint was hit. The "top-level scope of a module" is exactly the set of names that are in scope in the source code of a module, including all those names in scope by virtue of being imported. So I think the proposed solution would do what you want. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 6 10:23:35 2009 From: trac at galois.com (GHC) Date: Fri Feb 6 10:13:34 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.819fde1cb97957e5f265fda60fe623d1@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ---------------------------------+------------------------------------------ Reporter: dsf | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar Comment: I messed up when I modified the IO library to avoid using O_NONBLOCK for external file descriptors. Fixing it now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 6 12:16:45 2009 From: trac at galois.com (GHC) Date: Fri Feb 6 12:06:46 2009 Subject: [GHC] #3005: Normalize fully-applied type functions prior to display Message-ID: <047.30459bfff0d7f26f031112d1ec205050@localhost> #3005: Normalize fully-applied type functions prior to display -----------------------------+---------------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I have a module with a matrix type constructor: > data (Natural r, Natural c) => Matrix r c t = Matrix [[t]] deriving (Eq) which uses type-level naturals to provide dimension checking. A type class for multiplication: > class Multiply a b where > type Product a b > times :: a -> b -> Product a b and an instance for matrix multiplication: > instance (Natural a, Natural b, Natural c, Num t) => Multiply (Matrix a b t) (Matrix b c t) where > type Product (Matrix a b t) (Matrix b c t) = Matrix a c t > times m1 m2 = ... All of this works really well, I get dimension checking (and inference), and lot of other goodies. My request has to do with the following GHCi session: *Main> let a = matrix two two [[1,1],[2,6]] *Main> :t a a :: Matrix Two Two Integer *Main> :t a `times` a a `times` a :: Product (Matrix Two Two Integer) (Matrix Two Two Integer) When a type function is fully-applied, as Product is in this case, it would be nice if GHC could simplify it prior to display. This would result in the following output for this example: :t a `times` a a `times` a :: Matrix Two Two Integer I have attached the files necessary to run this test case, although a simpler one could be constructed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 6 14:36:14 2009 From: trac at galois.com (GHC) Date: Fri Feb 6 14:26:14 2009 Subject: [GHC] #3006: ghc panic when build Crypto package on Mac OS X 10.4 Message-ID: <046.629ad49a03e788e7c02f0b312b20f479@localhost> #3006: ghc panic when build Crypto package on Mac OS X 10.4 --------------------+------------------------------------------------------- Reporter: alexott | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- I build Crypto package on Mac OS X 10.4 and got following error: {{{ [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test /SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 6 17:35:43 2009 From: trac at galois.com (GHC) Date: Fri Feb 6 17:26:15 2009 Subject: [GHC] #3007: GHC seems to ignore the package name of modules imported with {#- SOURCE #-} Message-ID: <046.111251f57247f17187bc3cbd93be08f3@localhost> #3007: GHC seems to ignore the package name of modules imported with {#- SOURCE #-} --------------------+------------------------------------------------------- Reporter: jeltsch | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) --------------------+------------------------------------------------------- I have attached an archive with source bundles of two small Cabal packages A and B. Please build and register package A by executing these commands in directory A: {{{ runghc Setup.lhs configure --user runghc Setup.lhs build runghc Setup.lhs register --inplace }}} Now try to build B by executing these commands in directory B: {{{ runghc Setup.lhs configure --user runghc Setup.lhs build }}} You will probably get the following error message: {{{ B.hs:6:9: Bad interface file: .../Bug/A/dist/build/Internal.hi-boot .../Bug/A/dist/build/Internal.hi-boot: openBinaryFile: does not exist (No such file or directory) In the type `A' In the type signature for `a': a :: A }}} The type {{{A}}} is indirectly imported from module {{{Internal}}} of package A. GHC seems to think that this module was imported with a {{{{-# SOURCE #-}}}} pragma and therefore looks for a .hi-boot file instead of a .hi file. However, it?s the module {{{Internal}}} ''of package B'' that was imported with a {{{{-# SOURCE #-}}}} pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 6 18:45:15 2009 From: trac at galois.com (GHC) Date: Fri Feb 6 18:35:14 2009 Subject: [GHC] #3008: Strange behavior when using newtyped version of IO monad in FFI import declarations Message-ID: <044.36e848c5758ff29e66ba18e678751e7c@localhost> #3008: Strange behavior when using newtyped version of IO monad in FFI import declarations -------------------+-------------------------------------------------------- Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: FFI | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- Take a look at these two modules: A.hs: {{{ module A (GL) where import Control.Monad import Control.Monad.Trans newtype GL a = GL (IO a) deriving (Functor, Monad, MonadIO) }}} B.hs: {{{ module B where import A foreign import CALLCONV unsafe "glFlush" flush :: GL () }}} Now, compile them with optimizations: {{{ [david@alonzo temp]$ $HOME/ghc-6.10.1/bin/ghc A.hs B.hs -XGeneralizedNewtypeDeriving -XForeignFunctionInterface -DCALLCONV=ccall -XCPP -O compilation IS NOT required compilation IS NOT required A.o:(.text+0x8e): undefined reference to `mtlzm1zi1zi0zi2_ControlziMonadziTrans_ZCDMonadIO_con_info' A.o:(.text+0x237): undefined reference to `__stginit_mtlzm1zi1zi0zi2_ControlziMonadziTrans_' B.o:(.text+0x1e): undefined reference to `glFlush' /home/david/ghc-6.10.1//lib/ghc-6.10.1/libHSrts.a(Main.o): In function `real_main': Main.c:(.text+0x12): undefined reference to `__stginit_ZCMain' Main.c:(.text+0x26): undefined reference to `ZCMain_main_closure' collect2: ld returnerade avslutningsstatus 1 }}} It's OK - we pass the typechecking phase. Now, see what happens when we compile without `-O`: {{{ [david@alonzo temp]$ rm -f *.hi *.o [david@alonzo temp]$ $HOME/ghc-6.10.1/bin/ghc A.hs B.hs -XGeneralizedNewtypeDeriving -XForeignFunctionInterface -DCALLCONV=ccall -XCPP B.hs:5:0: Unacceptable result type in foreign declaration: GL () When checking declaration: foreign import ccall unsafe "static &glFlush" flush :: GL () }}} Putting everything into one single module makes the type error go away completely (that is, also when compiling without `-O`). Something strange must be going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 6 18:55:07 2009 From: trac at galois.com (GHC) Date: Fri Feb 6 18:45:05 2009 Subject: [GHC] #3008: Strange behavior when using newtyped version of IO monad in FFI import declarations In-Reply-To: <044.36e848c5758ff29e66ba18e678751e7c@localhost> References: <044.36e848c5758ff29e66ba18e678751e7c@localhost> Message-ID: <053.f57445f8ef9bdc9784d84f0fc8a5aa08@localhost> #3008: Strange behavior when using newtyped version of IO monad in FFI import declarations ----------------------+----------------------------------------------------- Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: FFI | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Comment (by waern): Please disregard the COMPILATION IS NOT REQUIRED lines in the first console output. I just ran the exact same command twice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 7 14:54:35 2009 From: trac at galois.com (GHC) Date: Sat Feb 7 14:44:30 2009 Subject: [GHC] #2358: Template Haskell's TupleT considers unary tuples as a valid types. In-Reply-To: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> References: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> Message-ID: <052.4847fd1eac0158df5872be42a577a347@localhost> #2358: Template Haskell's TupleT considers unary tuples as a valid types. ---------------------------------+------------------------------------------ Reporter: fons | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: TH_1tuple | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by SamB): Does this raise an error in 6.10, then? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 7 15:04:28 2009 From: trac at galois.com (GHC) Date: Sat Feb 7 14:54:23 2009 Subject: [GHC] #3009: ghci-6.10.1 has odd buffering behavior Message-ID: <045.9392d08426c5a478bc5d94d5d63b840d@localhost> #3009: ghci-6.10.1 has odd buffering behavior --------------------+------------------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- In ghci-6.10.1: {{{ Prelude> :m +System.IO Prelude System.IO> hGetBuffering stdin NoBuffering Prelude System.IO> getChar asdf 'a' Prelude System.IO> sdf :1:0: Not in scope: `sdf' Prelude System.IO> }}} That is, even though stdin is supposed to be unbuffered, getChar doesn't return until {{{'\n'}}} is entered. The above works correctly in ghci-6.8.3. Also, manually setting the buffering in ghci-6.10.1 works, but only for the duration of one statement: {{{ Prelude System.IO> hSetBuffering stdin NoBuffering >> getChar a'a' Prelude System.IO> getChar asdf 'a' Prelude System.IO> sdf :1:0: Not in scope: `sdf' Prelude System.IO> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 7 15:07:43 2009 From: trac at galois.com (GHC) Date: Sat Feb 7 14:57:39 2009 Subject: [GHC] #2358: Template Haskell's TupleT considers unary tuples as a valid types. In-Reply-To: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> References: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> Message-ID: <052.371caf04804d8f9733fcbb855266828d@localhost> #2358: Template Haskell's TupleT considers unary tuples as a valid types. ---------------------------------+------------------------------------------ Reporter: fons | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: TH_1tuple | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by SamB): #haskell tells me it works fine when you run this (with -fth): {{{ Prelude Language.Haskell.TH> $(sigE [|1|] (appT (tupleT 1) [t|Int|])) }}} So I guess the solution chosen was to behave as expected, not as proposed by fons. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 7 20:51:29 2009 From: trac at galois.com (GHC) Date: Sat Feb 7 20:41:22 2009 Subject: [GHC] #3010: "RegAllocLinear.getStackSlotFor: out of stack slots" ghc 6.10.1 for i386-unknown-mingw32 compiling Crypto-4.1.0 Message-ID: <048.19a2a630688462587678f67947378d66@localhost> #3010: "RegAllocLinear.getStackSlotFor: out of stack slots" ghc 6.10.1 for i386 -unknown-mingw32 compiling Crypto-4.1.0 ----------------------+----------------------------------------------------- Reporter: agocorona | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- compiling Crypto-4.1.0 .............. ............... [1 of 4] Compiling Codec.Utils ( Codec\Utils.hs, dist\build\SHA1Test\SHA1Te st-tmp\Codec\Utils.o ) [2 of 4] Compiling Data.Digest.SHA1 ( Data\Digest\SHA1.hs, dist\build\SHA1Test\S HA1Test-tmp\Data\Digest\SHA1.o ) [3 of 4] Compiling Codec.Text.Raw ( Codec\Text\Raw.hs, dist\build\SHA1Test\SHA 1Test-tmp\Codec\Text\Raw.o ) [4 of 4] Compiling Main ( SHA1Test.hs, dist\build\SHA1Test\SHA1Test- tmp\Main.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 8 06:19:29 2009 From: trac at galois.com (GHC) Date: Sun Feb 8 06:09:27 2009 Subject: [GHC] #3010: "RegAllocLinear.getStackSlotFor: out of stack slots" ghc 6.10.1 for i386-unknown-mingw32 compiling Crypto-4.1.0 In-Reply-To: <048.19a2a630688462587678f67947378d66@localhost> References: <048.19a2a630688462587678f67947378d66@localhost> Message-ID: <057.72b1d1d511ea717df91802d4a13ac5e0@localhost> #3010: "RegAllocLinear.getStackSlotFor: out of stack slots" ghc 6.10.1 for i386 -unknown-mingw32 compiling Crypto-4.1.0 -----------------------+---------------------------------------------------- Reporter: agocorona | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Testcase: Os: Windows | Architecture: x86 -----------------------+---------------------------------------------------- Changes (by Deewiant): * status: new => closed * resolution: => duplicate Comment: Duplicate of #3006, #2967, #2919, #2771, and #2753. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 8 06:19:41 2009 From: trac at galois.com (GHC) Date: Sun Feb 8 06:09:42 2009 Subject: [GHC] #3006: ghc panic when build Crypto package on Mac OS X 10.4 In-Reply-To: <046.629ad49a03e788e7c02f0b312b20f479@localhost> References: <046.629ad49a03e788e7c02f0b312b20f479@localhost> Message-ID: <055.e806799eea106ec0a7a3d5fb0b81e685@localhost> #3006: ghc panic when build Crypto package on Mac OS X 10.4 ----------------------+----------------------------------------------------- Reporter: alexott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Changes (by Deewiant): * status: new => closed * resolution: => duplicate Comment: Duplicate of #2967, #2919, #2771, and #2753. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 8 14:06:34 2009 From: trac at galois.com (GHC) Date: Sun Feb 8 13:56:31 2009 Subject: [GHC] #2913: OldException's catch etc should treat new Exception types as DynException's In-Reply-To: <044.32b88c5c6278c8a1dcec6524f5b05c54@localhost> References: <044.32b88c5c6278c8a1dcec6524f5b05c54@localhost> Message-ID: <053.e8f831e5f9a53f43059bf44b3a0d884a@localhost> #2913: OldException's catch etc should treat new Exception types as DynException's ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: OldException001 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * testcase: => OldException001 * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10 branches: {{{ Mon Feb 2 15:18:56 GMT 2009 Ian Lynagh * OldException catches unknown exceptions as DynException It's important that we put all exceptions into the old Exception type somehow, or throwing a new exception wouldn't cause the cleanup code for bracket, finally etc to happen. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 8 17:34:05 2009 From: trac at galois.com (GHC) Date: Sun Feb 8 17:23:58 2009 Subject: [GHC] #3011: ASSERT failed: file typecheck/TcMType.lhs line 526 t_a32G{tv} Message-ID: <053.fd6df4dcc16e4e1cfe771d7b12ab290f@localhost> #3011: ASSERT failed: file typecheck/TcMType.lhs line 526 t_a32G{tv} -----------------------------+---------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- NB: this is NOT AFAIK a duplicate of the previous ticket about the TcMType ASSERT failure. It was observed on a recent HEAD (as of 6th February 2009) while I happened to be using a stage 2 compiler with -DDEBUG on to compile some code I was working on. Error is as follows: {{{ $ ./Setup clean && ./Setup configure --with- compiler=/Users/mbolingbroke/Programming/Checkouts/ghc.working/ghc/stage2-inplace/ghc --with-hc- pkg=/Users/mbolingbroke/Programming/Checkouts/ghc.working/ghc/stage2-inplace /ghc-pkg --ghc --global && ./Setup build && dist/build/vector-tests /vector-tests cleaning... Configuring vector-tests-0.2... Preprocessing executables for vector-tests-0.2... Building vector-tests-0.2... [1 of 3] Compiling Utilities ( Utilities.hs, dist/build/vector- tests/vector-tests-tmp/Utilities.o ) WARNING: file simplCore/SimplCore.lhs line 545 Simplifier still going after 4 iterations; bailing out. Size = 1398 [2 of 3] Compiling Properties ( Properties.hs, dist/build/vector- tests/vector-tests-tmp/Properties.o ) WARNING: file typecheck/TcTyFuns.lhs line 284 (This warning is harmless; for Simon & Manuel) [Wanted t_a32G{tv} [tau] :: ghc-prim:GHC.Types.[]{(w) tc 317} ~ v{tv a2S9} [sk]] ghc: panic! (the 'impossible' happened) (GHC version 6.11.20090204 for i386-apple-darwin): ASSERT failed! file typecheck/TcMType.lhs line 526 t_a32G{tv} [tau] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Where that code look something like this: {{{ do { ASSERTM2( do { details <- readMetaTyVar tyvar; return (isFlexi details) }, ppr tyvar ) ; traceTc (text "writeMetaTyVar" <+> ppr tyvar <+> text ":=" <+> ppr ty) ; writeMutVar (metaTvRef tyvar) (Indirect ty) } }}} Full program is attached. Actually, the program has a type error (as rerunning with a non -DDEBUG build showed): {{{ Properties.hs:78:25: Could not deduce (Data.Vector.Unboxed.IVector [] a) from the context (Eq a, Ord a, Eq (v a), Ord (v a), Show a, Arbitrary a, Model a a, Show (v a), Arbitrary (v a), Model (v a) [a], Data.Vector.Unboxed.IVector v a, Show (v Bool), Arbitrary (v Bool), Model (v Bool) [Bool], Data.Vector.Unboxed.IVector v Bool) arising from a use of `Data.Vector.Unboxed.length' at Properties.hs:78:25-32 Possible fix: add (Data.Vector.Unboxed.IVector [] a) to the context of the type signature for `testVersusLists' or add an instance declaration for (Data.Vector.Unboxed.IVector [] a) In the first argument of `eq1', namely `(Data.Vector.Unboxed.length :: v a -> Int)' In the expression: (Data.Vector.Unboxed.length :: v a -> Int) `eq1` length In the definition of `prop_length': prop_length = (Data.Vector.Unboxed.length :: v a -> Int) `eq1` length Properties.hs:83:25: No instance for (Data.Vector.Unboxed.IVector [] Bool) arising from a use of `Data.Vector.Unboxed.and' at Properties.hs:83:25-29 Possible fix: add an instance declaration for (Data.Vector.Unboxed.IVector [] Bool) In the first argument of `eq1', namely `(Data.Vector.Unboxed.and :: v Bool -> Bool)' In the expression: (Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and In the definition of `prop_and': prop_and = (Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and Properties.hs:95:24: Could not deduce (Eq ([a] -> [a])) from the context (Eq a, Ord a, Eq (v a), Ord (v a), Show a, Arbitrary a, Model a a, Show (v a), Arbitrary (v a), Model (v a) [a], Data.Vector.Unboxed.IVector v a, Show (v Bool), Arbitrary (v Bool), Model (v Bool) [Bool], Data.Vector.Unboxed.IVector v Bool) arising from a use of `eq2' at Properties.hs:95:24-86 Possible fix: add (Eq ([a] -> [a])) to the context of the type signature for `testVersusLists' or add an instance declaration for (Eq ([a] -> [a])) In the expression: (Data.Vector.Unboxed.zipWith :: (a -> a -> a) -> v a -> v a -> v a) `eq2` zipWith In the definition of `prop_zipWith': prop_zipWith = (Data.Vector.Unboxed.zipWith :: (a -> a -> a) -> v a -> v a -> v a) `eq2` zipWith In the definition of `testVersusLists': testVersusLists _ = [testGroup "Prelude" prelude_tests, testGroup "Data.List" data_list_tests, testGroup "Extras" extra_tests] where prelude_tests = [testProperty "length" prop_length, ....] prop_length = (Data.Vector.Unboxed.length :: v a -> Int) `eq1` length prop_null = (Data.Vector.Unboxed.null :: v a -> Bool) `eq1` null prop_and = (Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and .... Properties.hs:114:25: Couldn't match expected type `v' against inferred type `[]' `v' is a rigid type variable bound by the type signature for `testVersusLists' at Properties.hs:19:28 In the first argument of `eq2', namely `(enumFromTo :: a -> a -> v a)' In the expression: (enumFromTo :: a -> a -> v a) `eq2` enumFromTo In the definition of `prop_enumFromTo': prop_enumFromTo = (enumFromTo :: a -> a -> v a) `eq2` enumFromTo Properties.hs:115:76: Could not deduce (Enum a) from the context (Eq a, Ord a, Eq (v a), Ord (v a), Show a, Arbitrary a, Model a a, Show (v a), Arbitrary (v a), Model (v a) [a], Data.Vector.Unboxed.IVector v a, Show (v Bool), Arbitrary (v Bool), Model (v Bool) [Bool], Data.Vector.Unboxed.IVector v Bool) arising from a use of `enumFromThenTo' at Properties.hs:115:76-89 Possible fix: add (Enum a) to the context of the type signature for `testVersusLists' In the second argument of `eq3', namely `enumFromThenTo' In the expression: (enumFromThenTo :: a -> a -> a -> v a) `eq3` enumFromThenTo In the definition of `prop_enumFromThenTo': prop_enumFromThenTo = (enumFromThenTo :: a -> a -> a -> v a) `eq3` enumFromThenTo Properties.hs:176:16: Could not deduce (Model [a] [a]) from the context (Eq a, Ord a, Eq (v a), Ord (v a), Show a, Arbitrary a, Model a a, Show (v a), Arbitrary (v a), Model (v a) [a], Data.Vector.Unboxed.IVector v a, Show (v Bool), Arbitrary (v Bool), Model (v Bool) [Bool], Data.Vector.Unboxed.IVector v Bool) arising from a use of `eq2' at Properties.hs:176:16-71 Possible fix: add (Model [a] [a]) to the context of the type signature for `testVersusLists' or add an instance declaration for (Model [a] [a]) In the expression: (Data.Vector.Unboxed.snoc :: v a -> a -> v a) `eq2` snoc In the definition of `prop_snoc': prop_snoc = (Data.Vector.Unboxed.snoc :: v a -> a -> v a) `eq2` snoc In the definition of `testVersusLists': testVersusLists _ = [testGroup "Prelude" prelude_tests, testGroup "Data.List" data_list_tests, testGroup "Extras" extra_tests] where prelude_tests = [testProperty "length" prop_length, ....] prop_length = (Data.Vector.Unboxed.length :: v a -> Int) `eq1` length prop_null = (Data.Vector.Unboxed.null :: v a -> Bool) `eq1` null prop_and = (Data.Vector.Unboxed.and :: v Bool -> Bool) `eq1` and .... }}} But we probably still shouldn't get the ASSERT. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 8 18:53:48 2009 From: trac at galois.com (GHC) Date: Sun Feb 8 18:44:03 2009 Subject: [GHC] #2883: setitimer(ITIMER_VIRTUAL) is not always available In-Reply-To: <047.b40f4ae8b455c2e4eb614a1510a0781b@localhost> References: <047.b40f4ae8b455c2e4eb614a1510a0781b@localhost> Message-ID: <056.5866dd7643a23b3b128e6d43fef162fa@localhost> #2883: setitimer(ITIMER_VIRTUAL) is not always available ---------------------------------+------------------------------------------ Reporter: sthibaul | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Applied to HEAD and 6.10 branch: {{{ Sun Feb 8 11:14:31 PST 2009 Ian Lynagh * Handle the case where setitimer(ITIMER_VIRTUAL) is not always available Patch from sthibaul. Fixes trac #2883. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 8 18:58:13 2009 From: trac at galois.com (GHC) Date: Sun Feb 8 18:48:03 2009 Subject: [GHC] #3002: Documentation for Data.Map.unionWithKey makes reference to "new" and "old" values which have no meaning in a union. In-Reply-To: <044.1d80fe5dfcd11073b7f22437a5d4d912@localhost> References: <044.1d80fe5dfcd11073b7f22437a5d4d912@localhost> Message-ID: <053.a090a920354146e117417cdf3959768e@localhost> #3002: Documentation for Data.Map.unionWithKey makes reference to "new" and "old" values which have no meaning in a union. ----------------------------------+----------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: libraries (other) | Version: 6.10.1 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10-branch: {{{ Sun Feb 8 11:21:32 PST 2009 Ian Lynagh * Use left/right rather than old/new to describe the arguments to unionWithKey Fixes trac #3002. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 8 19:04:34 2009 From: trac at galois.com (GHC) Date: Sun Feb 8 18:54:26 2009 Subject: [GHC] #2709: System.Directory.doesDirectoryExist "\\" is False on Windows In-Reply-To: <047.62ffe3d738f377c87f772b23e67bd03b@localhost> References: <047.62ffe3d738f377c87f772b23e67bd03b@localhost> Message-ID: <056.c56e1859d79959a229bfb72ef7a34ab9@localhost> #2709: System.Directory.doesDirectoryExist "\\" is False on Windows ------------------------------------+--------------------------------------- Reporter: Deewiant | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10 branch: {{{ Sun Feb 8 11:16:54 PST 2009 Ian Lynagh * Make dropTrailingPathSeparator not return empty string dropTrailingPathSeparator "\\" was evaluating to "". Now if it would return "" it returns a single path separator instead. Fixes trac #2709. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 8 20:13:28 2009 From: trac at galois.com (GHC) Date: Sun Feb 8 20:03:25 2009 Subject: [GHC] #3005: Normalize fully-applied type functions prior to display In-Reply-To: <047.30459bfff0d7f26f031112d1ec205050@localhost> References: <047.30459bfff0d7f26f031112d1ec205050@localhost> Message-ID: <056.aa217b8d99da9acd14c16bcac4468afa@localhost> #3005: Normalize fully-applied type functions prior to display ------------------------------+--------------------------------------------- Reporter: dmcclean | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by chak): * owner: => chak Comment: The problem is that sometime you want types to be normalised (like here), and sometimes, you prefer them non-normalised (e.g, when the normalised types get large). Currently, GHC tries to hard to print types with as little normalisation as possible (e.g, it prints `String` instead of `[Char]`). So far, my plan was to leave that as it is, but provide a new ghci command to normalise a given type. This is useful for type-level programs (like in your code) without affecting the standard output. An extra ghci command has the advantage that you can "evaluate" type functions without needing to construct values that have the type that you want to evaluate (for `:t` you always need to supply an appropriate expression). Given your experience, would a new ghci command as described be sufficient for your purposes (without altering the behaviour of `:t`)? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 8 20:22:50 2009 From: trac at galois.com (GHC) Date: Sun Feb 8 20:12:48 2009 Subject: [GHC] #2739: GHC API crashes on template haskell splices In-Reply-To: <044.3bac7d34665c04ceca674c8a12436d56@localhost> References: <044.3bac7d34665c04ceca674c8a12436d56@localhost> Message-ID: <053.b514969e6beb4ebc227f72e27398b836@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: nominolo Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: sanzhiyan@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 9 04:27:34 2009 From: trac at galois.com (GHC) Date: Mon Feb 9 04:17:35 2009 Subject: [GHC] #3005: Normalize fully-applied type functions prior to display In-Reply-To: <047.30459bfff0d7f26f031112d1ec205050@localhost> References: <047.30459bfff0d7f26f031112d1ec205050@localhost> Message-ID: <056.2f2db8b52847c076fe001eb4ba65116f@localhost> #3005: Normalize fully-applied type functions prior to display ------------------------------+--------------------------------------------- Reporter: dmcclean | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by dreixel): * cc: jpm@cs.uu.nl (added) Comment: I would be happy with a new ghci command. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 9 04:28:12 2009 From: trac at galois.com (GHC) Date: Mon Feb 9 04:18:03 2009 Subject: [GHC] #2358: Template Haskell's TupleT considers unary tuples as a valid types. In-Reply-To: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> References: <043.f22163bf02ff2ecbb2b6874f8a72bacc@localhost> Message-ID: <052.2e5c3dfc13383db79cf8ea2a0e2d7604@localhost> #2358: Template Haskell's TupleT considers unary tuples as a valid types. ---------------------------------+------------------------------------------ Reporter: fons | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: TH_1tuple | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): That's right. `TupleT [t]`, `TupE [e]`, and `TupP [p]`, all behave like `t`, `e` and `p` respectively, at least in the HEAD. That seemed more helpful than failing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 9 04:45:55 2009 From: trac at galois.com (GHC) Date: Mon Feb 9 04:35:45 2009 Subject: [GHC] #3011: ASSERT failed: file typecheck/TcMType.lhs line 526 t_a32G{tv} In-Reply-To: <053.fd6df4dcc16e4e1cfe771d7b12ab290f@localhost> References: <053.fd6df4dcc16e4e1cfe771d7b12ab290f@localhost> Message-ID: <062.5051fe3c39a7af273de36befda9ef559@localhost> #3011: ASSERT failed: file typecheck/TcMType.lhs line 526 t_a32G{tv} ----------------------------------------+----------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: I'm 99% sure that it's simply the same bug as #2999. By turning that ASSERT into a WARN, I simply made another ASSERT trigger! So I'm going to turn that into a WARN for now. We can turn it back into an assert when we fix the original bug. So this is very much a short term measure. I'll leave this bug open to remind us to change it back. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 9 05:16:09 2009 From: trac at galois.com (GHC) Date: Mon Feb 9 05:06:02 2009 Subject: [GHC] #2980: Data.Generics reports wrong package? In-Reply-To: <046.f7418eb0a17f24f43c739702ff117886@localhost> References: <046.f7418eb0a17f24f43c739702ff117886@localhost> Message-ID: <055.fee37c33157db3d52e5a189c0396e8c2@localhost> #2980: Data.Generics reports wrong package? ----------------------------------+----------------------------------------- Reporter: Martijn | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: I fixed the error message to list all the packages: {{{ Fri Feb 6 16:57:43 GMT 2009 Simon Marlow * Improvements to the "can't find module" error message (#2980) If the module was found in multiple hidden packages, we list them all. Could not find module `Data.Generics': it is a member of the hidden package `base-3.0.3.0' it is a member of the hidden package `syb' Use -v to see a list of the files searched for. }}} The documentation for `Data.Generics` does say that it comes from package `syb`: [http://www.haskell.org/ghc/docs/latest/html/libraries/syb/Data- Generics.html]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 9 05:19:21 2009 From: trac at galois.com (GHC) Date: Mon Feb 9 05:09:11 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.f85bab465e4bcce833efe6f9389fef7c@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ---------------------------------+------------------------------------------ Reporter: dsf | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Fri Feb 6 16:59:12 GMT 2009 Simon Marlow * Fix #2971: we had lost the non-blocking flag on Handles created by openFile This code is a mess, fortunately the new IO library cleans it up. }}} reading `/proc/mounts` works: {{{ Prelude> readFile "/proc/mounts" "rootfs / rootfs rw 0 0\n/dev/root / ext3 ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 9 06:15:03 2009 From: trac at galois.com (GHC) Date: Mon Feb 9 06:04:53 2009 Subject: [GHC] #2998: Expose the internals of the network library to make it more extensible In-Reply-To: <044.38e242663cf791489f4226de94cd9e56@localhost> References: <044.38e242663cf791489f4226de94cd9e56@localhost> Message-ID: <053.67104b3d7857a4b4a953bb6ea36c5e15@localhost> #2998: Expose the internals of the network library to make it more extensible ----------------------------------+----------------------------------------- Reporter: tibbe | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by felixmar): I support this proposal. Please also include sizeOfSockAddr_Family in the Network.Socket.Internal module. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 9 07:03:53 2009 From: trac at galois.com (GHC) Date: Mon Feb 9 06:53:58 2009 Subject: [GHC] #3012: A little deriving for GADTs Message-ID: <044.94324394f531ef37390c0c5f7ffabb55@localhost> #3012: A little deriving for GADTs -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- For GADTs that are really enumerations, I think deriving Show should work. E.g. {{{ data T a where Foo :: T Int Bar :: T Bool deriving (Show) }}} There's no(?) intricate behaviour of the derived functions, so why not? -- Lennart -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 9 10:01:22 2009 From: trac at galois.com (GHC) Date: Mon Feb 9 09:51:11 2009 Subject: [GHC] #2916: Adding "-auto-all" when using "-O2 -prof" causes "<>" In-Reply-To: <049.104e5ce0692c10d94ee0be86a698b1ee@localhost> References: <049.104e5ce0692c10d94ee0be86a698b1ee@localhost> Message-ID: <058.c7ef272de48d0a1e2b23c0eb3ca3fa17@localhost> #2916: Adding "-auto-all" when using "-O2 -prof" causes "<>" ------------------------------+--------------------------------------------- Reporter: BenMoseley | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: loop auto-all | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ------------------------------+--------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: So what happened here is that GHC decided to transform this {{{ hashConser e = deepSeq e (unsafePerformIO $ mkHC' e) }}} into this {{{ hashConser e = case unsafePerformIO $ mkHC' e of x -> deepSeq e x }}} which it is allowed to do, because `deepSeq` is strict in both its arguments. But the second version has different behaviour in this case, due to the use of `unsafePerformIO`. Consider this call to `hashConser`: {{{ hashConser (hashConser X) }}} the first call to `hashConser` is passed the (unevaluated) `hashConser X` as its argument. The first thing it does is to write into the memo table `Map.insert e ehc tbl`, where `e` is `hashConser X`. This causes the evaluation of `e`, which tries to look up in the hash table, leading to a loop. GHC isn't breaking the rules here, I think. It is confusing that the unexpected behaviour only happens with `-auto-all`, but that's the nature of `unsafePerformIO`: it's possible to write programs that have non- deterministic behaviour. You can fix it by using `Control.Parallel.pseq` instead of `seq` in the definition of `deepSeq`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 9 11:28:36 2009 From: trac at galois.com (GHC) Date: Mon Feb 9 11:18:37 2009 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> Message-ID: <060.6223d085648b707c7d44eda76c0606b1@localhost> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by fasta): * cc: ron@gamr7.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 9 12:55:52 2009 From: trac at galois.com (GHC) Date: Mon Feb 9 12:45:49 2009 Subject: [GHC] #3012: A little deriving for GADTs In-Reply-To: <044.94324394f531ef37390c0c5f7ffabb55@localhost> References: <044.94324394f531ef37390c0c5f7ffabb55@localhost> Message-ID: <053.da8f979b65265ba9c991d2e89930a323@localhost> #3012: A little deriving for GADTs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Good suggestion. In general I'm all for it. But why just `Show`? And is enumerations the right restriction? I suppose you could say that any extra stuff is an improvement, but the less ad hoc the better. In general, to do 'deriving' you need to solve two problems 1. Figure out the right context for the instance declaration. 2. Guarantee the the code generated for the instance will typecheck. There are plenty of details. For example, (1) isn't necessary for "standalone deriving" because the programmer specifies the context. If he specifies the wrong context, the generated instance may not typecheck, so we cannot guarantee (2). So perhaps we should accept ANY data type (GADT or whatever) with standalone deriving, and say "it's your fault" if the derived code doesn't typecheck? I don't have a strong position on any of this. If someone wants to figure out the detailed spec, implementation is probably not hard. Simon (Lennart, are you sure you don't want a Trac login of your own?) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 9 14:20:55 2009 From: trac at galois.com (GHC) Date: Mon Feb 9 14:10:57 2009 Subject: [GHC] #3013: New simple GADT feature Message-ID: <044.28ccf32146b8a6f2dca8fc7552e2ce8a@localhost> #3013: New simple GADT feature -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It's somewhat of an anomaly that the following does not work: {{{ data T where Foo, Bar :: Int -> T }}} Since the comma syntax works for type signatures and records it would be natural for it to work with GADTs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 04:17:53 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 04:07:41 2009 Subject: [GHC] #3014: Any type being derived in Haskell 98 module Message-ID: <044.9ea2d924c5e505c6225eb8af4944504d@localhost> #3014: Any type being derived in Haskell 98 module -----------------------------+---------------------------------------------- Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: any type | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Load the attached module with ghci -ignore-dot-ghci, do :browse and observe the type of z, z :: GHC.Prim.Any -> Double -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 04:46:10 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 04:35:58 2009 Subject: [GHC] #3014: Any type being derived in Haskell 98 module In-Reply-To: <044.9ea2d924c5e505c6225eb8af4944504d@localhost> References: <044.9ea2d924c5e505c6225eb8af4944504d@localhost> Message-ID: <053.6dbf4d2c5efe7a6d59bcadb4fceb74b4@localhost> #3014: Any type being derived in Haskell 98 module -------------------------------------+-------------------------------------- Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: any type | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- Comment (by duncan): Hugs says: {{{ z :: a -> Double }}} ghci-6.6.1 says: {{{ z :: () -> Double }}} ghci-6.8.2 and ghci-6.10.1 say: {{{ z :: GHC.Prim.Any -> Double }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 11:20:25 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 11:10:20 2009 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.98ba6f02578c46652cb9ac9040b0e760@localhost> #1074: -fwarn-unused-imports complains about wrong import ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: 6.10.2 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 11:20:34 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 11:10:22 2009 Subject: [GHC] #1136: High memory use when compiling many let bindings. In-Reply-To: <044.2f9aae100a9caba688d31e410efb3444@localhost> References: <044.2f9aae100a9caba688d31e410efb3444@localhost> Message-ID: <053.08221560a330af82350799faa4be56d7@localhost> #1136: High memory use when compiling many let bindings. ---------------------------------------------+------------------------------ Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * milestone: 6.10.2 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 11:20:52 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 11:10:39 2009 Subject: [GHC] #2267: Bogus "unused import" warning In-Reply-To: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> References: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> Message-ID: <055.a4f543e8820735fe8e22d2abe8bcb09a@localhost> #2267: Bogus "unused import" warning ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: 6.10.2 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 11:26:30 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 11:16:15 2009 Subject: [GHC] #2889: Compilation fails - Can't opne temporary In-Reply-To: <046.8fe469503d4d0471dd07d5bc59e9501a@localhost> References: <046.8fe469503d4d0471dd07d5bc59e9501a@localhost> Message-ID: <055.a1c56fe061d6303f8ee87ab7b3d6c26c@localhost> #2889: Compilation fails - Can't opne temporary -------------------------+-------------------------------------------------- Reporter: fobrock | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by igloo): fobrock, can you please add the `-v` flag to your GHC commandline, and paste the output here? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 14:45:48 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 14:35:35 2009 Subject: [GHC] #2894: Documentation for "even" missing In-Reply-To: <051.915bb1c85de628cda06f20972aedc55e@localhost> References: <051.915bb1c85de628cda06f20972aedc55e@localhost> Message-ID: <060.4fe28a2120ed65d86048a444b23458f1@localhost> #2894: Documentation for "even" missing ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now fixed in HEAD and 6.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 14:47:55 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 14:37:40 2009 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.93cd78a4e9d2fb0416ae41738e0587f6@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: All 3 merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 16:54:06 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 16:43:53 2009 Subject: [GHC] #2980: Data.Generics reports wrong package? In-Reply-To: <046.f7418eb0a17f24f43c739702ff117886@localhost> References: <046.f7418eb0a17f24f43c739702ff117886@localhost> Message-ID: <055.bb7e3c66032c4062b7640389d1edde6d@localhost> #2980: Data.Generics reports wrong package? ----------------------------------+----------------------------------------- Reporter: Martijn | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 16:54:57 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 16:44:44 2009 Subject: [GHC] #2971: readFile "/proc/mounts" hangs on an amd64 machine In-Reply-To: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> References: <042.58c8b1f5b64b5fd351e834dd0235fad4@localhost> Message-ID: <051.4a1c1960939c28e975e407ecdab8c423@localhost> #2971: readFile "/proc/mounts" hangs on an amd64 machine ---------------------------------+------------------------------------------ Reporter: dsf | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 17:56:55 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 17:46:40 2009 Subject: [GHC] #3015: Building packages using ghc (6.8.2) results in inconsistent error assembler messages Message-ID: <046.693b020b64cc705b3137297db374c5fe@localhost> #3015: Building packages using ghc (6.8.2) results in inconsistent error assembler messages -----------------------------+---------------------------------------------- Reporter: akrohit | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- akrohit@illusion:~/tmp/ghc-6.8.2$ uname -a Linux illusion 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux akrohit@illusion:~/tmp/ghc-6.8.2$ gcc --version gcc (GCC) 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3) akrohit@illusion:~/tmp/ghc-6.8.2$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 Whenever installing any package using cabal or building packages locally results in some error messages of something like : /tmp/ghc10273_0/ghc10273_0.s: Assembler messages: /tmp/ghc10273_0/ghc10273_0.s:2502:0: Error: junk at end of line, first unrecognized character is `8' /tmp/ghc10273_0/ghc10273_0.s:2830:0: Error: unknown pseudo-op: `.aligo' <> make[2]: *** [Distribution/Compiler.o] Error 1 make[1]: *** [boot] Error 2 make: *** [stage1] Error 1 These error messages are not consistent. Above also results with gcc version 4.3.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 17:58:16 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 17:48:03 2009 Subject: [GHC] #3015: Building packages using ghc (6.8.2) results in inconsistent error assembler messages In-Reply-To: <046.693b020b64cc705b3137297db374c5fe@localhost> References: <046.693b020b64cc705b3137297db374c5fe@localhost> Message-ID: <055.755689ff4719ba3c9c5910017fd6358b@localhost> #3015: Building packages using ghc (6.8.2) results in inconsistent error assembler messages ----------------------+----------------------------------------------------- Reporter: akrohit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Changes (by akrohit): * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 19:09:55 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 18:59:41 2009 Subject: [GHC] #1502: GHC should integrate better with mingw In-Reply-To: <047.b7395f3fc65ee001157bf44a9570b106@localhost> References: <047.b7395f3fc65ee001157bf44a9570b106@localhost> Message-ID: <056.f0bf66b3e92352ef7296cc248d28e857@localhost> #1502: GHC should integrate better with mingw ---------------------------------+------------------------------------------ Reporter: eivuokko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: windows | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: 6.10.2 => 6.12 branch Comment: We'll do this for the new build system, as we need to rewrite the code to put gcc etc in the right place anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 19:28:23 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 19:18:08 2009 Subject: [GHC] #3016: Long compile times, large memory use with static data in 6.10 Message-ID: <043.860ff3ba501bcb6418e5778e2c5eff65@localhost> #3016: Long compile times, large memory use with static data in 6.10 -----------------------------+---------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: static data | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- A collection of modules like this, when compiled together, are taking 2 1/2 hrs to compile with ghc 6.10, up from 30 mins with 6.8.x This is slowing down a work project somewhat. Attached is a sample module, that should illustrate the problem, when compiled ghc uses 2G and takes a few minutes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 10 19:32:26 2009 From: trac at galois.com (GHC) Date: Tue Feb 10 19:22:11 2009 Subject: [GHC] #3016: Long compile times, large memory use with static data in 6.10 In-Reply-To: <043.860ff3ba501bcb6418e5778e2c5eff65@localhost> References: <043.860ff3ba501bcb6418e5778e2c5eff65@localhost> Message-ID: <052.a99dde7e18b5f286a538abec35ac8226@localhost> #3016: Long compile times, large memory use with static data in 6.10 ------------------------------+--------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: static data | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by awick): * cc: awick (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 04:28:39 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 04:24:42 2009 Subject: [GHC] #2992: GHCi Memory Leak in Windows Vista In-Reply-To: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> References: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> Message-ID: <053.31af74011d1919c5991857be85460a84@localhost> #2992: GHCi Memory Leak in Windows Vista -----------------------+---------------------------------------------------- Reporter: Andir | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Comment (by guest): Problem does *not* show up on Windows XP. On Vista present on GHC 6.8.any and 6.10.1. Also it is easier to just start compilation ghc --make of larger part of software (larger package from hackage). The "for /L" method sometimes leaves slots of time between compilations for GHCi to do garbage collection. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 04:44:20 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 04:34:04 2009 Subject: [GHC] #2986: :info printing instances often isn't wanted In-Reply-To: <043.cc7348275a1e64e6491d1ee94042b0a6@localhost> References: <043.cc7348275a1e64e6491d1ee94042b0a6@localhost> Message-ID: <052.21516feef6d3c2cf8901f1639dba2ec5@localhost> #2986: :info printing instances often isn't wanted ---------------------------------+------------------------------------------ Reporter: Remi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: :info instances | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Capturing a bit more email; Simon M writes: My vote would be: {{{ :info class Show :info type Show :info instance Show }}} where `:info Show` displays information about everything called "Show". I know that classes and types share the same namespace currently, but it might not always be so. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 07:19:30 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 07:09:14 2009 Subject: [GHC] #3017: Type inference is broken when dealing with tuple type synonyms Message-ID: <051.63df5f501a493ca23dd437a940fffbef@localhost> #3017: Type inference is broken when dealing with tuple type synonyms -------------------------+-------------------------------------------------- Reporter: straka.milan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------------+-------------------------------------------------- I have GHC 6.10.1 built from the sources. In the whole bugreport, suppose we have {{{ {-# LANGUAGE TypeFamilies #-} class Coll c where type Elem c empty :: c insert :: Elem c -> c -> c data ListColl a = L [a] instance Coll (ListColl a) where type Elem (ListColl a) = a empty = L [] insert x (L xs) = L (x:xs) emptyL :: ListColl a emptyL = empty }}} GHCI says {{{ test1 c = insert 0 c test2 c = insert (0, 0) c *Main> :t test1 test1 :: (Num (Elem c), Coll c) => c -> c *Main> :t test2 test2 :: ((Integer, Integer) ~ Elem c, Coll c) => c -> c }}} Shouldn't be the type of test2 be something like {{{test2 :: (Num a, Num b, (a, b) ~ (Elem c), Coll c) => c -> c}}} ? When trying {{{ test1 c = insert 0 c test2 c = insert (0, 0) c test3 :: ListColl (Float, Float) test3 = test2 emptyL }}} we get {{{ *Main> :t test2 test2 : ((Float, Float) ~ Elem c, Coll c) => c -> c }}} and {{{ test1 c = insert 0 c test2 c = insert (0, 0) c test3 :: ListColl (Float, Float) test3 = test2 emptyL test3':: ListColl (Int, Int) test3'= test2 emptyL Couldn't match expected type `Int' against inferred type `Float' Expected type: Elem (ListColl (Int, Int)) Inferred type: (Float, Float) When generalising the type(s) for `test3'' Failed, modules loaded: none. }}} and {{{ test1 c = insert 0 c test2 c = insert (0, 0) c test4::(Num a, Num b) => ListColl (a, b) test4 = test2 empty Inferred type is less polymorphic than expected Quantified type variable `b' escapes Quantified type variable `a' escapes When trying to generalise the type inferred for `test4' Signature type: forall a b. (Num a, Num b) => ListColl (a, b) Type to generalise: ListColl (a, b) In the type signature for `test4' When generalising the type(s) for `test4' Failed, modules loaded: none. }}} When adding explicit type signature {{{test2 :: (Num a, Num b, (a, b) ~ (Elem c), Coll c) => c -> c}}} all above examples works correctly, even if GHCI still says {{{ :t test2 *Main> :t test2 test2 :: ((Integer, Integer) ~ Elem c, Coll c) => c -> c }}} Last weird thing is {{{ test5 _ = insert 0 emptyL *Main> :t test5 test5 :: (Num a) => t -> ListColl a test6 _ = insert (0,0) emptyL Ambiguous type variable `t' in the constraint: `Num t' arising from the literal `0' at /work/skola/haskell/grafy/Bug.hs:32:18 Probable fix: add a type signature that fixes these type variable(s) Ambiguous type variable `t1' in the constraint: `Num t1' arising from the literal `0' at /work/skola/haskell/grafy/Bug.hs:32:21 Probable fix: add a type signature that fixes these type variable(s) Failed, modules loaded: none. }}} but adding {{{ test6 :: (Num a, Num b, (a, b) ~ (Elem (ListColl c)), Coll (ListColl c)) => foo -> (ListColl c) test6 _ = insert (0,0) emptyL }}} once again solves the problem. Is this really a bug or just a feature :) I understand that in t1 ~ t2, the t1 and t2 can be arbitraty monotypes, so (a, b) should work, even with Num a and Num b, right? Cheers, Milan Straka -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 09:18:08 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 09:07:50 2009 Subject: [GHC] #2872: sparc -mcpu=v9 is not used in assembly phase In-Reply-To: <045.560447626eec7a2ff3f9465e35a5352d@localhost> References: <045.560447626eec7a2ff3f9465e35a5352d@localhost> Message-ID: <054.03be57abc7a1cc591b3c68419ccc758b@localhost> #2872: sparc -mcpu=v9 is not used in assembly phase -------------------------+-------------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 09:59:40 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 09:49:24 2009 Subject: [GHC] #2871: "Prologue junk?" error when building GHC In-Reply-To: <047.340efbd5b95f62aac88650d45afdbdde@localhost> References: <047.340efbd5b95f62aac88650d45afdbdde@localhost> Message-ID: <056.046eca89111f4aeebc021d77bc549896@localhost> #2871: "Prologue junk?" error when building GHC -------------------------+-------------------------------------------------- Reporter: Deewiant | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 10:34:57 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 10:24:43 2009 Subject: [GHC] #3001: Biographical profiling segfaults In-Reply-To: <042.14ab8fad2945eacc99233583472e718a@localhost> References: <042.14ab8fad2945eacc99233583472e718a@localhost> Message-ID: <051.835277f148184cfefae6cfeb145f72fa@localhost> #3001: Biographical profiling segfaults -------------------------+-------------------------------------------------- Reporter: nad | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 10:46:28 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 10:36:11 2009 Subject: [GHC] #3018: Constraints of function in record appears to nullifiy instance constraints. Message-ID: <051.6f48ec69104cf641686fab51096e5186@localhost> #3018: Constraints of function in record appears to nullifiy instance constraints. -----------------------------+---------------------------------------------- Reporter: ben.kavanagh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- If an field of a record that has constraints in its type, defining a value for this field appears to cause the compiler to ignore outer level constraints declared for an instance. This problem restricts generic functions written in syb-with-class and replib style to functions that do not have constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 11:31:56 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 11:21:40 2009 Subject: [GHC] #2746: Documentation for Haskell 98 modules is empty In-Reply-To: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> References: <047.55938b64a6a9b8fb4713b6865f858c9d@localhost> Message-ID: <056.199c0c94b3cc37ac34b445f852aeb8c9@localhost> #2746: Documentation for Haskell 98 modules is empty ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now working in 6.10 branch and HEAD. Thanks, David! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 11:47:16 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 11:37:00 2009 Subject: [GHC] #2872: sparc -mcpu=v9 is not used in assembly phase In-Reply-To: <045.560447626eec7a2ff3f9465e35a5352d@localhost> References: <045.560447626eec7a2ff3f9465e35a5352d@localhost> Message-ID: <054.ae1c67b34416604cbcd04abf0bbe8ea4@localhost> #2872: sparc -mcpu=v9 is not used in assembly phase -------------------------+-------------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10: {{{ Wed Feb 11 06:16:00 PST 2009 Ian Lynagh * On sparc, pass -mcpu=v9 when assembling with object splitting enabled Fixes trac #2872. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 11:48:46 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 11:38:31 2009 Subject: [GHC] #3001: Biographical profiling segfaults In-Reply-To: <042.14ab8fad2945eacc99233583472e718a@localhost> References: <042.14ab8fad2945eacc99233583472e718a@localhost> Message-ID: <051.3a4a63ddcb9b779bf7a4c4941b0c67a3@localhost> #3001: Biographical profiling segfaults -------------------------+-------------------------------------------------- Reporter: nad | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10: {{{ Wed Feb 11 07:34:57 PST 2009 Ian Lynagh * Fix trac #3001: Biographical profiling segfaults We were zeroing the wrong memory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 11:49:16 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 11:38:57 2009 Subject: [GHC] #2871: "Prologue junk?" error when building GHC In-Reply-To: <047.340efbd5b95f62aac88650d45afdbdde@localhost> References: <047.340efbd5b95f62aac88650d45afdbdde@localhost> Message-ID: <056.9f839601c7bc727bf6e393a2f508a188@localhost> #2871: "Prologue junk?" error when building GHC -------------------------+-------------------------------------------------- Reporter: Deewiant | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10: {{{ Wed Feb 11 07:03:40 PST 2009 Ian Lynagh * Tweak the mangler; fixes trac #2871 It was getting confused by lines like: # 9 "C:\Temp\/ghc620_0/ghc620_0.hc" 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 11:50:45 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 11:48:48 2009 Subject: [GHC] #2992: GHCi Memory Leak in Windows Vista In-Reply-To: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> References: <044.bbcf8b8aa5f153518193d9089d558ebe@localhost> Message-ID: <053.04c013071a7a0cf3db08a255f5dd5192@localhost> #2992: GHCi Memory Leak in Windows Vista -----------------------+---------------------------------------------------- Reporter: Andir | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 12:44:29 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 12:34:11 2009 Subject: [GHC] #2890: Library docs are missing source links In-Reply-To: <047.5d9f8bb2c0907720ec70f2f23485d487@localhost> References: <047.5d9f8bb2c0907720ec70f2f23485d487@localhost> Message-ID: <056.6aec17fe98ba0530ea32cae7c620f0a7@localhost> #2890: Library docs are missing source links ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo Comment: There is HsColoured source in the docs in: {{{ ghc-6.10.1.20090203-i386-unknown-linux.tar.bz2 ghc-6.10.1.20090209-x86_64-unknown-linux.tar.bz2 ghc-6.11.20090130-i386-unknown-linux.tar.bz2 ghc-6.11.20090203-x86_64-unknown-linux.tar.bz2 }}} Still need to check the Windows snapshots. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 12:58:02 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 12:47:43 2009 Subject: [GHC] #3017: Type inference is broken when dealing with tuple type synonyms In-Reply-To: <051.63df5f501a493ca23dd437a940fffbef@localhost> References: <051.63df5f501a493ca23dd437a940fffbef@localhost> Message-ID: <060.ed522cd4a02049f25cf8f819a08384c9@localhost> #3017: Type inference is broken when dealing with tuple type synonyms ---------------------------------------------------+------------------------ Reporter: straka.milan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: indexed-types/should_compile/T3017 | Os: Linux Architecture: x86 | ---------------------------------------------------+------------------------ Changes (by simonpj): * testcase: => indexed-types/should_compile/T3017 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Well spotted. Fixed by {{{ Wed Feb 11 17:47:33 GMT 2009 simonpj@microsoft.com * Fix Trac #3017: ensure that we quantify over enough type variables when equalities are involved }}} Ian: push to the branch if the merge goes smoothly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 13:17:53 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 13:07:38 2009 Subject: [GHC] #3019: sparc membar asm instruction requires mode parameter Message-ID: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> #3019: sparc membar asm instruction requires mode parameter --------------------+------------------------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: rts/testwsdeque.c Os: Solaris | Architecture: sparc --------------------+------------------------------------------------------- The new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`. {{{ EXTERN_INLINE void store_load_barrier(void) { #if i386_HOST_ARCH __asm__ __volatile__ ("lock; addl $0,0(%%esp)" : : : "memory"); #elif x86_64_HOST_ARCH __asm__ __volatile__ ("lock; addq $0,0(%%rsp)" : : : "memory"); #elif powerpc_HOST_ARCH __asm__ __volatile__ ("msync" : : : "memory"); #elif sparc_HOST_ARCH /* Sparc in TSO mode does not require write/write barriers. */ __asm__ __volatile__ ("membar" : : : "memory"); #elif !defined(WITHSMP) return; #else #error memory barriers unimplemented on this architecture #endif }}} In particular for sparc the bit: {{{ /* Sparc in TSO mode does not require write/write barriers. */ __asm__ __volatile__ ("membar" : : : "memory"); }}} This is not right. The membar assembly statement requires a parameter to specify which kind of memory barrier is required. For `store_load_barrier()` it is of course `membar #StoreLoad`. Without this the assembler complains: {{{ /usr/ccs/bin/as: "parallel/WSDeque.s", line 11: error: statement syntax }}} With `#StoreLoad` added it's fine. Note also that the comment appears to be wrong {{{ /* Sparc in TSO mode does not require write/write barriers. */ }}} This is `store_load_barrier()` not `store_store_barrier()` so it is exactly and only this case that is required. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 13:19:48 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 13:09:30 2009 Subject: [GHC] #3020: process 1.0.1.1 compile Message-ID: <048.df95f4a6309fe9fe64b69e181e320d2b@localhost> #3020: process 1.0.1.1 compile ----------------------+----------------------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.8.3 | Severity: normal Keywords: | Testcase: Os: FreeBSD | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Compiling haskell source using the process library version 1.0.1.1 via cabal-install gives compile errors. process.hs : {{{ import System.Process main = runCommand "ls" }}} ghc process.hs : {{{ process.o(.text+0xea): In function `Main_main_info': : undefined reference to `processzm1zi0zi1zi1_SystemziProcess_runCommand_closure' process.o(.text+0x1c3): In function `__stginit_Main_': : undefined reference to `__stginit_processzm1zi0zi1zi1_SystemziProcess_' process.o(.data+0x28): In function `Main_main_srt': : undefined reference to `processzm1zi0zi1zi1_SystemziProcess_runCommand_closure' }}} just importing the library and not using anything it exports still yields the first of the three errors. ghci crashes upon compilation of process-1.0.1.1: {{{ GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :module +System.Process Prelude System.Process> runCommand "ls" Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.1 ... linking ... done. Loading package unix-2.3.0.1 ... linking ... done. Loading package process-1.0.1.1 ... linking ... : internal error: R_X86_64_PC32 relocation out of range: (noname) = 0x7c18012a8 (GHC version 6.8.3 for x86_64_unknown_freebsd) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort (core dumped) }}} ghc --version : {{{ The Glorious Glasgow Haskell Compilation System, version 6.8.3 }}} uname -v {{{ FreeBSD 7.1-RELEASE-p1 #0: Tue Jan 13 00:58:07 UTC 2009 root@:/usr/obj/usr/src/sys/GENERIC }}} ghc-pkg -list {{{ /usr/local/lib/ghc-6.8.3/package.conf: Cabal-1.2.4.0, HUnit-1.2.0.0, QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.2.0, bytestring-0.9.0.1.1, cgi-3001.1.6.0, containers-0.1.0.2, directory-1.0.0.1, fgl-5.4.2.0, filepath-1.1.0.0, (ghc-6.8.3), haskell-src-1.0.1.2, haskell98-1.0.1.0, hpc-0.5.0.1, html-1.0.1.1, mtl-1.1.0.1, network-2.2.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.1, parsec-2.1.0.1, pretty-1.0.0.0, process-1.0.0.1, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.1, template-haskell-2.2.0.0, time-1.1.2.1, unix-2.3.0.1, xhtml-3000.2.0.0 /home/******/.ghc/x86_64-freebsd-6.8.3/package.conf: Cabal-1.6.0.1, HTTP-3001.1.3, X11-1.4.5, X11-xft-0.3, process-1.0.1.1, utf8-string-0.3.4, xmonad-0.8.1, xmonad-contrib-0.8.1, zlib-0.4.0.4 }}} process 1.0.0.0 works just fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 13:28:13 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 13:17:56 2009 Subject: [GHC] #3020: process 1.0.1.1 does not compile In-Reply-To: <048.df95f4a6309fe9fe64b69e181e320d2b@localhost> References: <048.df95f4a6309fe9fe64b69e181e320d2b@localhost> Message-ID: <057.6d54c2905ef60d4e8e2a38a23ecb0ba3@localhost> #3020: process 1.0.1.1 does not compile -------------------------------+-------------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Os: FreeBSD | Architecture: x86_64 (amd64) -------------------------------+-------------------------------------------- Changes (by Philonous): * summary: process 1.0.1.1 compile => process 1.0.1.1 does not compile -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 14:02:43 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 13:52:25 2009 Subject: [GHC] #2972: GHCi broken in GHC 6.10.1 In-Reply-To: <046.36c84703d6f462149fdd781bf29492ec@localhost> References: <046.36c84703d6f462149fdd781bf29492ec@localhost> Message-ID: <055.fd493ce9d41a737759882854d8209bbf@localhost> #2972: GHCi broken in GHC 6.10.1 ------------------------+--------------------------------------------------- Reporter: cemeyer | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: powerpc | ------------------------+--------------------------------------------------- Comment (by int-e): How exactly does it crash? The description so far fits the known libedit problem, #2716 An easy check for that problem is to remove ~/.ghc/ghci_history and then start ghci: if this works (once - ghci will recreate the file on exit), then libedit is the culprit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 14:38:43 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 14:28:26 2009 Subject: [GHC] #2969: unix package built wrong on Solaris In-Reply-To: <045.0d30450289e14ebfae501919df8c4ac3@localhost> References: <045.0d30450289e14ebfae501919df8c4ac3@localhost> Message-ID: <054.21f1a02e88da2e82deaa93113e94338d@localhost> #2969: unix package built wrong on Solaris -------------------------+-------------------------------------------------- Reporter: duncan | Owner: duncan Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by igloo): * owner: => duncan Comment: This should be fixed now: {{{ Wed Feb 11 18:29:06 GMT 2009 Ian Lynagh * Don't put inline'd functions in HsUnix.h; fixes trac #2969 If they are included into a C file which also has certain symbols defined, then the behaviour of the HsUnix.h functions can change (e.g. lstat can become the 32bit, rather than 64bit, version). }}} Duncan, as you have a machine it failed on, is there any chance you could add a test for this please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 15:17:07 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 15:06:57 2009 Subject: [GHC] #2972: GHCi broken in GHC 6.10.1 In-Reply-To: <046.36c84703d6f462149fdd781bf29492ec@localhost> References: <046.36c84703d6f462149fdd781bf29492ec@localhost> Message-ID: <055.ed920d833e3523d6f9ef8620777b7579@localhost> #2972: GHCi broken in GHC 6.10.1 ------------------------+--------------------------------------------------- Reporter: cemeyer | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: powerpc | ------------------------+--------------------------------------------------- Comment (by cemeyer): I don't seem to have a ~/.ghc/ghci_history file (nor a ~/.ghc directory), so this isn't the problem, I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 19:57:11 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 19:46:56 2009 Subject: [GHC] #2890: Library docs are missing source links In-Reply-To: <047.5d9f8bb2c0907720ec70f2f23485d487@localhost> References: <047.5d9f8bb2c0907720ec70f2f23485d487@localhost> Message-ID: <056.f2c09fa7c0552ffb5f0560f3b97e6b56@localhost> #2890: Library docs are missing source links ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Checked: {{{ ghc-6.10.1.20090211-i386-unknown-mingw32.tar.bz2 ghc-6.11.20090211-i386-unknown-mingw32.tar.bz2 }}} All good! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 21:38:53 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 21:28:37 2009 Subject: [GHC] #2839: Integer not documented in latest docs In-Reply-To: <053.5999defb877c69f25bce4ee37808f714@localhost> References: <053.5999defb877c69f25bce4ee37808f714@localhost> Message-ID: <062.3cf11adc094b128eaba48c8095b04c66@localhost> #2839: Integer not documented in latest docs ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: high => normal * milestone: 6.10.2 => 6.12 branch Comment: I've unhidden `GHC.Integer` from haddock for now. A proper fix depends on http://trac.haskell.org/haddock/ticket/24 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 11 22:23:39 2009 From: trac at galois.com (GHC) Date: Wed Feb 11 22:13:20 2009 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output Message-ID: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> #3021: A way to programmatically insert marks into heap profiling output -----------------------------+---------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Component: Profiling Version: 6.10.1 | Severity: normal Keywords: profiling | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This would be useful for e.g. marking compiler phases. Hmm, this would be more useful if the "MARK" record type had a string field... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 01:53:55 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 01:43:37 2009 Subject: [GHC] #3022: ghc: panic! (the 'impossible' happened) linkBCO: >= 64k insns in BCO Message-ID: <044.30ac4f6e3902a654e6966b395559b244@localhost> #3022: ghc: panic! (the 'impossible' happened) linkBCO: >= 64k insns in BCO -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- ghci told me to report a bug: {{{ $ ghci 18.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( 18.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): linkBCO: >= 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > $ ghci --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 $ uname -a Linux ogum 2.6.24-23-generic #1 SMP Mon Jan 26 00:13:11 UTC 2009 i686 GNU/Linux }}} I've attached the offending file, here's the md5sum: {{{ $ md5sum 18.hs 1594c7d5522d0b1d7f1a70f6f3dfc24a 18.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 02:33:58 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 02:23:47 2009 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> References: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> Message-ID: <052.26cd51401ef45deb7c5b724684a45651@localhost> #3021: A way to programmatically insert marks into heap profiling output ------------------------------+--------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: profiling | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): This is a feature that has been part of heap profiling for a long time. See for instance the graphs on p.42 of R?jemo's thesis chapter about space-efficiency in nhc98: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.710 There are marks for the start of the renaming, type-checking, and export phases. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 04:24:47 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 04:14:28 2009 Subject: [GHC] #3019: sparc membar asm instruction requires mode parameter In-Reply-To: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> References: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> Message-ID: <054.ba8ec33357e8cec2e2d0a60b3c2f8c4d@localhost> #3019: sparc membar asm instruction requires mode parameter ----------------------------------+----------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rts/testwsdeque.c | Os: Solaris Architecture: sparc | ----------------------------------+----------------------------------------- Changes (by simonmar): * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 04:25:40 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 04:15:22 2009 Subject: [GHC] #3008: Strange behavior when using newtyped version of IO monad in FFI import declarations In-Reply-To: <044.36e848c5758ff29e66ba18e678751e7c@localhost> References: <044.36e848c5758ff29e66ba18e678751e7c@localhost> Message-ID: <053.e1bbbe8a7d213966e5695f22d1c9acce@localhost> #3008: Strange behavior when using newtyped version of IO monad in FFI import declarations -------------------------------+-------------------------------------------- Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: FFI | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Excellent report. The real culprit is in the FFI spec: see http://www.haskell.org/pipermail /haskell-prime/2009-February/002726.html. Until that thread is resolved, you can work around this bug by exporting `GL(..)`. Indeed, if my proposal is accepted, you'll be forced to do that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 05:27:54 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 05:17:39 2009 Subject: [GHC] #3001: Biographical profiling segfaults In-Reply-To: <042.14ab8fad2945eacc99233583472e718a@localhost> References: <042.14ab8fad2945eacc99233583472e718a@localhost> Message-ID: <051.9b616e2d8942c57ba9affc2bc412181d@localhost> #3001: Biographical profiling segfaults -------------------------+-------------------------------------------------- Reporter: nad | Owner: igloo Type: bug | Status: reopened Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: fixed => Comment: Nice catch Ian. We should add this as a test, clearly the existing test for bio profiling didn't catch the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 05:35:00 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 05:24:46 2009 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.50f6295f4519c45c79c5344da038312d@localhost> #2615: ghci doesn't play nice with linker scripts ---------------------------------+------------------------------------------ Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high Comment: Seems important to do something about this, but I'm not sure exactly what. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 08:15:33 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 08:05:14 2009 Subject: [GHC] #2972: GHCi broken in GHC 6.10.1 In-Reply-To: <046.36c84703d6f462149fdd781bf29492ec@localhost> References: <046.36c84703d6f462149fdd781bf29492ec@localhost> Message-ID: <055.52c53fd52bd082733544cb5b4eba4afe@localhost> #2972: GHCi broken in GHC 6.10.1 ------------------------+--------------------------------------------------- Reporter: cemeyer | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: powerpc | ------------------------+--------------------------------------------------- Comment (by igloo): Replying to [comment:2 cemeyer]: > Replying to [comment:1 igloo]: > > If you build GHC unregisterised then it should work, though. > > I don't understand. GHC works fine, are you saying this should make GHCi work? Yes; GHCi is just `ghc --interactive`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 08:18:26 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 08:08:12 2009 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.604c153858544656a6b27b13e833ae28@localhost> #2615: ghci doesn't play nice with linker scripts ---------------------------------+------------------------------------------ Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by maeder): Removing "pthread" (and "m") from the `extraLibraries` of the `gtk` package in my `package.conf` solved the problem. (I've left in `"-pthread"` under `ldOptions`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 08:37:18 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 08:27:06 2009 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> References: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> Message-ID: <052.8989199cb2cc82bd9a3d9aa188caf6d9@localhost> #3021: A way to programmatically insert marks into heap profiling output ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: profiling | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: I did once try to add this once by merging our hp2ps with the one that comes with nhc98, and I gave up - the nhc98 one has diverged a long way. Actually I'd rather see hp2ps rewritten in Haskell using one of the new visualisation libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 08:46:51 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 08:37:27 2009 Subject: [GHC] #3012: A little deriving for GADTs In-Reply-To: <044.94324394f531ef37390c0c5f7ffabb55@localhost> References: <044.94324394f531ef37390c0c5f7ffabb55@localhost> Message-ID: <053.241ac93fbbf20261a1bf630170a08e00@localhost> #3012: A little deriving for GADTs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): We're going to typecheck the derived code anyway, right? I don't think it's worth trying to predict in advance whether or not this will succeed, especially as the prediction has the potential to not exactly match what the actual type checker will accept. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 08:56:03 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 08:45:51 2009 Subject: [GHC] #3023: Wrong inferred type shown Message-ID: <044.76801181a244d7308d1c4ba154fcc135@localhost> #3023: Wrong inferred type shown -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- When the warning for missing type signatures is turned on the displayed type is sometimes totally bogus. {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, UndecidableInstances #-} module Bug where class C a b | a -> b, b -> a where f :: a -> b instance C Int Bool where f = undefined instance (C a c, C b d) => C (a -> b) (c -> d) where f = undefined foo :: Int -> Int foo = undefined bar = f foo }}} GHC says: {{{ Warning: Definition but no type signature for `bar' Inferred type: bar :: c -> d }}} The type for bar is, of course, Bool->Bool, and nothing else. -- Lennart -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 09:14:28 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 09:04:16 2009 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> References: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> Message-ID: <052.69d4caf742c9a668b1071511ad9842ef@localhost> #3021: A way to programmatically insert marks into heap profiling output ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: profiling | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by SamB): Replying to [comment:2 simonmar]: > Actually I'd rather see hp2ps rewritten in Haskell using one of the new visualisation libraries. Yeah. I was thinking about making a ticket about that too. I was pretty disgusted when I saw that it was written in C, and none-too-clean C at that. (I was thinking of adding support for rendering in-progress profiles without munging them in shell a few weeks ago.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 09:47:24 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 09:37:13 2009 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> References: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> Message-ID: <052.38af639245e38ac79d1d108680e1d329@localhost> #3021: A way to programmatically insert marks into heap profiling output ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: profiling | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by SamB): Oh, well, anyway, what I had in mind here was a call of type {{{String -> IO ()}}} to place a labeled mark in the profile, basically as shown in that paper. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 09:52:17 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 09:41:59 2009 Subject: [GHC] #3024: Rewrite hp2ps in Haskell Message-ID: <043.5e2ae06063a38e8d4403ee8cfc50d869@localhost> #3024: Rewrite hp2ps in Haskell -----------------------------+---------------------------------------------- Reporter: SamB | Owner: Type: task | Status: new Priority: normal | Component: Profiling Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Right now, hp2ps is written in rather difficult to modify C, and is quite inflexible. We should rewrite it in Haskell and make, among other things, more tolerant to incomplete records. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 09:54:12 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 09:43:58 2009 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> References: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> Message-ID: <052.c116acd1a550a43eadb31daad3cc5711@localhost> #3021: A way to programmatically insert marks into heap profiling output ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: profiling | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by SamB): Okay, I made the ticket for rewriting hp2ps in Haskell: #3024. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 09:55:01 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 09:44:40 2009 Subject: [GHC] #3024: Rewrite hp2ps in Haskell In-Reply-To: <043.5e2ae06063a38e8d4403ee8cfc50d869@localhost> References: <043.5e2ae06063a38e8d4403ee8cfc50d869@localhost> Message-ID: <052.70bdda632da8bac4f040959a5e0ced78@localhost> #3024: Rewrite hp2ps in Haskell ------------------------------+--------------------------------------------- Reporter: SamB | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by SamB): * cc: naesten@gmail.com (added) Comment: This would also help with #3021. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 09:58:40 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 09:48:23 2009 Subject: [GHC] #3019: sparc membar asm instruction requires mode parameter In-Reply-To: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> References: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> Message-ID: <054.e008fe9286bf1b9a1d6dc2a86f65ebb9@localhost> #3019: sparc membar asm instruction requires mode parameter ----------------------------------+----------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rts/testwsdeque.c | Os: Solaris Architecture: sparc | ----------------------------------+----------------------------------------- Comment (by duncan): {{{ hunk ./includes/SMP.h 200 #elif powerpc_HOST_ARCH __asm__ __volatile__ ("msync" : : : "memory"); #elif sparc_HOST_ARCH - /* Sparc in TSO mode does not require write/write barriers. */ - __asm__ __volatile__ ("membar" : : : "memory"); + __asm__ __volatile__ ("membar #StoreLoad" : : : "memory"); #elif !defined(WITHSMP) return; #else }}} With this fix (darcs patch attached) `rts/parallel/WSDeque.c` compiles fine and the test program `rts/testwsdeque.c` appears to work (and runs very quickly on the T2 cpu). Out of interest we would like to see if we omit the membar if that causes the test program to fail in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 09:58:52 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 09:48:35 2009 Subject: [GHC] #3024: Rewrite hp2ps in Haskell In-Reply-To: <043.5e2ae06063a38e8d4403ee8cfc50d869@localhost> References: <043.5e2ae06063a38e8d4403ee8cfc50d869@localhost> Message-ID: <052.5f69334ee741de0568f1ffccdcb6ae5d@localhost> #3024: Rewrite hp2ps in Haskell ------------------------------+--------------------------------------------- Reporter: SamB | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by SamB): * cc: naesten@gmail.com (removed) * cc: SamB (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 10:02:17 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 09:51:57 2009 Subject: [GHC] #3024: Rewrite hp2ps in Haskell In-Reply-To: <043.5e2ae06063a38e8d4403ee8cfc50d869@localhost> References: <043.5e2ae06063a38e8d4403ee8cfc50d869@localhost> Message-ID: <052.0ca6a9d3826d87bf6196926929944b5c@localhost> #3024: Rewrite hp2ps in Haskell ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Old description: > Right now, hp2ps is written in rather difficult to modify C, and is quite > inflexible. We should rewrite it in Haskell and make, among other things, > more tolerant to incomplete records. New description: Right now, hp2ps is written in rather difficult to modify C, and is quite inflexible. We should rewrite it in Haskell and make it, among other things, more tolerant to incomplete records. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 10:36:55 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 10:26:35 2009 Subject: [GHC] #3019: sparc membar asm instruction requires mode parameter In-Reply-To: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> References: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> Message-ID: <054.237f4766e83b5e724691394c5b443c6b@localhost> #3019: sparc membar asm instruction requires mode parameter ----------------------------------+----------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rts/testwsdeque.c | Os: Solaris Architecture: sparc | ----------------------------------+----------------------------------------- Comment (by duncan): If we modify the `rts/parallel/WSDqueue.c` to omit the call to `store_load_barrier()` then running `testwsdeque` (with 3 threads) fails like so: {{{ internal error: internal error: FAIL: 3461204 1 10FAIL: 3460860 2 10 (GHC version 6.11.20090211 for sparc_sun_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug (GHC version 6.11.20090211 for sparc_sun_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort (core dumped) }}} Clearly several threads are hitting internal errors and the messages are getting interleaved in the console output. With just two threads the output is more readable: {{{ internal error: FAIL: 3456932 1 10 (GHC version 6.11.20090211 for sparc_sun_solaris2) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort (core dumped) }}} Note that at least one thread does not die and the test runs on for a second or so until it aborts. So the conclusion would seem to be that the attached patch works and that the store/load memory barrier is necessary on Sparc. As for performance, it is apparently a bit quicker than on x86 which is interesting. For reference, running the `testwsdeque` test prog with a 10x bigger problem size (ie `SCRATCH_SIZE`) on the UltraSPARC T2: * 3 threads: 1.6s * 4 threads: 1.6s * 8 threads: 1.9s * 16 threads: 3.4s * 32 threads: 8.3s * 64 threads: 18.6-19.2s (more variability) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 10:51:20 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 10:41:01 2009 Subject: [GHC] #3019: sparc membar asm instruction requires mode parameter In-Reply-To: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> References: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> Message-ID: <054.2efab742b560963be8b4977e41198e1b@localhost> #3019: sparc membar asm instruction requires mode parameter ----------------------------------+----------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rts/testwsdeque.c | Os: Solaris Architecture: sparc | ----------------------------------+----------------------------------------- Comment (by duncan): Replying to [comment:3 duncan]: > As for performance, it is apparently a bit quicker than on x86 which is interesting. For reference, running the `testwsdeque` test prog with a 10x bigger problem size (ie `SCRATCH_SIZE`) on the UltraSPARC T2: Correction: the above were THREADS=n results. The number of threads actually being used is n+1 because of the main thread which is doing part of the work in the test. So for THREADS=7: * 8 threads: 1.79s (+/- 0.01) On x86-64 Simon reports THREADS=7: * 8 threads: 17.2s So we might hope that work-stealing queues for `par` sparks might be pretty nippy on the T2 cpus. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 11:49:22 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 11:39:06 2009 Subject: [GHC] #2272: internal error: getMBlock: mmap: Bad file number In-Reply-To: <044.485296ba49fdd540ac589cc1c46011fb@localhost> References: <044.485296ba49fdd540ac589cc1c46011fb@localhost> Message-ID: <053.d13f2345ad2ce0979cacac1376ec4db4@localhost> #2272: internal error: getMBlock: mmap: Bad file number -------------------------------+-------------------------------------------- Reporter: hpwei | Owner: benl Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => benl * architecture: Unknown/Multiple => sparc Comment: Ben, could you check whether you can reproduce this one? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 12:08:07 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 11:57:47 2009 Subject: [GHC] #2966: build system does not respect --with-gcc= In-Reply-To: <045.38910ced362f70db06ad52953362394b@localhost> References: <045.38910ced362f70db06ad52953362394b@localhost> Message-ID: <054.63b7da263bab0432e099904c9bcaae64@localhost> #2966: build system does not respect --with-gcc= ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): A helpful workaround in the meantime (ie for 6.10.2) is to add a check that if `--with-gcc=` is given, then it's exactly the same one as the `gcc` on the `$PATH`. Even in this case the `--with-gcc=` is not redundant because it bakes the gcc path into ghc so that it'll use that one once installed, even if the gcc on the path is different at that time. So the gcc on the `$PATH` only has to be the same at build time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 13:41:28 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 13:31:11 2009 Subject: [GHC] #2962: Reduce space usage of genericLength for common Num instances In-Reply-To: <050.56d33139a9874005c965ed3f7cb60dae@localhost> References: <050.56d33139a9874005c965ed3f7cb60dae@localhost> Message-ID: <059.fe868390aab9bdc4675ffdc6dd905be6@localhost> #2962: Reduce space usage of genericLength for common Num instances ---------------------------------+------------------------------------------ Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by thorkilnaur): I attach a patch that adds rules for genericLength::[a]->Int and genericLength::[a]->Integer. Adding rules for Float and Double seems excessive, but it is of course easily done. That the result is as intended is witnessed by: {{{ $ ghc-6.11.20090211 --version The Glorious Glasgow Haskell Compilation System, version 6.11.20090211 $ cat R.hs import List import IO main = do hSetBuffering stdout NoBuffering print $ map ($ [1..4000000]) [ genericLength :: [a] -> Int , fromIntegral . (genericLength :: [a] -> Integer) , round . (genericLength :: [a] -> Double) ] $ ghc-6.11.20090211 -fforce-recomp --make R -O [1 of 1] Compiling Main ( R.hs, R.o ) Linking R ... $ ./R [4000000,4000000,Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. $ }}} Interestingly, this patch only solves the problem for compiled code. I don't know if it is possible to solve it for interpreted code also. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 14:48:49 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 14:38:27 2009 Subject: [GHC] #3025: Possible PiDigits memory explosion regression Message-ID: <045.83a907a9b608fda1ad14968d66d95fe2@localhost> #3025: Possible PiDigits memory explosion regression -----------------------------+---------------------------------------------- Reporter: japple | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This bug is reported from http://axman6.homeip.net/blog/2009/02/shootout- pidigits-program-kinda-sucks-and-possibly-so-does-ghc.html . I will duplicate some content here, since blogs hosted at *.homeip.net seem likely to be down more than the average blog. [http://shootout.alioth.debian.org/u64q/benchmark.php?test=pidigits&lang=ghc&id=1 PiDigits on 6.10] takes over 300mb of memory, but [http://winterkoninkje.livejournal.com/ wren ng thornton] notes that the program only takes 3mb when compiled with 6.8.2. BTW, I'm on linux x86, while the shootout is on x86_64. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 16:07:34 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 15:57:16 2009 Subject: [GHC] #2962: Reduce space usage of genericLength for common Num instances In-Reply-To: <050.56d33139a9874005c965ed3f7cb60dae@localhost> References: <050.56d33139a9874005c965ed3f7cb60dae@localhost> Message-ID: <059.51bbf4eca008afcaf727b9bb0d2c3153@localhost> #2962: Reduce space usage of genericLength for common Num instances --------------------------------------+------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: rules, specialisation | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by dons): * keywords: => rules, specialisation * cc: dons, dcoutts (added) Comment: In general we need rules for left folds on atomic types not being 'foldl'. sum, product, length, maxium, minimum, etc. There are open tickets relating to this already, iirc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 17:55:49 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 17:45:28 2009 Subject: [GHC] #3026: GHCi segfault Message-ID: <045.32dfa38b320a92e3252f23b24d4bdbec@localhost> #3026: GHCi segfault -------------------+-------------------------------------------------------- Reporter: porges | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: major Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- This may be libedit's fault, but I can't tell :) How to replicate: Load up GHCi, hold the up-arrow. Segfault! Here's a backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7e546b0 (LWP 9959)] 0xb808133c in ?? () from /usr/lib/libedit.so.2 (gdb) bt #0 0xb808133c in ?? () from /usr/lib/libedit.so.2 #1 0xb8085e1a in ?? () from /usr/lib/libedit.so.2 #2 0xb8088164 in el_gets () from /usr/lib/libedit.so.2 #3 0xb8095d24 in readline () from /usr/lib/libedit.so.2 #4 0x08aaea00 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 17:56:48 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 17:46:26 2009 Subject: [GHC] #3026: GHCi segfault In-Reply-To: <045.32dfa38b320a92e3252f23b24d4bdbec@localhost> References: <045.32dfa38b320a92e3252f23b24d4bdbec@localhost> Message-ID: <054.e936a4aac411878ac58ca7fe72f9dda1@localhost> #3026: GHCi segfault --------------------+------------------------------------------------------- Reporter: porges | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------+------------------------------------------------------- Comment (by porges): Sorry about formatting: {{{ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7e546b0 (LWP 9959)] 0xb808133c in ?? () from /usr/lib/libedit.so.2 (gdb) bt #0 0xb808133c in ?? () from /usr/lib/libedit.so.2 #1 0xb8085e1a in ?? () from /usr/lib/libedit.so.2 #2 0xb8088164 in el_gets () from /usr/lib/libedit.so.2 #3 0xb8095d24 in readline () from /usr/lib/libedit.so.2 #4 0x08aaea00 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 12 19:19:00 2009 From: trac at galois.com (GHC) Date: Thu Feb 12 19:08:45 2009 Subject: [GHC] #951: stage2 on sparc dies with "schedule: re-entered unsafely" In-Reply-To: <045.a567b71646e7cba6dde8632a9b13b02f@localhost> References: <045.a567b71646e7cba6dde8632a9b13b02f@localhost> Message-ID: <054.6a943453014fa9521563b3c335245830@localhost> #951: stage2 on sparc dies with "schedule: re-entered unsafely" -----------------------------+---------------------------------------------- Reporter: duncan | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: sparc | -----------------------------+---------------------------------------------- Changes (by benl): * status: new => assigned * owner: => benl -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 13 09:03:51 2009 From: trac at galois.com (GHC) Date: Fri Feb 13 08:53:36 2009 Subject: [GHC] #3027: Specialisation rules fail because dictionary projections do not match Message-ID: <068.47a834cf6bc8524dc890365958a3f55d@localhost> #3027: Specialisation rules fail because dictionary projections do not match ------------------------------------------+--------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------------------+--------------------------------- Here is an apparent bug in ghc's specialisation rules. The rewrite rule generated by a SPECIALISE pragma seems to want to pattern-match on exact dictionaries (as well as types). But the compiler is not necessarily able to fully resolve dictionaries before the rules are supposed to fire. First, the source code we want to specialise: {{{ {-# SPECIALISE hedgehog :: Float -> Vector3 Float -> [Cell_8 (Coord3 Float)] -> [Cell_8 (Vector3 Float)] -> [(Coord3 Float, Coord3 Float)] #-} hedgehog :: ( Fractional a, Cell cell vert, Eq vert , Geom coord, Geom vector, Embed vector coord ) => a -> vector a -> [cell (coord a)] -> [cell (vector a)] -> [(coord a, coord a)] }}} The core + interface generated for this module contains the rule: {{{ "SPEC Hedgehog.hedgehog" ALWAYS forall Hedgehog.hedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ RectGrid.MyVertex @ Geometries.Coord3 @ Geometries.Vector3 GHC.Float.$f16 RectGrid.$f2 RectGrid.$f10 Geometries.$f5 Geometries.$f3 Geometries.$f1 }}} But in a different module (Viewer.hs), here is what the usage site looks like just before the specialisation rules are supposed to fire: {{{ hedgehog_aWr = Hedgehog.hedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ RectGrid.MyVertex @ Geometries.Coord3 @ Geometries.Vector3 GHC.Float.$f16 RectGrid.$f2 RectGrid.$f10 (Dataset.$p2Embed @ Geometries.Vector3 @ Geometries.Coord3 Geometries.$f1) (Dataset.$p1Embed @ Geometries.Vector3 @ Geometries.Coord3 Geometries.$f1) Geometries.$f1 }}} Notice how there are a couple of dictionary projection functions still sitting there, so although some of the dictionaries match, not all do, and the rule does not fire. However, later the worker-wrapper transformation is able to resolve those outstanding dictionaries, giving eventually: {{{ hedgehog_r2at = Hedgehog.$whedgehog @ GHC.Float.Float @ RectGrid.Cell_8 @ RectGrid.MyVertex @ Geometries.Coord3 @ Geometries.Vector3 GHC.Float.$f16 RectGrid.$f2 Geometries.$f5 Geometries.$f3 Geometries.$f1 }}} So I'm left calling the worker for the polymorphic version of the function, rather than the specialised monomorphic code I wanted. Given how many dictionaries are involved, and that this is the inner loop of the program, I'm hoping there is a big performance win waiting for me, if only I can get that specialised code to run! A code archive is attached, to help you reproduce the behaviour. I have cut down the code considerably already, but it is still spread over 5 modules: I was unable to cut it down much further without the bug disappearing (probably through inlining or something). Classes are defined in Dataset.hs, instances in Geometries.hs. The code I want to specialise is in Hedgehog.hs, and the usage site is in Viewer.hs (the main program). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 13 13:34:37 2009 From: trac at galois.com (GHC) Date: Fri Feb 13 13:24:19 2009 Subject: [GHC] #3028: what_next error Message-ID: <044.6a7021c20efa74e40884fe46c6d12d9b@localhost> #3028: what_next error --------------------+------------------------------------------------------- Reporter: osuch | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- C:\Documents and Settings\ondrej\Desktop\Prob>del *.o C:\Documents and Settings\ondrej\Desktop\Prob>ghc --make -o par2 Par2.hs par1.hs [1 of 2] Compiling Par1 ( par1.hs, par1.o ) [2 of 2] Compiling Main ( Par2.hs, Par2.o ) Linking par2.exe ... C:\Documents and Settings\ondrej\Desktop\Prob>par2.exe -d 10 -t 2 -r 100000 -s 1 0 [('d',"10"),('r',"100000"),('s',"10"),('t',"2")] about to start generator thread about to start consumer threads done Result for thread 1 is Just 499799.8385894363 par2.exe: internal error: schedule: invalid what_next field (GHC version 6.10.1 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 13 17:43:20 2009 From: trac at galois.com (GHC) Date: Fri Feb 13 17:32:57 2009 Subject: [GHC] #2650: Child processes always unwantedly inherit Handles on Windows In-Reply-To: <047.1449ef20e3242d7624bded23f58b28e1@localhost> References: <047.1449ef20e3242d7624bded23f58b28e1@localhost> Message-ID: <056.1bd7e16b035312d723e68e007df9597f@localhost> #2650: Child processes always unwantedly inherit Handles on Windows ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries (other) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by Deewiant): * component: libraries/process => libraries (other) * architecture: x86 => Unknown/Multiple * summary: System.Process: processes may unwantedly inherit Handles on Windows when multithreading => Child processes always unwantedly inherit Handles on Windows Comment: Okay then, some info and bugfixes follow. Thanks a lot to dcoutts for pointing me in the right direction and helping me along with this. There are actually two issues, only one of which is (poorly) tested by `createprocess-race-condition.hs`: 1. The race condition described in the Microsoft KB article. 2. The fact that all file handles are inheritable by default, meaning that every child process always inherits them. This leads to errors if a child is still alive when the parent wants to e.g. delete a file which was open when the child was born. The second issue is what is tested by the original test case. It only happens sporadically because the file handle is kept open for a very brief interval. The first issue I haven't managed to reproduce, but I don't see a reason why it couldn't happen given the current code in `runProcess.c`. Even if the second issue is fixed it should be possible that the anonymous pipes for a child's stdin/out/err streams are inherited by some other process. I'm attaching: 1. A better test case for issue 2 above. 2. A patch against `base` which disables inheritance of file handles, solving most cases of issue 2. 3. A tentative patch for issue 1 which I haven't tested properly, against `process`: it wraps most of `runInteractiveProcess` in a critical section for atomicity and rewrites the helper function `mkAnonPipe` to work as described in the [http://support.microsoft.com/kb/315939 KB article explaining the race condition issue]. Both patches are against the 6.10 darcs HEAD. According to [http://msdn.microsoft.com/en-us/library/ms724466.aspx MSDN's list of handle types that may be inherited], at least the `network` library still needs to be changed: sockets shouldn't be inherited either. (I don't think any of the other possible handles apply.) If anybody else wants to do that bit, see [http://support.microsoft.com/kb/150523 this KB article] for info on how it should be done. Note that the inheritance disabling should be done atomically, to avoid the race condition described above. I'm pointing this bug at "libraries (other)" since it affects at least all of `base`, `process`, and `network`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 13 18:01:31 2009 From: trac at galois.com (GHC) Date: Fri Feb 13 17:51:07 2009 Subject: [GHC] #2650: Child processes always unwantedly inherit Handles on Windows In-Reply-To: <047.1449ef20e3242d7624bded23f58b28e1@localhost> References: <047.1449ef20e3242d7624bded23f58b28e1@localhost> Message-ID: <056.12b4e822c4db5f59cf90739a397eb20a@localhost> #2650: Child processes always unwantedly inherit Handles on Windows ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries (other) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by Deewiant): I just realized an error in the patch against `process`: a critical section object is now initialized and deleted each time `runInteractiveProcess` is called. This makes it completely useless since each thread gets its own critical section! It should be made into a global, initializing it only once. Deleting it is probably unnecessary since the OS will free it when the process exits, and you can't be sure it won't be reused until that happens anyway. I defer doing this to someone who knows more about how that single initialization can be performed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 14 08:28:26 2009 From: trac at galois.com (GHC) Date: Sat Feb 14 08:18:00 2009 Subject: [GHC] #1891: New RTS "--info" option not in help message In-Reply-To: <044.c4d7d82a3e73e3a3ea77f97a5cdf5109@localhost> References: <044.c4d7d82a3e73e3a3ea77f97a5cdf5109@localhost> Message-ID: <053.270f9b7c7e232d9d7fc156531ab53b73@localhost> #1891: New RTS "--info" option not in help message -------------------------------+-------------------------------------------- Reporter: Orphi | Owner: Orphi Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by Orphi): * owner: => Orphi Comment: Since you've already done the hard part, I'll take a stab at writing the documentation myself and submitting a patch for it. (If I can figure out how... never done this before!) I've managed to find out a lot from the GHC commentary. I have a couple of questions remaining: - Can "GHC RTS" ever be "no"? How? - Does anybody have a list of the possible RTS "ways"? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 14 10:31:10 2009 From: trac at galois.com (GHC) Date: Sat Feb 14 10:20:43 2009 Subject: [GHC] #1891: New RTS "--info" option not in help message In-Reply-To: <044.c4d7d82a3e73e3a3ea77f97a5cdf5109@localhost> References: <044.c4d7d82a3e73e3a3ea77f97a5cdf5109@localhost> Message-ID: <053.7129ffdd07e9e0da706d42d70c5ca9cc@localhost> #1891: New RTS "--info" option not in help message ---------------------------------+------------------------------------------ Reporter: Orphi | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by Orphi): * owner: Orphi => igloo * architecture: x86 => Unknown/Multiple Comment: OK, hopefully I did this right. I've made a patch against the user guide for GHC HEAD. Somebody should probably check that: - My DocBook markup isn't bogus. (I've never heard of DocBook before, but my additions appear to compile to HTML without issue.) - The information I've added is actually correct. (I took a guess at the RTS ways, based on experimental testing and comments in the various makefiles, header files and C bits.) Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 14 14:54:56 2009 From: trac at galois.com (GHC) Date: Sat Feb 14 14:44:29 2009 Subject: [GHC] #2208: many .xml files for the User's Manual force xml-mode in emacs In-Reply-To: <043.dbdf8ae310e46744a6c504b004f1a2cd@localhost> References: <043.dbdf8ae310e46744a6c504b004f1a2cd@localhost> Message-ID: <052.e6daa35468611cc7f757e63ce9cba93c@localhost> #2208: many .xml files for the User's Manual force xml-mode in emacs ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Documentation | Version: 6.9 Severity: normal | Resolution: Keywords: emacs | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by SamB): Replying to [comment:1 igloo]: > If the mode line is removed, will the sgml-parent line still work? Sure -- as long as you have {{{.xml}}} mapped to {{{xml-mode}}} in your {{{auto-mode-alist}}}. (Or just load manually, if you'd prefer.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 15 16:05:53 2009 From: trac at galois.com (GHC) Date: Sun Feb 15 15:55:24 2009 Subject: [GHC] #3029: ghc panic while installing hs-Crypto package (via macport) Message-ID: <047.aa9d2c38601915c3bc099893d3c1ddef@localhost> #3029: ghc panic while installing hs-Crypto package (via macport) ---------------------+------------------------------------------------------ Reporter: mreza101 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: Crypto | Testcase: Os: MacOS X | Architecture: x86 ---------------------+------------------------------------------------------ Here is the bug dump after it failed to build the package. Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports .org_release_ports_devel_hs-Crypto/work/Crypto-4.1.0 && runhaskell Setup build -v" returned error 1 Command output: In the instance declaration for `Integral (LargeKey a b)' Data/LargeWord.hs:137:9: Warning: No explicit method nor default method for `toRational' In the instance declaration for `Real (LargeKey a b)' Data/LargeWord.hs:140:9: Warning: No explicit method nor default method for `toEnum' In the instance declaration for `Enum (LargeKey a b)' Data/LargeWord.hs:140:9: Warning: No explicit method nor default method for `fromEnum' In the instance declaration for `Enum (LargeKey a b)' [10 of 11] Compiling Codec.Encryption.AES ( Codec/Encryption/AES.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Codec/Encryption/AES.o ) [11 of 11] Compiling Main ( SymmetricTest.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Main.o ) Linking dist/build/SymmetricTest/SymmetricTest ... Building executable: SHA1Test... Creating dist/build/SHA1Test (and its parents) Creating dist/build/SHA1Test/SHA1Test-tmp (and its parents) /opt/local/bin/ghc -o dist/build/SHA1Test/SHA1Test --make -hide-all- packages -no-user-package-conf -i -idist/build/SHA1Test/SHA1Test-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/SHA1Test/SHA1Test- tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/SHA1Test/SHA1Test-tmp -hidir dist/build/SHA1Test/SHA1Test-tmp -stubdir dist/build/SHA1Test/SHA1Test-tmp -package HUnit-1.2.0.3 -package QuickCheck-1.2.0.0 -package array-0.2.0.0 -package base-4.0.0.0 -package pretty-1.0.1.0 -package random-1.0.0.1 -O ./SHA1Test.hs [1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test /SHA1Test-tmp/Codec/Utils.o ) [2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o ) [3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o ) [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test /SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Error: Status 1 encountered during processing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 15 18:22:20 2009 From: trac at galois.com (GHC) Date: Sun Feb 15 18:11:49 2009 Subject: [GHC] #3030: GHCI Loading Compiled Modules Under Windows XP Crashes Message-ID: <045.6520dffed9f982658cc7c254dd664b33@localhost> #3030: GHCI Loading Compiled Modules Under Windows XP Crashes --------------------+------------------------------------------------------- Reporter: jburck | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- whenever I load any compiled code under GHCI I get the following when it tries to execute: : panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 15 18:46:06 2009 From: trac at galois.com (GHC) Date: Sun Feb 15 18:35:37 2009 Subject: [GHC] #1377: GHCi debugger tasks In-Reply-To: <047.b3e158073b17fc81d3d320da105cad09@localhost> References: <047.b3e158073b17fc81d3d320da105cad09@localhost> Message-ID: <056.105cebf1ab823772f778807f5c4b89a5@localhost> #1377: GHCi debugger tasks ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by mnislaih): Thanks for the patch Peter, I'll push it as soon as I run validate on it -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 15 18:55:10 2009 From: trac at galois.com (GHC) Date: Sun Feb 15 18:44:40 2009 Subject: [GHC] #2827: Win32 releases lack versioned binaries In-Reply-To: <044.f4f9519bc323ffec43db3e4ff5846813@localhost> References: <044.f4f9519bc323ffec43db3e4ff5846813@localhost> Message-ID: <053.88e0e0942ad34ee4cdca2197a15e0c6d@localhost> #2827: Win32 releases lack versioned binaries ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 16 04:24:24 2009 From: trac at galois.com (GHC) Date: Mon Feb 16 04:13:54 2009 Subject: [GHC] #3019: sparc membar asm instruction requires mode parameter In-Reply-To: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> References: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> Message-ID: <054.6951ed6792586397ba82ddaf9fcf8621@localhost> #3019: sparc membar asm instruction requires mode parameter ----------------------------------+----------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rts/testwsdeque.c | Os: Solaris Architecture: sparc | ----------------------------------+----------------------------------------- Changes (by simonmar): * component: Compiler => Runtime System * milestone: => 6.12 branch Comment: Fixed: {{{ Thu Feb 12 01:23:40 PST 2009 Simon Marlow * update Sparc store/load barrier (#3019), and fix comments }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 16 07:34:44 2009 From: trac at galois.com (GHC) Date: Mon Feb 16 07:24:24 2009 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> References: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> Message-ID: <052.170e089f26f6fc089bb0a250edefa735@localhost> #3021: A way to programmatically insert marks into heap profiling output ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: profiling | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by malcolm.wallace@cs.york.ac.uk): For reference, if you do decide to add this feature, it would be good to use the same interface as nhc98 already has: {{{ profile :: String -> a -> a }}} which is similar to the common side-effecting "trace" function in semantics. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 16 08:05:09 2009 From: trac at galois.com (GHC) Date: Mon Feb 16 07:54:43 2009 Subject: [GHC] #3027: Specialisation rules fail because dictionary projections do not match In-Reply-To: <068.47a834cf6bc8524dc890365958a3f55d@localhost> References: <068.47a834cf6bc8524dc890365958a3f55d@localhost> Message-ID: <077.fc6865ad1b09441871a5c214dbeb7342@localhost> #3027: Specialisation rules fail because dictionary projections do not match -------------------------------------------+-------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------------+-------------------------------- Changes (by malcolm.wallace@cs.york.ac.uk): * status: new => closed * resolution: => fixed Comment: This bug appears to have been fixed between 6.8.2 and 6.10.1. (Although sadly the specialised code in 6.10.1 actually runs slower in some cases than the unspecialised code in 6.8.2.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 16 08:47:59 2009 From: trac at galois.com (GHC) Date: Mon Feb 16 08:37:26 2009 Subject: [GHC] #3031: -fwarn-unrecognised-pragmas is not documented Message-ID: <047.a1fe7ee61556353e5838fab50b24eb4f@localhost> #3031: -fwarn-unrecognised-pragmas is not documented -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Somehow this slipped through the net... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 16 08:50:47 2009 From: trac at galois.com (GHC) Date: Mon Feb 16 08:40:24 2009 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> References: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> Message-ID: <052.07a0bce474a9470e2a8b41c43b8a5aa8@localhost> #3021: A way to programmatically insert marks into heap profiling output ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: profiling | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:6 malcolm.wallace@cs.york.ac.uk]: > {{{ > profile :: String -> a -> a > }}} From which module? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 16 09:11:18 2009 From: trac at galois.com (GHC) Date: Mon Feb 16 09:00:53 2009 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> References: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> Message-ID: <052.7da04861cea8f68ed32c77ccf3c1c940@localhost> #3021: A way to programmatically insert marks into heap profiling output ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: profiling | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by malcolm.wallace@cs.york.ac.uk): Ah, we have it in module NonStdProfile (non-hierarchical, since it predates that extension). But if you have a better idea of where it should live, I'll happily change nhc98 to match. Where does "trace" live? Would System.IO.Unsafe be a good place? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 16 11:26:47 2009 From: trac at galois.com (GHC) Date: Mon Feb 16 11:16:25 2009 Subject: [GHC] #2998: Expose the internals of the network library to make it more extensible In-Reply-To: <044.38e242663cf791489f4226de94cd9e56@localhost> References: <044.38e242663cf791489f4226de94cd9e56@localhost> Message-ID: <053.89361c68996d18c8c7ec53756ee6f1eb@localhost> #2998: Expose the internals of the network library to make it more extensible ----------------------------------+----------------------------------------- Reporter: tibbe | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by tibbe): As there were no objections during the discussion period I will go ahead and implement this proposal. I will try to release a new version of `network` as soon as feasible. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 16 11:57:21 2009 From: trac at galois.com (GHC) Date: Mon Feb 16 11:46:57 2009 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> References: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> Message-ID: <052.a5141774ba40116feee44a1d3a26114b@localhost> #3021: A way to programmatically insert marks into heap profiling output ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 6.10.1 Severity: normal | Resolution: Keywords: profiling | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): `trace` is in `Debug.Trace`. I don't think `System.IO.Unsafe` is right (it's not unsafe or IO-ish). `Profiling.Heap.mark`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 16 14:46:10 2009 From: trac at galois.com (GHC) Date: Mon Feb 16 14:35:37 2009 Subject: [GHC] #3032: would be nice if -fno-code and --make worked together Message-ID: <045.95d90490c3a839988666e452fac25300@localhost> #3032: would be nice if -fno-code and --make worked together -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- We had a Cabal feature request to omit linking to make it quicker in the use case that we just want to check that a package typechecks ok. Omitting liking is good but we could save more time by omitting code generation too. The `-fno-code` would seem to be what we want in this case but it looks like it only works with batch mode and not `--make` mode. What happens at the moment when one uses `-fno-code --make` is that ghc cannot find the dependent modules, though it is not clear that it is actually looking for `.hi` files in any particular location. This is with 6.8.2, I've not checked with 6.10 but I assume it is the same. So if it looks like it would not be too hard to do, then letting `-fno- code` work with `--make` would be occasionally useful. The expected result would be to write out the `.hi` files for all the modules but not the corresponding `.o` files. When combined with `-O0` we might hope it to be a bit quicker than normal builds. Of course it would not work in the case of template Haskell, but Cabal would just avoid using `-fno-code` if the package uses TH. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 17 01:50:46 2009 From: trac at galois.com (GHC) Date: Tue Feb 17 01:40:13 2009 Subject: [GHC] #3033: numerical error introduced by -O1 Message-ID: <045.049e49d5cb5eb4a62c5c7447049b290a@localhost> #3033: numerical error introduced by -O1 -----------------------------+---------------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- {{{ f x = x * 1000000.1 g y True = y g y False = g y True z = let x = 100000000000.0 in f x - g (f x) True main = putStrLn (show z) }}} This program prints "-2.328125" when compiled with "-O1". Running {{{main}}} from within ghci gives "0.0", as it should. Occurs under Mac OS and Linux (both x86). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 17 03:15:47 2009 From: trac at galois.com (GHC) Date: Tue Feb 17 03:05:21 2009 Subject: [GHC] #3001: Biographical profiling segfaults In-Reply-To: <042.14ab8fad2945eacc99233583472e718a@localhost> References: <042.14ab8fad2945eacc99233583472e718a@localhost> Message-ID: <051.40b188a7699fcacb1e72b876aa3d6c59@localhost> #3001: Biographical profiling segfaults -------------------------+-------------------------------------------------- Reporter: nad | Owner: igloo Type: bug | Status: reopened Priority: high | Milestone: 6.10.2 Component: Compiler | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by nad): * version: 6.10.1 => Comment: Biographical profiling still causes segfaults for me, but not on the simple example above. With http://www.haskell.org/ghc/dist/stable/dist/ghc-6.10.1.20090214-src.tar.bz2 and binary-0.4.4 I can trigger a segfault using the following program: {{{ import Data.Binary main = do encodeFile "test.bin" $ replicate 10000 'x' print =<< (decodeFile "test.bin" :: IO String) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 17 04:18:04 2009 From: trac at galois.com (GHC) Date: Tue Feb 17 04:07:31 2009 Subject: [GHC] #3033: numerical error introduced by -O1 In-Reply-To: <045.049e49d5cb5eb4a62c5c7447049b290a@localhost> References: <045.049e49d5cb5eb4a62c5c7447049b290a@localhost> Message-ID: <054.e9e9e2611e8054c3584dc1beb5de6ce7@localhost> #3033: numerical error introduced by -O1 ------------------------------+--------------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by guest): So, interestingly gcc prints non-zero with no optimization and 0 with optimization. The problem is due to the fact the floating point on the 387 compatible FPU stores a double in 64 bits, but internally computes with 80 bits. So the first (f x) is computed and stored, then the second one is computed, and the first one is subtracted. But one of the (f x) calls has 80 bits all the way and the other has been truncated to 64 bits and lost some bits. This is life with the x86, unless you really want to cripple performance and truncate after each FP operation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 17 11:38:08 2009 From: trac at galois.com (GHC) Date: Tue Feb 17 11:27:40 2009 Subject: [GHC] #2697: bad testsuite results with ghc-6.10.0.20081007 In-Reply-To: <045.c368cc178489a6d371c14b6319d3b743@localhost> References: <045.c368cc178489a6d371c14b6319d3b743@localhost> Message-ID: <054.fde73a00c0b6095523783ff7ff8735fb@localhost> #2697: bad testsuite results with ghc-6.10.0.20081007 -------------------------+-------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: high => normal * os: Unknown/Multiple => MacOS X * architecture: Unknown/Multiple => powerpc * milestone: 6.10.2 => _|_ Comment: threaded2 segfaults, panics or times out on some tests. The `ffi009`, `ffi014` and `num012` test failures also look like bugs. The others seem to all be either things like `hpc-inplace` missing, bytestring tests being for a different version of bytestring, etc; or failures of external things, e.g. gcc internal compiler errors. As this isn't one of our [wiki:Platforms tier 1 platforms] we're unlikely to look into the failures in any more detail, but I'll leave this ticket open in milestone `_|_`, so that it is listed if anyone searches for PPC tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 17 13:22:42 2009 From: trac at galois.com (GHC) Date: Tue Feb 17 13:12:21 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.086a88a623861d55058e39db1087c649@localhost> #2917: alloca and allocaArray do not respect alignment -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by igloo): I'm a little nervous about rushing this in, particularly as it changes (adds to) some APIs, and I'm not sure exactly what the behaviour should be. You say {{{ mallocAlignment :: Int mallocAlignment = 16 allocaAlignment :: Int allocaAlignment = 8 }}} but my manpage says {{{ GNU libc malloc() always returns 8-byte aligned memory addresses }}} Where did 16 come from? It also seems strange to me that `allocaAlignment` should be different to `mallocAlignment`. According to my OS X manpages, OS X doesn't have `posix_memalign` or `memalign`, although it does have `valloc` ("The allocated memory is aligned on a page boundary."). However, for all the allocation functions on OS X, "The allocated memory is aligned such that it can be used for any data type, including AltiVec- and SSE-related types.". So if we're told the alignment is 32, and we get memory 16-byte aligned, should we fail? It's not clear to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 17 13:59:14 2009 From: trac at galois.com (GHC) Date: Tue Feb 17 13:48:43 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.fb1e7d587ed9b9eb265ce64a45631637@localhost> #2917: alloca and allocaArray do not respect alignment -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by guest): The mallocAlignment is the alignment returned by C malloc(), the allocaAlignment is the alignment for ghc's heap based allocation. I should have spelled that out. Those two things should not be numbers, of course, but determined by the configure script. yes, OS X malloc() works fine, but ghc's internal allocation fails since it allocates on 8 byte boundary. I don't want to rush this in either. But the bug makes large parts of the FFI library unusable with LLVM, so I'd like some fix. How about a band aid that changes ghc's internal alloca to 16 byte boundary? That will make things work, and we have a chance to test my patch further. -- Lennart -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 04:36:05 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 04:25:26 2009 Subject: [GHC] #3034: divInt# floated into a position which leads to low arity Message-ID: <053.0019c225828c125ef2fe245d50116a1f@localhost> #3034: divInt# floated into a position which leads to low arity -------------------------------------+-------------------------------------- Reporter: batterseapower | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- Tyson Whitehead saw this in the Core output of one of his programs compiled using the MTL StateT: {{{ $wdigit_s1GR [ALWAYS LoopBreaker Nothing] :: GHC.Prim.Int# -> GHC.Types.Int -> Control.Monad.State.Strict.StateT GHC.Types.Int (Control.Monad.Error.ErrorT GHC.Base.String Control.Monad.Identity.Identity) (GHC.Types.Int, GHC.Types.Int) [Arity 1 Str: DmdType L] $wdigit_s1GR = \ (ww_X1H6 :: GHC.Prim.Int#) -> let { lvl_s1H5 [ALWAYS Just D(T)] :: GHC.Types.Int [Str: DmdType] lvl_s1H5 = case GHC.Prim.-# 2147483647 ww_X1H6 of wild2_a1xs [ALWAYS Just L] { __DEFAULT -> case GHC.Base.divInt# wild2_a1xs 10 of wild21_a1xt [ALWAYS Just L] { __DEFAULT -> GHC.Types.I# wild21_a1xt }; (-2147483648) -> lvl_s1Ha } } in (\ (eta_X1nK :: GHC.Types.Int) (eta_s1Dl :: GHC.Types.Int) -> case eta_s1Dl of y_XrP [ALWAYS Just A] { GHC.Types.I# ipv_s19d [ALWAYS Just L] -> case GHC.Prim.<=# ipv_s19d 214748363 of wild_a19h [ALWAYS Dead Just A] { GHC.Bool.False -> case lvl_s1H5 of wild1_X1zB [ALWAYS Just A] { GHC.Types.I# y_X1zG [ALWAYS Just L] -> case GHC.Prim.<=# ipv_s19d y_X1zG of wild_X1z [ALWAYS Dead Just A] { GHC.Bool.False -> a_s1Hk `cast` (right }}} This REALLY SHOULD have arity 3 because that allows: * More worker/wrapper * Less sharing of trivial partial applications elsewhere in his program Here is my reply to him, explaining why it all happens: {{{ Yes - GHC wants to share the work of (maxBound-x)`div`10 between several partial applications of "digit". This is usually a good idea, but in this case it sucks because it's resulted in a massively increased arity. IMHO GHC should fix this by: * Marking divInt# INLINE in the base library. This would result in your code would just containing uses of quotInt# * Making some operations cheap even if they may fail (PrimOp.primpOpIsCheap should change). Though this might mean that we turn non-terminating programs into terminating ones (such operations get pushed inside lambdas) but this is consistent with our treatment of lambdas generally. Actually, your divInt# call wouldn't even usually be floated out to between two lambdas, but at the time FloatOut runs there is something in between the \x lambda and the lambdas from the state monad - the monadic bind operator! So FloatOut feels free to move the computation for "x" up even though that >>= will go away as soon as we run the simplifier. What a disaster! }}} So one of FloatOut and primOpIsCheap probably needs to be fixed. I've attached a program that can reproduce this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 04:36:55 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 04:26:20 2009 Subject: [GHC] #3034: divInt# floated into a position which leads to low arity In-Reply-To: <053.0019c225828c125ef2fe245d50116a1f@localhost> References: <053.0019c225828c125ef2fe245d50116a1f@localhost> Message-ID: <062.a4d654154d90756169cc569c9ee5bc7a@localhost> #3034: divInt# floated into a position which leads to low arity --------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------+------------------------------------- Changes (by batterseapower): * cc: twhitehead@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 07:58:14 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 07:47:36 2009 Subject: [GHC] #3020: process 1.0.1.1 does not compile In-Reply-To: <048.df95f4a6309fe9fe64b69e181e320d2b@localhost> References: <048.df95f4a6309fe9fe64b69e181e320d2b@localhost> Message-ID: <057.f668172f08ff4c10b617e2a21b74debd@localhost> #3020: process 1.0.1.1 does not compile ----------------------------------+----------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/process | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: FreeBSD Architecture: x86_64 (amd64) | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: You need to add `-package process`, or use the `--make` flag. The reason it worked before is that you were lucky: the older version of process was a dependency of the `haskell98` package, which is linked in automatically. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 08:01:33 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 07:50:57 2009 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.3f534f35a6423042e49dc22e8227dbaf@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 | Os: Linux Architecture: powerpc64 | -------------------------------------+-------------------------------------- Comment (by simonmar): Highly relevant message on the autoconf mailing list: [http://www.mail- archive.com/autoconf@gnu.org/msg12932.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 09:11:22 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 09:00:44 2009 Subject: [GHC] #2827: Win32 releases lack versioned binaries In-Reply-To: <044.f4f9519bc323ffec43db3e4ff5846813@localhost> References: <044.f4f9519bc323ffec43db3e4ff5846813@localhost> Message-ID: <053.afa0d9301a80c471af50ecaa62b6e058@localhost> #2827: Win32 releases lack versioned binaries ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10 branch, and I've added a TODO note to the new build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 09:13:29 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 09:03:03 2009 Subject: [GHC] #2897: HsFFI.h is not in the default include path for hsc2hs In-Reply-To: <042.b2d6e868e73bff261558ad2f8fec87f6@localhost> References: <042.b2d6e868e73bff261558ad2f8fec87f6@localhost> Message-ID: <051.425c2b0eff661c03f9b9ee406db8a9e1@localhost> #2897: HsFFI.h is not in the default include path for hsc2hs ---------------------------------+------------------------------------------ Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: hsc2hs | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: high => normal * milestone: 6.10.2 => 6.12 branch Comment: Fixed in HEAD and 6.10.2 by passing a suitable `-I` flag at the end of the commandline: {{{ Tue Feb 17 12:24:07 PST 2009 Ian Lynagh * Add a -I flag with the path to HsFFI.h This can still be overridden by adding a -I flag to the commandline, but it means that hsc2hs will work if no flags are given. }}} But we may want to fix it differently in the future; see http://www.haskell.org/pipermail/glasgow-haskell- users/2009-February/016606.html for more details. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 09:35:33 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 09:24:57 2009 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. In-Reply-To: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> References: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> Message-ID: <051.40099b05f17ee4884964aee595bbff48@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. ------------------------------------------------+--------------------------- Reporter: dsh | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: posix signal threaded IOmanager | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Comment (by simonmar): I intend to fix this by bringing in my new signal-handling code, which moves more of the signal-handling into Haskell. The original plan was to also extend the user API, but we could bring in the low-level machinery without disturbing the API for now. I'd rather do this than spend time fixing bugs in the current implementation, which is rather ugly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 09:57:17 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 09:46:39 2009 Subject: [GHC] #2889: Compilation fails - Can't opne temporary In-Reply-To: <046.8fe469503d4d0471dd07d5bc59e9501a@localhost> References: <046.8fe469503d4d0471dd07d5bc59e9501a@localhost> Message-ID: <055.a90b8956d4b48dc00612dbc07de9ad5e@localhost> #2889: Compilation fails - Can't opne temporary -------------------------+-------------------------------------------------- Reporter: fobrock | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by fobrock): As a result of the issue, which occurred constantly (even with a simple "hello, world" progam), I backed off to using 6.8.2. When I just re-intalled 6.10.1 to capture the "-v" output, the issue did *not* recurr. I tried several uninstalls and re-installs but my test compiles have all been successful. Note that when the issue did occurr in 6.10.1, it was "windres.exe" that reported it. Therefore, I tried compiling with "-fno-gen-manifest" thinking it would avoid calling "windres.exe", but the compilation failed for an unspecified reason (it was requested to report this to GNU). Unless this issue can be reproduced by someone else, I am OK with concluding it must have been something local to my PC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 10:23:42 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 10:13:09 2009 Subject: [GHC] #951: stage2 on sparc dies with "schedule: re-entered unsafely" In-Reply-To: <045.a567b71646e7cba6dde8632a9b13b02f@localhost> References: <045.a567b71646e7cba6dde8632a9b13b02f@localhost> Message-ID: <054.6c6a5a30b4c2ab7125dbc38c7e55f6ac@localhost> #951: stage2 on sparc dies with "schedule: re-entered unsafely" -----------------------------+---------------------------------------------- Reporter: duncan | Owner: benl Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: sparc | -----------------------------+---------------------------------------------- Comment (by duncan): I tried using ghc-6.8.3 and gcc-3.4.3 (the Solaris 10 `/usr/sfw/bin/gcc`). The build went through fine but the stage2/ghc-inplace just hangs when run. GDB reports that we're waiting on something: {{{ (gdb) bt #0 0xff044a30 in __lwp_park () from /lib/libc.so.1 #1 0xff03e968 in cond_sleep_queue () from /lib/libc.so.1 #2 0xff03ea84 in cond_wait_queue () from /lib/libc.so.1 #3 0xff03f004 in cond_wait () from /lib/libc.so.1 #4 0xff03f040 in pthread_cond_wait () from /lib/libc.so.1 #5 0x018ef654 in waitCondition () #6 0x018e52c4 in waitForReturnCapability () #7 0x018e86c4 in rts_lock () #8 0x018e7de0 in real_main () #9 0x018e7f64 in main () }}} Relinking `stage2/ghc-6.8.3` without `-threaded` we get a segfault instead. GDB reports that it occurs in `stg_ap_v_fast`: {{{ (gdb) bt #0 0x019033b4 in stg_ap_v_fast () #1 0x018e9a74 in scheduleWaitThread () #2 0x018e6b6c in real_main () #3 0x018e6cc8 in main () }}} Relinking stage2 with the debug rts seems to make it work ok. At least it does not die on startup. In fact `stage2/ghc-inplace --interactive` also works in that it can eval `1+1`. Anyway, the conclusion does seem to be that this version of gcc does not like the rts. It's interesting that the debug one works. Does it get built with less aggressive gcc optimisations perhaps? For the moment I think I'd just recommend that we make ghc's `./configure` reject `gcc-3.x` on Sparc platforms. We may well also like to warn if people are using `gcc-4.2` as it is known to be very slow. We've not tested 4.3 because the mangler didn't like it last time we tried. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 10:36:48 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 10:26:09 2009 Subject: [GHC] #2889: Compilation fails - Can't opne temporary In-Reply-To: <046.8fe469503d4d0471dd07d5bc59e9501a@localhost> References: <046.8fe469503d4d0471dd07d5bc59e9501a@localhost> Message-ID: <055.f148ff129f50d59b52291860542d9afc@localhost> #2889: Compilation fails - Can't opne temporary -------------------------+-------------------------------------------------- Reporter: fobrock | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: OK; thanks for taking the time to test it again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 12:56:31 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 12:46:02 2009 Subject: [GHC] #2897: HsFFI.h is not in the default include path for hsc2hs In-Reply-To: <042.b2d6e868e73bff261558ad2f8fec87f6@localhost> References: <042.b2d6e868e73bff261558ad2f8fec87f6@localhost> Message-ID: <051.d662306464465b62dabd9a2d2d9141f0@localhost> #2897: HsFFI.h is not in the default include path for hsc2hs ---------------------------------+------------------------------------------ Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: hsc2hs | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): I propose that the next hsc2hs release should have a default template file that does not include `HsFFI.h`. It's not needed by the template itself or any code hsc2hs generates. It's only provided for the convenience of .hsc modules, but they can `#include "HsFFI.h"` themselves if they need it. I expect (but have not checked) that very very few `.hsc` modules actually do need `HsFFI.h` and most of the ones that do are probably in the core libs which are the easiest to fix. A survey of hackage is needed to confirm this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 16:14:49 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 16:04:09 2009 Subject: [GHC] #3034: divInt# floated into a position which leads to low arity In-Reply-To: <053.0019c225828c125ef2fe245d50116a1f@localhost> References: <053.0019c225828c125ef2fe245d50116a1f@localhost> Message-ID: <062.230a0a792205af9ea15435a1b4298d7d@localhost> #3034: divInt# floated into a position which leads to low arity --------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------+------------------------------------- Comment (by twhitehead): For some reason, using quot instead of div produces the desired code. This is despite quotInt# not being cheap according to ghci 6.10.1 Prelude> PrimOp.primOpIsCheap PrimOp.IntQuotOp False Maybe it has something to do with there being a primitive IntQuotOp but not a corresponding IntDivOp (tidy core gives GHC.Prim.quotInt# versus GHC.Base.divInt#) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 19:18:41 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 19:08:02 2009 Subject: [GHC] #3034: divInt# floated into a position which leads to low arity In-Reply-To: <053.0019c225828c125ef2fe245d50116a1f@localhost> References: <053.0019c225828c125ef2fe245d50116a1f@localhost> Message-ID: <062.81984e37ae088dc9628833c04825c1cf@localhost> #3034: divInt# floated into a position which leads to low arity --------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------+------------------------------------- Comment (by twhitehead): I should avoiding the division altogether through quotRem generates really bad code as well where digit :: Int -> Int -> ParseInt Int Int digit !x = do !y <- lift get ( if y < ym || y==ym && x<=xm then lift (put $ y*10+x) >> s2 else throwError "integer overflow" ) where (ym,xm) = maxBound`quotRem`10 Putting separate "ym = maxBound`quot`10" and "xm = maxBound`rem`10" bindings gives good code. Examining the assembler for a seperate routine like demo :: Int -> Int -> Int demo x y = q+r where q = quot x y r = rem x y shows this isn't a really great option in general because the GHC does it through two identical idivs on the x86_64. I am guessing the underlying issue is much the same due to no IntQuotRem prim op. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 20:24:16 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 20:14:07 2009 Subject: [GHC] #3001: Biographical profiling segfaults In-Reply-To: <042.14ab8fad2945eacc99233583472e718a@localhost> References: <042.14ab8fad2945eacc99233583472e718a@localhost> Message-ID: <051.d7f7a4836e70d37b7a2377bded563f29@localhost> #3001: Biographical profiling segfaults ------------------------------+--------------------------------------------- Reporter: nad | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T3001 T3001-2 | Os: Linux Architecture: x86 | ------------------------------+--------------------------------------------- Changes (by igloo): * testcase: => T3001 T3001-2 * status: reopened => closed * resolution: => fixed Comment: Thanks for the follow-up, nad. I've fixed this second problem in HEAD and 6.10-branch: {{{ Wed Feb 18 23:56:20 GMT 2009 Ian Lynagh * Fix an off-by-one; fixes the second bug in trac #3001 }}} and added test cases for them both (T3001, T3001-2). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 18 23:31:01 2009 From: trac at galois.com (GHC) Date: Wed Feb 18 23:20:24 2009 Subject: [GHC] #2360: More information in occurs check message In-Reply-To: <042.d2d1b5c4c3c7a52b18a6186683534f09@localhost> References: <042.d2d1b5c4c3c7a52b18a6186683534f09@localhost> Message-ID: <051.30c086e6d601ea26a5f7700d1021e6fa@localhost> #2360: More information in occurs check message ---------------------------------+------------------------------------------ Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by rwbarton): * cc: rwbarton (added) Comment: Here are some more interesting cases. I'm specifically interested in whether the error message pinpoints the location of the error; I call those error messages good. My tests are under ghc-6.11.20090107. Case 1: A good error message when there's no type signature {{{ Prelude> let m x = x : x in m :1:14: Occurs check: cannot construct the infinite type: a = [a] Expected type: [a] Inferred type: a In the second argument of `(:)', namely `x' In the expression: x : x }}} Case 2: A bad error message when a polymorphic type signature is given {{{ Prelude> let m :: a -> a; m x = x : x in m :1:17: Occurs check: cannot construct the infinite type: a = [a] When generalising the type(s) for `m' In the expression: let m :: a -> a m x = x : x in m In the definition of `it': it = let m :: a -> a m x = x : x in m }}} Case 3: A good error when a monomorphic type signature is given {{{ Prelude> let m :: Int -> Int; m x = x : x in m :1:31: Couldn't match expected type `[Int]' against inferred type `Int' In the second argument of `(:)', namely `x' In the expression: x : x In the definition of `m': m x = x : x }}} The difference between cases 2 and 3 surprises me because I could mechanically turn case 2 into case 3 by substituting a fresh type constructor for each universally quantified type variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 03:31:17 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 03:20:37 2009 Subject: [GHC] #3035: :steplocal and :stepmodule should not polute trace history Message-ID: <046.666e1eb28f46a24ca4e7454edb2b85e1@localhost> #3035: :steplocal and :stepmodule should not polute trace history -----------------------------+---------------------------------------------- Reporter: phercek | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- :steplocal and :stepmodule should not extend trace history with records which represent breakpoints outside the scopes in which :steplocal and :stepmodule are actually stopping. For some discussion related to this see http://www.haskell.org/pipermail/glasgow-haskell- users/2009-February/016576.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 04:01:25 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 03:50:53 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.9770d4be6565bd68eb0df178a5b494e9@localhost> #2917: alloca and allocaArray do not respect alignment -------------------------------+-------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'll do as Lennart suggests and bump the default alignment to 16 bytes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 05:23:23 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 05:12:42 2009 Subject: [GHC] #3036: Max/Min Monoids Message-ID: <048.94c5fac7b8338a7b3c6807ec8bc79bf5@localhost> #3036: Max/Min Monoids -----------------------------+---------------------------------------------- Reporter: whpearson | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- A small patch to Data.Monoid to give Max a and Min a monoids for (Ord a, Bounded a) = > a. Very similar to Sum and Product. Some alternatives here for unbounded Max/Mins http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1528 My current preferred one is to not to bother and perhaps put Data.AddBounds in the main branch and people can wrap Integers in that if they want. It seems conceptually purer. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 05:37:42 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 05:27:00 2009 Subject: [GHC] #3019: sparc membar asm instruction requires mode parameter In-Reply-To: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> References: <045.b75b7e69ee9e9c081ff6ba417e666deb@localhost> Message-ID: <054.4e95721ac3656f7ee75fc708e0ba604f@localhost> #3019: sparc membar asm instruction requires mode parameter ----------------------------------+----------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rts/testwsdeque.c | Os: Solaris Architecture: sparc | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 05:59:55 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 05:49:14 2009 Subject: [GHC] #3036: Max/Min Monoids In-Reply-To: <048.94c5fac7b8338a7b3c6807ec8bc79bf5@localhost> References: <048.94c5fac7b8338a7b3c6807ec8bc79bf5@localhost> Message-ID: <057.34300dfa1a9a79959c5545b49614b824@localhost> #3036: Max/Min Monoids ------------------------------+--------------------------------------------- Reporter: whpearson | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by whpearson): Forgot to export -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 06:12:34 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 06:01:52 2009 Subject: [GHC] #3009: ghci-6.10.1 has odd buffering behavior In-Reply-To: <045.9392d08426c5a478bc5d94d5d63b840d@localhost> References: <045.9392d08426c5a478bc5d94d5d63b840d@localhost> Message-ID: <054.75233d301dcd55abc6920b42f8bc11e1@localhost> #3009: ghci-6.10.1 has odd buffering behavior ---------------------------------+------------------------------------------ Reporter: judahj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * os: MacOS X => Unknown/Multiple * resolution: => wontfix * architecture: x86 => Unknown/Multiple Comment: This is another editline thing, I think. Editline is turning on ICANON and IECHO after it has finished reading the input, even if it was turned off before. I can't see an easy workaround, and we don't want to invest significant effort into fixing editline-related problems since we're moving to haskeline anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 06:15:59 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 06:05:18 2009 Subject: [GHC] #3014: Any type being derived in Haskell 98 module In-Reply-To: <044.9ea2d924c5e505c6225eb8af4944504d@localhost> References: <044.9ea2d924c5e505c6225eb8af4944504d@localhost> Message-ID: <053.91d8369e5dee307057f7a6979f1c3d46@localhost> #3014: Any type being derived in Haskell 98 module ----------------------------------------+----------------------------------- Reporter: fasta | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: wontfix Keywords: any type | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: As we discussed on IRC, this is due to monomorphic pattern bindings; use `-XNoMonoPatBinds` to turn them off. Arguably its an infelicity to see the `Any` type exposed. However I think we're agreed that the right fix is to implement the Haskell' static semantics for pattern bindings, see #2357. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 06:19:09 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 06:08:27 2009 Subject: [GHC] #592: signal handlers should be able to access siginfo_t information In-Reply-To: <047.44a80ef10278cacddbca83ff583da267@localhost> References: <047.44a80ef10278cacddbca83ff583da267@localhost> Message-ID: <056.260806c5a5119953c8834c96fb1bbd96@localhost> #592: signal handlers should be able to access siginfo_t information ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/unix | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Update: the code to provide access to siginfo is now in, we just need to expose the API. {{{ Thu Feb 19 02:05:32 PST 2009 Simon Marlow * Rewrite of signal-handling. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 06:20:00 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 06:09:18 2009 Subject: [GHC] #2451: New signal-handling API In-Reply-To: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> References: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> Message-ID: <056.9e0f4da6e52ca2e15420c082add075e9@localhost> #2451: New signal-handling API ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Update: the internals of the rewrite have now been committed, so far with no API changes. {{{ Thu Feb 19 02:05:32 PST 2009 Simon Marlow * Rewrite of signal-handling. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 06:22:54 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 06:12:13 2009 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. In-Reply-To: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> References: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> Message-ID: <051.7ff68e2c0a1770a5d29a8e1c44f1f318@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. ------------------------------------------------+--------------------------- Reporter: dsh | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: posix signal threaded IOmanager | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: I think these patches should fix the problem, since we no longer have the RTS table of `StablePtrs` to signal handlers. I'd be grateful if you could test the new code and let me know if you still encounter any problems. patch to libraries/unix: {{{ Thu Feb 19 02:05:32 PST 2009 Simon Marlow * Rewrite of signal-handling. Ignore-this: 1579194c10020dc34af715c225a9f207 The API is the same (for now). The new implementation has the capability to define signal handlers that have access to the siginfo of the signal (#592), but this functionality is not exposed in this patch. #2451 is the ticket for the new API. The main purpose of bringing this in now is to fix race conditions in the old signal handling code (#2858). Later we can enable the new API in the HEAD. Implementation differences: - More of the signal-handling is moved into Haskell. We store the table of signal handlers in an MVar, rather than having a table of StablePtrs in the RTS. - In the threaded RTS, the siginfo of the signal is passed down the pipe to the IO manager thread, which manages the business of starting up new signal handler threads. In the non-threaded RTS, the siginfo of caught signals is stored in the RTS, and the scheduler starts new signal handler threads. }}} patch to libraries/base: {{{ Thu Feb 19 02:22:03 PST 2009 Simon Marlow * Rewrite of signal-handling (base patch; see also ghc and unix patches) }}} patch to ghc: {{{ Thu Feb 19 02:31:42 PST 2009 Simon Marlow * Rewrite of signal-handling (ghc patch; see also base and unix patches) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 06:23:16 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 06:12:35 2009 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. In-Reply-To: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> References: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> Message-ID: <051.ab9e97bfdde63f8836ebfa43a82d133f@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. ------------------------------------------------+--------------------------- Reporter: dsh | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: posix signal threaded IOmanager | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by simonmar): * os: Linux => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 06:24:01 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 06:13:30 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.17af9f2f825508199fd19ab6eac1d319@localhost> #2917: alloca and allocaArray do not respect alignment ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * architecture: x86 => Unknown/Multiple Comment: Done: {{{ Thu Feb 19 02:32:45 PST 2009 Simon Marlow * newPinnedByteArray#: align the result to 16-bytes (part of #2917) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 06:44:24 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 06:33:43 2009 Subject: [GHC] #2860: Redundant unblocking in POSIX generic_handler In-Reply-To: <042.2727ad23f19fb18f0134c48d09681776@localhost> References: <042.2727ad23f19fb18f0134c48d09681776@localhost> Message-ID: <051.79398e0b7f80ec7fa6b778cd6c225e64@localhost> #2860: Redundant unblocking in POSIX generic_handler --------------------------------------+------------------------------------- Reporter: dsh | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: trivial | Resolution: fixed Keywords: POSIX generic_handler | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * component: Compiler => Runtime System * os: Linux => Unknown/Multiple * resolution: => fixed * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Done: {{{ Thu Feb 19 02:32:58 PST 2009 Simon Marlow * #2860: remove redundant unblocking of signals }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 08:24:17 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 08:13:37 2009 Subject: [GHC] #2870: User signals are not blocked before 'fork' in runInteractiveProcess In-Reply-To: <042.e53acc7954108a66f75c2330d39f6f71@localhost> References: <042.e53acc7954108a66f75c2330d39f6f71@localhost> Message-ID: <051.13e1a6aa4feec5170fb965ec7aa49eac@localhost> #2870: User signals are not blocked before 'fork' in runInteractiveProcess -----------------------------------------------+---------------------------- Reporter: dsh | Owner: igoo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: libraries/process | Version: 6.10.1 Severity: normal | Resolution: Keywords: threaded runInteractiveProcess | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -----------------------------------------------+---------------------------- Changes (by simonmar): * owner: simonmar => igoo * type: bug => merge Comment: Fixed. Three patches are required, first ghc: {{{ Thu Feb 19 03:34:18 PST 2009 Simon Marlow * Export blockUserSignals and unblockUserSignals (needed for #2870) }}} secondly for libraries/process: {{{ Thu Feb 19 04:32:35 PST 2009 Simon Marlow * Fix #2870: User signals are not blocked before 'fork' in runInteractiveProcess }}} and finally, for libraries/base, this isn't strictly necessary but I think it's prudent: {{{ Thu Feb 19 03:42:17 PST 2009 Simon Marlow * Set the IO manager pipe descriptors to FD_CLOEXEC }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 15:12:05 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 15:01:25 2009 Subject: [GHC] #3037: GHC panics when configuring base Message-ID: <045.45590b53143628c417b0483ef73fb77f@localhost> #3037: GHC panics when configuring base ----------------------------------------------+----------------------------- Reporter: mooism | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: base, base-4.0.0.0, panic, panic! | Testcase: Os: Linux | Architecture: x86 ----------------------------------------------+----------------------------- {{{ $ wget http://hackage.haskell.org/packages/archive/base/4.0.0.0/base-4.0.0.0.tar.gz --2009-02-19 19:54:31-- http://hackage.haskell.org/packages/archive/base/4.0.0.0/base-4.0.0.0.tar.gz Resolving hackage.haskell.org... 69.30.63.197 Connecting to hackage.haskell.org|69.30.63.197|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 409339 (400K) [application/x-tar] Saving to: `base-4.0.0.0.tar.gz' 100%[========================================================================================================>] 409,339 86.7K/s in 5.6s 2009-02-19 19:54:37 (71.8 KB/s) - `base-4.0.0.0.tar.gz' saved [409339/409339] $ tar zxf base-4.0.0.0.tar.gz $ cd base-4.0.0.0 $ runhaskell Setup.hs configure :1:22: attempting to use module `System.IO' (System/IO.hs) which is not loaded :1:22: Not in scope: `System.IO.stderr' :1:22: Not in scope: `System.IO.stdin' ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I am using Ubuntu 8.10 Linux 2.6.27-11-generic i686. I am having trouble using cabal-install, and my real problem may lie there, but I thought I should report this anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 19 18:44:59 2009 From: trac at galois.com (GHC) Date: Thu Feb 19 18:34:17 2009 Subject: [GHC] #3037: GHC panics when configuring base In-Reply-To: <045.45590b53143628c417b0483ef73fb77f@localhost> References: <045.45590b53143628c417b0483ef73fb77f@localhost> Message-ID: <054.f28a82fba936563d7beaf9c2e376aa6b@localhost> #3037: GHC panics when configuring base ----------------------+----------------------------------------------------- Reporter: mooism | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------+----------------------------------------------------- Changes (by duncan): * keywords: base, base-4.0.0.0, panic, panic! => Comment: When cabal-install says a package cannot be installed because it needs base 4, that does not mean you should install base 4. It means you cannot use that version of that package with ghc-6.8. You either have to use an older version of the same package, avoid using the package or upgrade to ghc-6.10 which comes with base 4. For exactly this reason, cabal-install does not decide to install base 4 (which is why you had to go to such lengths to try to install it). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 20 07:54:56 2009 From: trac at galois.com (GHC) Date: Fri Feb 20 07:44:12 2009 Subject: [GHC] #2762: Excessive heap usage In-Reply-To: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> References: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> Message-ID: <053.8675ca446b131450a9e5717dd097a83b@localhost> #2762: Excessive heap usage ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): I think I can work around the cases of this in my real program by pulling the instance methods out into recursive functions, e.g. {{{ instance InputOutput a => InputOutput [a] where input = inputList inputList :: InputOutput a => String -> ([a], String) inputList ('0':bs) = ([], bs) inputList ('1':bs) = case input bs of (x, bs') -> case inputList bs' of ~(xs, bs'') -> (x : xs, bs'') }}} In some cases it gets a little uglier, but still tolerable, e.g. with: {{{ data Seq p from to where Cons :: p from mid -> Seq p mid to -> Seq p from to Nil :: Seq p here here }}} I need to hide the `from` and `to` arguments to stop it leaking space: {{{ data Hide2 t where Hide2 :: t a b -> Hide2 t hide2 :: t a b -> Hide2 t hide2 x = Hide2 x unhide2 :: Hide2 t -> t a b unhide2 (Hide2 x) = unsafeCoerce x inputSeq :: InputOutput2 p => ByteString -> (Hide2 (Seq p), ByteString) inputSeq bs = case BS.head bs of 0 -> (hide2 Nil, BS.tail bs) 1 -> case input2 (BS.tail bs) of (x, bs') -> case inputSeq bs' of ~(xs, bs'') -> (hide2 (x `Cons` unhide2 xs), bs'') _ -> error "InputOutput Seq: Bad value" }}} So I'd still like this to be fixed, as it would be one less thing to worry about when writing code, but I don't think it's actually blocking me currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 20 11:55:35 2009 From: trac at galois.com (GHC) Date: Fri Feb 20 11:45:26 2009 Subject: [GHC] #2812: For ghci, drop editline in favour of haskeline In-Reply-To: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> References: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> Message-ID: <053.be916097dae3c2673322dff077c86fc2@localhost> #2812: For ghci, drop editline in favour of haskeline ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ingmar): * cc: ingmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 20 12:02:22 2009 From: trac at galois.com (GHC) Date: Fri Feb 20 11:52:17 2009 Subject: [GHC] #3004: Makefile needs to improve treatment of HsColour In-Reply-To: <041.599d5d545611d75bbe675a894a5ae12b@localhost> References: <041.599d5d545611d75bbe675a894a5ae12b@localhost> Message-ID: <050.d7084df138308f43e3f3e40fd31f9347@localhost> #3004: Makefile needs to improve treatment of HsColour ------------------------------+--------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by ingmar): * cc: ingmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 20 12:47:48 2009 From: trac at galois.com (GHC) Date: Fri Feb 20 12:37:04 2009 Subject: [GHC] #3038: Associated type use triggers a bogus error message Message-ID: <044.c075c321a58408fdedadf06d2e00122e@localhost> #3038: Associated type use triggers a bogus error message ------------------------------------+--------------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: associated type synonym | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------------+--------------------------------------- In GHCi, version 6.11.20090115 built from HEAD {{{ {-# LANGUAGE TypeOperators, TypeFamilies #-} {-# OPTIONS_GHC -Wall #-} -- With associate type synonym, the ch' definition leads to -- -- Couldn't match expected type `Basis u1' -- against inferred type `Basis u' -- Expected type: u1 :-* v -- Inferred type: u :-* v -- In the expression: ch -- In the definition of `ch'': ch' = ch -- -- With associated data type, no problem. class HasBasis u where type Basis u :: * -- class HasBasis u where data Basis u :: * type u :-* v = Basis u -> v ch :: (HasBasis u, HasBasis v) => (v :-* w) -> (u :-* v) -> (u :-* w) ch = undefined ch' :: (HasBasis u, HasBasis v) => (v :-* w) -> (u :-* v) -> (u :-* w) ch' = ch }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 20 18:29:27 2009 From: trac at galois.com (GHC) Date: Fri Feb 20 18:18:39 2009 Subject: [GHC] #3039: strange space usage Message-ID: <044.6222a2241621a8a36e8604831e185979@localhost> #3039: strange space usage ---------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ This program: {{{ module Main (main) where import System.IO.Unsafe main :: IO () main = do writeFile "wibbleflibble" (replicate 100 'z') bs <- getCs $ g $ replicate 1000000 "flibble" print $ last bs getCs :: [FilePath] -> IO String getCs [] = return "" getCs (c : cs) = do x <- readFile c xs <- unsafeInterleaveIO $ getCs cs return (x ++ xs) g :: [FilePath] -> [FilePath] g is = map f is f :: FilePath -> FilePath f fn = "wibble" ++ fn }}} when run: {{{ $ ghc -fforce-recomp -Wall --make -O2 -prof -auto-all z.hs -o z $ ./z +RTS -h -p }}} shows that around 100k is used by `f` (`h.png`). Running with {{{ $ ./z +RTS -hcf -hy -p }}} shows that it is all of type `[]` (`hcf_hy.png`). That seems like a large amount of space for a 13 character filename, so it smells to me like something is wrong somewhere. If we inline `g`: {{{ module Main (main) where import System.IO.Unsafe main :: IO () main = do writeFile "wibbleflibble" (replicate 100 'z') bs <- getCs $ map f $ replicate 1000000 "flibble" print $ last bs getCs :: [FilePath] -> IO String getCs [] = return "" getCs (c : cs) = do x <- readFile c xs <- unsafeInterleaveIO $ getCs cs return (x ++ xs) f :: FilePath -> FilePath f fn = "wibble" ++ fn }}} then it all disappears (`h2.png`). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 20 19:57:59 2009 From: trac at galois.com (GHC) Date: Fri Feb 20 19:47:12 2009 Subject: [GHC] #3039: strange space usage In-Reply-To: <044.6222a2241621a8a36e8604831e185979@localhost> References: <044.6222a2241621a8a36e8604831e185979@localhost> Message-ID: <053.a198d497e44f26f357e57e4854262ab5@localhost> #3039: strange space usage -----------------------------------------+---------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by igloo): A biography profile shows that all the `f` usage is `VOID`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 21 01:29:29 2009 From: trac at galois.com (GHC) Date: Sat Feb 21 01:18:47 2009 Subject: [GHC] #3038: Associated type use triggers a bogus error message In-Reply-To: <044.c075c321a58408fdedadf06d2e00122e@localhost> References: <044.c075c321a58408fdedadf06d2e00122e@localhost> Message-ID: <053.80ebd44236594afd61e650adb0db9250@localhost> #3038: Associated type use triggers a bogus error message -------------------------------------+-------------------------------------- Reporter: conal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: duplicate Keywords: associated type synonym | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => duplicate Comment: The signature of `ch' is ambiguous. See #1897 for similar examples and a long discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 21 09:08:34 2009 From: trac at galois.com (GHC) Date: Sat Feb 21 08:57:47 2009 Subject: [GHC] #2451: New signal-handling API In-Reply-To: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> References: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> Message-ID: <056.78e5f7b102e405e2d48508de85b85855@localhost> #2451: New signal-handling API ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by golubovsky): The change of Feb 19 (namely in System.Posix.Process.Internals) does not work with Hugs as GHC.Conc is not known to Hugs. As a result, the whole Unix package is skipped while building. Please consider this in future updates. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 21 15:18:25 2009 From: trac at galois.com (GHC) Date: Sat Feb 21 15:07:47 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.c439d660f2d4cb4590a4e0737ba9ea6c@localhost> #2917: alloca and allocaArray do not respect alignment ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * type: merge => bug Comment: That patch was buggy (segfaults on 32-bit platforms, amongst other problems), so I've rolled it back. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 21 15:28:54 2009 From: trac at galois.com (GHC) Date: Sat Feb 21 15:18:07 2009 Subject: [GHC] #3040: make clean fails (in utils/hsc2hs?) on 6.10 Message-ID: <041.44349b023a81934d09f5b52fb3674ea2@localhost> #3040: make clean fails (in utils/hsc2hs?) on 6.10 -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- {{{make clean}}} halts with an error message. Here's the tail of the output: {{{ make -C hpc clean /home/nr/net/ghc/2009-feb-dias/libraries/cabal-bin /usr/bin/ghc /home/nr/net/ghc/2009-feb-dias/libraries/bootstrapping.conf 1.7.0 clean --distpref dist-inplace cleaning... /home/nr/net/ghc/2009-feb-dias/libraries/cabal-bin /usr/bin/ghc /home/nr/net/ghc/2009-feb-dias/libraries/bootstrapping.conf 1.7.0 clean --distpref dist-install cleaning... rm -f -rf install-inplace make -C hsc2hs clean make[2]: *** No rule to make target `clean'. Stop. make[1]: *** [clean.hsc2hs] Error 2 Failed making clean in utils: 1 make: *** [clean] Error 1 : nr@homedog 2958 }}} I ran {{{darcs-all get}}} but this left me with an empty utils/hsc2hs directory, which turned out to be the cause of the problem. Removing the empty directory and re-running {{{darcs-all get}}} solved the problem. Not sure if this one is likely to recur, but I thought you should know about it. Perhaps ./configure ought to fail if a directory that should be nonempty is found to be empty? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 21 15:33:44 2009 From: trac at galois.com (GHC) Date: Sat Feb 21 15:22:59 2009 Subject: [GHC] #3040: make clean fails (in utils/hsc2hs?) on 6.10 In-Reply-To: <041.44349b023a81934d09f5b52fb3674ea2@localhost> References: <041.44349b023a81934d09f5b52fb3674ea2@localhost> Message-ID: <050.3b3185463ff933cd06591635a8b57af5@localhost> #3040: make clean fails (in utils/hsc2hs?) on 6.10 ------------------------------+--------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by nr): * version: 6.10.1 => 6.11 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 21 16:27:09 2009 From: trac at galois.com (GHC) Date: Sat Feb 21 16:16:21 2009 Subject: [GHC] #2870: User signals are not blocked before 'fork' in runInteractiveProcess In-Reply-To: <042.e53acc7954108a66f75c2330d39f6f71@localhost> References: <042.e53acc7954108a66f75c2330d39f6f71@localhost> Message-ID: <051.509c37c423e59fbe1ccde2e831ad807d@localhost> #2870: User signals are not blocked before 'fork' in runInteractiveProcess -----------------------------------------------+---------------------------- Reporter: dsh | Owner: igoo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: libraries/process | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: threaded runInteractiveProcess | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -----------------------------------------------+---------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: All 3 merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 21 16:28:12 2009 From: trac at galois.com (GHC) Date: Sat Feb 21 16:17:22 2009 Subject: [GHC] #3017: Type inference is broken when dealing with tuple type synonyms In-Reply-To: <051.63df5f501a493ca23dd437a940fffbef@localhost> References: <051.63df5f501a493ca23dd437a940fffbef@localhost> Message-ID: <060.b20e42dcd386ac68b46f0a0ce4f2421c@localhost> #3017: Type inference is broken when dealing with tuple type synonyms ---------------------------------------------------+------------------------ Reporter: straka.milan | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: indexed-types/should_compile/T3017 | Os: Linux Architecture: x86 | ---------------------------------------------------+------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Didn't go smoothly, so not merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 21 16:29:09 2009 From: trac at galois.com (GHC) Date: Sat Feb 21 16:18:22 2009 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. In-Reply-To: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> References: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> Message-ID: <051.34577aa0a3db0ca173a165c5eb4dc9c0@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. ------------------------------------------------+--------------------------- Reporter: dsh | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: posix signal threaded IOmanager | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: All 3 merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 21 16:59:44 2009 From: trac at galois.com (GHC) Date: Sat Feb 21 16:48:59 2009 Subject: [GHC] #3041: Arch independent binary representations Message-ID: <046.ec9add4015adc692796a9426b46aeec0@localhost> #3041: Arch independent binary representations ----------------------------+----------------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------------+----------------------------------------------- Hi, when packaging ghc6.10 for Debian, we stumbled over a rather large annoyance: Haddock?s .haddock files are not architecture independent any more. It uses Binary instances to serialize it?s data, and for Int, the size depends on the architecture it is running. As otherwise the .haddock files should not be arch independent, it would make life for the ghc6 maintainer easier if this can be changed. I started to fix haddock there, but it uses the Binary instance for some of ghc6 internal structures (Name at least, maybe more), which also serialize Int?s without specifying the size. Would it be accepted to change the Binary instances for (at least) these data types to convert all Int?s to Int32?s or Int64?s before serialization? What would be broken by such a change? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 21 17:28:16 2009 From: trac at galois.com (GHC) Date: Sat Feb 21 17:17:27 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.85432e69a78ef563476328f706480cb9@localhost> #3041: Arch independent binary representations -----------------------------+---------------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Comment (by nomeata): I think it affects (at least): * Int, as the basic culprit. Change the Binary instance of Int, fixes all the following cases. * FastString, for the length variable * PackageId, ModuleName, as they are FastString newtypes (so either the FastString instance has to be changed, or copied and ?arch-independized? for PackageId, ModuleName * OccName, builds on NameSpace and FastString -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 21 21:00:49 2009 From: trac at galois.com (GHC) Date: Sat Feb 21 20:50:11 2009 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> Message-ID: <053.1e8973341b18a2abc9758b87caf2fbdd@localhost> #2578: "ld: atom sorting error for ..." on OS X ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * os: Unknown/Multiple => MacOS X -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 22 04:22:39 2009 From: trac at galois.com (GHC) Date: Sun Feb 22 04:12:36 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.187ae9ed22e0cc1d4b800fe5efbecdb0@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: clemens Type: task | Status: assigned Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 22 05:55:23 2009 From: trac at galois.com (GHC) Date: Sun Feb 22 05:44:35 2009 Subject: [GHC] #3035: :steplocal and :stepmodule should not polute trace history In-Reply-To: <046.666e1eb28f46a24ca4e7454edb2b85e1@localhost> References: <046.666e1eb28f46a24ca4e7454edb2b85e1@localhost> Message-ID: <055.eea12784ec6fac84407a9624dae37af3@localhost> #3035: :steplocal and :stepmodule should not polute trace history ------------------------------+--------------------------------------------- Reporter: phercek | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by mnislaih): * status: new => assigned * owner: => mnislaih * cc: phercek@gmail.com, mnislaih@gmail.com (added) Comment: Peter, this patch is against HEAD, right ? It looks like cannot apply it because of a darcs bug. *Sigh* After trying both with darcs1 and darcs2 on a clean ghc, I give up. Would you mind to attach a manual patch instead? Thanks. {{{ pepe@ender4:~/scratch/ghc.head$ darcs1 apply ../ghc.phercek/traceOnlyStops.dpatch darcs1: bug in get_extra commuting patch: Sat Sep 20 17:57:22 CEST 2008 Ian Lynagh * Add library release notes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 22 07:54:09 2009 From: trac at galois.com (GHC) Date: Sun Feb 22 07:44:06 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.d1098242d4caf59ae7c4a720c43543d2@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: clemens Type: task | Status: assigned Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: Bulat.Ziganshin@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 22 11:55:22 2009 From: trac at galois.com (GHC) Date: Sun Feb 22 11:44:30 2009 Subject: [GHC] #3042: rts defines "real_main" which can clash with user C code Message-ID: <045.2ba5f7fc867f0e9727cddd2b5dbaa661@localhost> #3042: rts defines "real_main" which can clash with user C code -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I was just about to file a bug about `ghc -no-hs-main` not working but it turns out it is just because I had a `real_main` C function in my `.c` file. This ends up clashing with the C function of the same name from the rts package. This means that when linking we pull in the wrong one and the rts one needs `__stginit_ZCMain` and `ZCMain_main_closure` which is what the linker error message reports (which is rather confusing). Suggestion: rename the rts `real_main` to something less likely to clash with user code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 22 12:11:07 2009 From: trac at galois.com (GHC) Date: Sun Feb 22 12:00:14 2009 Subject: [GHC] #3042: rts defines "real_main" which can clash with user C code In-Reply-To: <045.2ba5f7fc867f0e9727cddd2b5dbaa661@localhost> References: <045.2ba5f7fc867f0e9727cddd2b5dbaa661@localhost> Message-ID: <054.86f34efcf52f830792cd999845ad4528@localhost> #3042: rts defines "real_main" which can clash with user C code ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by duncan): see also http://hackage.haskell.org/trac/hackage/ticket/504 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 22 14:55:24 2009 From: trac at galois.com (GHC) Date: Sun Feb 22 14:44:33 2009 Subject: [GHC] #3043: An unrelated definition monomorphizes a type even without the MR Message-ID: <047.eb7eedba17aec30268266c1c9884edd3@localhost> #3043: An unrelated definition monomorphizes a type even without the MR -----------------------------+---------------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following code: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, FunctionalDependencies #-} class Id a b | b -> a where id' :: a -> b instance Id [Char] [Char] where id' = id class Fst a where fst' :: a -> String instance Fst ([Char],a) where fst' = fst data Void a = Void void :: (String,a) -> Void a void _ = Void fst'' (a,b) = let x = (id' a, b) y = void x :: Void Int -- remove this line and the code compiles in fst' x }}} Results in: {{{ arst.hs:18:6: No instance for (Fst (b, Int)) arising from a use of `fst'' at arst.hs:18:6-11 Possible fix: add an instance declaration for (Fst (b, Int)) In the expression: fst' x In the expression: let x = (id' a, b) y = void x :: Void Int in fst' x In the definition of `fst''': fst'' (a, b) = let x = ... y = ... in fst' x arst.hs:18:11: No instance for (Id [Char] b) arising from a use of `x' at arst.hs:18:11 Possible fix: add an instance declaration for (Id [Char] b) In the first argument of `fst'', namely `x' In the expression: fst' x In the expression: let x = (id' a, b) y = void x :: Void Int in fst' x }}} It seems that the definition of `y` locks down the type of `x` somewhat even though the monomorphism restriction is disabled. If we remove the definition: {{{ *Main> :t fst'' fst'' :: (Id t b, Fst (b, t1)) => (t, t1) -> String }}} To be completely honest I'm not sure whether the code should be accepted or not, since `(Id t b, Fst (b, t1))` can't be satisfied. Only the fully monomorphic signature `([Char], Int) -> String`, which is obtained with the definition of `y` in place and the monomorphism restriction enabled, works. In any case, I think it's a bug that the results of the type check depend on whether `y` is defined or not: surely that shouldn't matter at all, no matter what the end result is. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 22 15:18:32 2009 From: trac at galois.com (GHC) Date: Sun Feb 22 15:07:43 2009 Subject: [GHC] #3035: :steplocal and :stepmodule should not polute trace history In-Reply-To: <046.666e1eb28f46a24ca4e7454edb2b85e1@localhost> References: <046.666e1eb28f46a24ca4e7454edb2b85e1@localhost> Message-ID: <055.5d1aa49eee326ecfab0e8e67affe5634@localhost> #3035: :steplocal and :stepmodule should not polute trace history ------------------------------+--------------------------------------------- Reporter: phercek | Owner: Igloo Type: merge | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by mnislaih): * status: assigned => new * owner: mnislaih => Igloo * type: bug => merge Comment: Validated and pushed {{{ Sun Feb 22 21:10:02 CET 2009 Peter Hercek * :steplocal and :stepmodule should not polute trace history }}} This patch can be merged to ghc-6.10 if the API change in {{{GhciMonad.resume}}} is not too bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 22 15:18:46 2009 From: trac at galois.com (GHC) Date: Sun Feb 22 15:07:56 2009 Subject: [GHC] #3035: :steplocal and :stepmodule should not polute trace history In-Reply-To: <046.666e1eb28f46a24ca4e7454edb2b85e1@localhost> References: <046.666e1eb28f46a24ca4e7454edb2b85e1@localhost> Message-ID: <055.aa5a5d2cec5038ae9db2d32157c63ac2@localhost> #3035: :steplocal and :stepmodule should not polute trace history ------------------------------+--------------------------------------------- Reporter: phercek | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by mnislaih): * owner: Igloo => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 22 15:21:33 2009 From: trac at galois.com (GHC) Date: Sun Feb 22 15:10:43 2009 Subject: [GHC] #1377: GHCi debugger tasks In-Reply-To: <047.b3e158073b17fc81d3d320da105cad09@localhost> References: <047.b3e158073b17fc81d3d320da105cad09@localhost> Message-ID: <056.67bb6a89300f41df86521552a0d09b20@localhost> #1377: GHCi debugger tasks ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by mnislaih): * owner: => igloo Comment: Validated and pushed {{{ Sun Feb 22 20:55:51 CET 2009 Peter Hercek * Do not print anything to stdout when stopping at a breakpoint with custom code attached }}} Ian, this patch can be merged to 6.10, but do not close the ticket yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 22 16:01:59 2009 From: trac at galois.com (GHC) Date: Sun Feb 22 15:51:07 2009 Subject: [GHC] #3031: -fwarn-unrecognised-pragmas is not documented In-Reply-To: <047.a1fe7ee61556353e5838fab50b24eb4f@localhost> References: <047.a1fe7ee61556353e5838fab50b24eb4f@localhost> Message-ID: <056.0893ebeb721b34cd1ab6c5780b553549@localhost> #3031: -fwarn-unrecognised-pragmas is not documented ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 23 04:41:22 2009 From: trac at galois.com (GHC) Date: Mon Feb 23 04:30:39 2009 Subject: [GHC] #1897: Ambiguous types and rejected type signatures In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.44714e6480a5799d369f24ed2b64eec0@localhost> #1897: Ambiguous types and rejected type signatures ----------------------------------------+----------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Comment (by simonpj): See also #3038 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 23 07:03:59 2009 From: trac at galois.com (GHC) Date: Mon Feb 23 06:53:10 2009 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> Message-ID: <053.e7b4b93b1890228f71b77d0c57fce8c1@localhost> #2578: "ld: atom sorting error for ..." on OS X ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): You can avoid the warnings by passing the -w flag to the linker, i.e., -optl -w. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 23 08:18:24 2009 From: trac at galois.com (GHC) Date: Mon Feb 23 08:08:14 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.0b1cb6c474fb7af92516bff304e6b788@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: clemens Type: task | Status: assigned Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by clemens): We need a buildbot for regression testing. I asked a few times on #ghc without much response. Probably I wasn't persistant enough to chase after those responsible. I haven't look at most recent HEAD but frankly, I would be surprised if --enable-shared still works out of the box, where I left it a few months ago. Also I would be surpised if the number of failing test cases given above would have remained constant. Honestly, there is more exciting stuff around than hacking on shared libs. If someone wants to take the job, this one should feel free to reassign the bug to himself. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 23 08:50:31 2009 From: trac at galois.com (GHC) Date: Mon Feb 23 08:39:44 2009 Subject: [GHC] #3027: Specialisation rules fail because dictionary projections do not match In-Reply-To: <068.47a834cf6bc8524dc890365958a3f55d@localhost> References: <068.47a834cf6bc8524dc890365958a3f55d@localhost> Message-ID: <077.6d0bb7fbbe30151fa01e62e0c35b787f@localhost> #3027: Specialisation rules fail because dictionary projections do not match ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: I hate hearing that 6.10.1 goes slower than 6.8.2. If you can get any insight into '''why''', that'd be really great. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 23 09:41:31 2009 From: trac at galois.com (GHC) Date: Mon Feb 23 09:31:23 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.715ce7fc028ad853642e61c90d13f710@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: clemens Type: task | Status: assigned Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): We'll make it possible to build it in parallel with the non-shared GHC in the new build system, and then we won't need a dedicated buildbot for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 23 09:57:53 2009 From: trac at galois.com (GHC) Date: Mon Feb 23 09:47:06 2009 Subject: [GHC] #3027: Specialisation rules fail because dictionary projections do not match In-Reply-To: <068.47a834cf6bc8524dc890365958a3f55d@localhost> References: <068.47a834cf6bc8524dc890365958a3f55d@localhost> Message-ID: <077.19c39402cee39312ac619414408a5880@localhost> #3027: Specialisation rules fail because dictionary projections do not match ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): Unfortunately performance tuning remains something of a black art for me. Here are timing figures for the real code in question, with attempted (but failed) specialisation in 6.8.2, and actual specialisation in 6.10.1: ghc-6.8.2: 11.88s ghc-6.10.1: 14.75s Later, having profiled this same code, and hit two hotspots with a small algorithmic improvement, and some INLINE pragmas, I now get the following comparison: ghc-6.8.2: 2.71s ghc-6.10.1: 2.92s Big improvement overall, which I'm very happy with, but 6.8.2 still wins. Make a tiny change to the outer loop of this version, basically to remove a filter and thus do more work: ghc-6.8.2: 16.18s ghc-6.10.1: 11.55s and suddenly 6.10.1 overtakes 6.8.2. So the newer ghc oscillates between 25% faster, and 25% slower, on very slight variations of the same program. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 23 10:03:40 2009 From: trac at galois.com (GHC) Date: Mon Feb 23 09:52:52 2009 Subject: [GHC] #3027: Specialisation rules fail because dictionary projections do not match In-Reply-To: <068.47a834cf6bc8524dc890365958a3f55d@localhost> References: <068.47a834cf6bc8524dc890365958a3f55d@localhost> Message-ID: <077.78b5648827f7bd94b3e91b743e8c5193@localhost> #3027: Specialisation rules fail because dictionary projections do not match ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Comment (by simonpj): OK. Could you dump a reproducible version of this into the ticket? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 23 12:57:18 2009 From: trac at galois.com (GHC) Date: Mon Feb 23 12:46:23 2009 Subject: [GHC] #3043: An unrelated definition monomorphizes a type even without the MR In-Reply-To: <047.eb7eedba17aec30268266c1c9884edd3@localhost> References: <047.eb7eedba17aec30268266c1c9884edd3@localhost> Message-ID: <056.0db405b70a48e8929624f269b168c163@localhost> #3043: An unrelated definition monomorphizes a type even without the MR ----------------------------------------+----------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Your final remark isn't right in general. Consider: {{{ f x = let y = x::Int in x && True }}} This is rejected, because `x` can't be both an `Int` and a `Bool`. But it'd be accepted if the binding for `y` was dropped. The type checker takes no notice of whether `y` is mentioned or not. (You might want it to, but I don't think it matters one way or the other in practice.) In your example, since `a` and `b` are both mentioned in the right hand side of `x`, the type of `x` can't be generalised. Suppose `a :: ta` and `b :: tb`. Then the inferred type for `x` will be something like {{{ x :: forall c. Id ta c => (c, tb) }}} Now the type sig in `y` instantiates `c` to `String`, forces `tb=Int`, and generates a constraint `(Id ta String)`. Now the fundep on `Id` forces `ta=String`. That's as far as I have time to go today. I don't think this has anything to do with the MR. Reopen if you disagree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 23 17:53:07 2009 From: trac at galois.com (GHC) Date: Mon Feb 23 17:42:20 2009 Subject: [GHC] #2739: GHC API crashes on template haskell splices In-Reply-To: <044.3bac7d34665c04ceca674c8a12436d56@localhost> References: <044.3bac7d34665c04ceca674c8a12436d56@localhost> Message-ID: <053.32d3de4a1cf860a4ac378ce69ec79b63@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: nominolo Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by waern): Hi, I'd just like to point out that it's pretty important that we try to back- port the above patch to GHC 6.10.2 since Haddock will continue to be broken on packages that uses TH otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 04:10:33 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 04:00:25 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.f3defdd28d26a4bb073e80baec99f782@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: clemens Type: task | Status: assigned Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): To my mind this is stalled not just due to lack of effort, but there's some design work to be done - mainly around how distributions, and how Cabal and cabal-install will work with shared libraries. See my list of questions above ([http://hackage.haskell.org/trac/ghc/ticket/1876#comment:11]) for a start. The other thing that worries me is that without having support for fixed ABIs, we could have more problems with shared libraries, since when someone reinstalls a library they will break not only dependent packages, but also existing dynamically-linked binaries. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 07:21:18 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 07:10:21 2009 Subject: [GHC] #3044: NoImplicitPrelude being ignored by 6.10.1, works in 6.8.2 Message-ID: <044.8b40c90113b2e3dad255b12560d982a0@localhost> #3044: NoImplicitPrelude being ignored by 6.10.1, works in 6.8.2 -----------------------------+---------------------------------------------- Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- ~/bin/ghci -XNoImplicitPrelude Main.hs results in the module being loaded Expected result: the module should fail saying that putStrLn cannot be found/is not in scope. {{{ module Main where import Foo import qualified Prelude as P main = P.putStrLn [] }}} {{{ module Foo where zork = putStrLn "hi" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 07:43:27 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 07:32:31 2009 Subject: [GHC] #3025: Possible PiDigits memory explosion regression In-Reply-To: <045.83a907a9b608fda1ad14968d66d95fe2@localhost> References: <045.83a907a9b608fda1ad14968d66d95fe2@localhost> Message-ID: <054.91b06cb2c5498a4d6a9cd4519d997097@localhost> #3025: Possible PiDigits memory explosion regression ---------------------------------+------------------------------------------ Reporter: japple | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Almost certainly a dup of #2747. Retest with 6.10.2 and then close. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 07:44:19 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 07:33:24 2009 Subject: [GHC] #3025: Possible PiDigits memory explosion regression In-Reply-To: <045.83a907a9b608fda1ad14968d66d95fe2@localhost> References: <045.83a907a9b608fda1ad14968d66d95fe2@localhost> Message-ID: <054.67df950c27a38f4c2b08c8ca0347ee78@localhost> #3025: Possible PiDigits memory explosion regression ---------------------------------+------------------------------------------ Reporter: japple | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 07:46:30 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 07:35:32 2009 Subject: [GHC] #3028: what_next error In-Reply-To: <044.6a7021c20efa74e40884fe46c6d12d9b@localhost> References: <044.6a7021c20efa74e40884fe46c6d12d9b@localhost> Message-ID: <053.a524e76f4c45af14fddb849056b13c2e@localhost> #3028: what_next error -----------------------+---------------------------------------------------- Reporter: osuch | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: dup of #2818. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 07:47:58 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 07:37:14 2009 Subject: [GHC] #3030: GHCI Loading Compiled Modules Under Windows XP Crashes In-Reply-To: <045.6520dffed9f982658cc7c254dd664b33@localhost> References: <045.6520dffed9f982658cc7c254dd664b33@localhost> Message-ID: <054.52241b3a31f8e3057de600422d9e9d2d@localhost> #3030: GHCI Loading Compiled Modules Under Windows XP Crashes -----------------------+---------------------------------------------------- Reporter: jburck | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Can you give us specific instructions to reproduce? Exactly what commands did you type? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 07:50:23 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 07:39:27 2009 Subject: [GHC] #3033: numerical error introduced by -O1 In-Reply-To: <045.049e49d5cb5eb4a62c5c7447049b290a@localhost> References: <045.049e49d5cb5eb4a62c5c7447049b290a@localhost> Message-ID: <054.20c95f68e9a436b97cc1edf25f7e64a6@localhost> #3033: numerical error introduced by -O1 ---------------------------------+------------------------------------------ Reporter: roland | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks guest (Lennart?). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 07:51:20 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 07:40:23 2009 Subject: [GHC] #3044: NoImplicitPrelude being ignored by 6.10.1, works in 6.8.2 In-Reply-To: <044.8b40c90113b2e3dad255b12560d982a0@localhost> References: <044.8b40c90113b2e3dad255b12560d982a0@localhost> Message-ID: <053.3738dcb8488479dbc401737c1cb8bd1f@localhost> #3044: NoImplicitPrelude being ignored by 6.10.1, works in 6.8.2 ------------------------------+--------------------------------------------- Reporter: fasta | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by fasta): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 07:56:06 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 07:45:09 2009 Subject: [GHC] #3037: GHC panics when configuring base In-Reply-To: <045.45590b53143628c417b0483ef73fb77f@localhost> References: <045.45590b53143628c417b0483ef73fb77f@localhost> Message-ID: <054.87eab8a97b149beaa2319d89010e80c2@localhost> #3037: GHC panics when configuring base -------------------------+-------------------------------------------------- Reporter: mooism | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: The error message is no longer a panic in 6.10.1: {{{ $ runhaskell Setup.hs configure : module `Prelude' is not loaded }}} Though perhaps it's equally obscure. We don't plan to support this anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 08:13:27 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 08:02:29 2009 Subject: [GHC] #3039: strange space usage In-Reply-To: <044.6222a2241621a8a36e8604831e185979@localhost> References: <044.6222a2241621a8a36e8604831e185979@localhost> Message-ID: <053.ecc891760f33ee242a576794bfa1013f@localhost> #3039: strange space usage -----------------------------------------+---------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonmar): Running the two versions of the program with +RTS -hT (no profiling) show identical heap profiles. Most of the stuff in the heap is Handles and Handle-related things. It looks like we're retaining quite a few Handles, perhaps because the finalizers take a while to run (the Handles are closed, but still in memory until the finalizer has run). The reason we have lots of retained list data that belongs to `f` is because each Handle contains its filename, and the filename was generated by `f`. Why it apparently goes away when inlining `g`, I've no idea. Could just random scheduling behaviour, perhaps all the finalizers are running earlier. Or it could be a profiling bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 08:17:32 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 08:06:35 2009 Subject: [GHC] #3045: GHCI Crashes Under Windows when loading compiled code Message-ID: <045.753f237853c90b31fef839a556ac402c@localhost> #3045: GHCI Crashes Under Windows when loading compiled code --------------------+------------------------------------------------------- Reporter: jburck | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- whenever I load any compiled code under GHCI I get the following when it tries to execute: : panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): loadObj: failed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 08:35:51 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 08:24:55 2009 Subject: [GHC] #3044: NoImplicitPrelude being ignored by 6.10.1, works in 6.8.2 In-Reply-To: <044.8b40c90113b2e3dad255b12560d982a0@localhost> References: <044.8b40c90113b2e3dad255b12560d982a0@localhost> Message-ID: <053.21ffd79da797193799eea0bf206a8730@localhost> #3044: NoImplicitPrelude being ignored by 6.10.1, works in 6.8.2 ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Comment: Was caused by already having a compiled `Foo.o` and `Foo.hi`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 11:55:40 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 11:44:45 2009 Subject: [GHC] #1473: isSpace is too slow In-Reply-To: <044.3c2c0fec916372178c4bf5ce7945c8fa@localhost> References: <044.3c2c0fec916372178c4bf5ce7945c8fa@localhost> Message-ID: <053.90d7761b40e6980a522fd5773662ab33@localhost> #1473: isSpace is too slow ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: gwern0@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 14:32:54 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 14:21:56 2009 Subject: [GHC] #3046: Generalized newtype deriving with associated types Message-ID: <053.5760498fe5df42ff01ed60b4c8b401f4@localhost> #3046: Generalized newtype deriving with associated types -----------------------------+---------------------------------------------- Reporter: LouisWasserman | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- When I have a {{{ class Foo a where type Bar a foobar :: a -> Bar a }}} an {{{ instance Foo Fooey ... }}} and {{{ newtype Fooey2 = F2 (Fooey) deriving (Foo) }}} I expect the automatically generated deriving to include {{{ type Bar Fooey2 = Bar Fooey }}} but this is not the case: I cannot get an associated type from a newtype to resolve to anything. My guess is that the combination of -XTypeFamilies and -XGeneralizedNewtypeDeriving is rare enough that this may simply not have been thought of yet, but it's something I'd like to see fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 14:34:25 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 14:23:27 2009 Subject: [GHC] #3046: Generalized newtype deriving with associated types In-Reply-To: <053.5760498fe5df42ff01ed60b4c8b401f4@localhost> References: <053.5760498fe5df42ff01ed60b4c8b401f4@localhost> Message-ID: <062.bac4df31eea632a8dfb51e179a7e2a69@localhost> #3046: Generalized newtype deriving with associated types ------------------------------+--------------------------------------------- Reporter: LouisWasserman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by LouisWasserman): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 14:36:27 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 14:25:36 2009 Subject: [GHC] #3047: Panic! (the 'impossible' happened) :) Message-ID: <049.1afc8a34b373d8cc459a64a5eb511c3e@localhost> #3047: Panic! (the 'impossible' happened) :) -----------------------+---------------------------------------------------- Reporter: bchallenor | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 -----------------------+---------------------------------------------------- I was just coding up a solution to a Project Euler problem when the following occurred. I'm attaching the source file. It should be useful as it's very short (well, except for there being a 46KB list on one line). I apologize if this is a duplicate, because I'm using a fairly old GHCi. Cheers Ben [1 of 1] Compiling Main ( C:/Users/Ben/Desktop/ProjectEuler/22.hs, i nterpreted ) : panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-mingw32): linkBCO: >= 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 14:39:50 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 14:28:57 2009 Subject: [GHC] #3047: Panic! (the 'impossible' happened) :) In-Reply-To: <049.1afc8a34b373d8cc459a64a5eb511c3e@localhost> References: <049.1afc8a34b373d8cc459a64a5eb511c3e@localhost> Message-ID: <058.08af3e36f60518bd44ae2f3ed559ab30@localhost> #3047: Panic! (the 'impossible' happened) :) ------------------------+--------------------------------------------------- Reporter: bchallenor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ------------------------+--------------------------------------------------- Comment (by bchallenor): This could well be a duplicate of http://hackage.haskell.org/trac/ghc/ticket/3022. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 14:44:04 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 14:33:08 2009 Subject: [GHC] #3022: ghc: panic! (the 'impossible' happened) linkBCO: >= 64k insns in BCO In-Reply-To: <044.30ac4f6e3902a654e6966b395559b244@localhost> References: <044.30ac4f6e3902a654e6966b395559b244@localhost> Message-ID: <053.1284413701719f50433932597fd7996e@localhost> #3022: ghc: panic! (the 'impossible' happened) linkBCO: >= 64k insns in BCO ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by bchallenor): This looks very similar to my bug. http://hackage.haskell.org/trac/ghc/ticket/3047 It's interesting that you also were doing Project Euler, though yours was on problem 18 and mine on 22. :) And it's also interesting that my solution to 18 didn't trigger the bug, even though I laid out my triangles nearly identically to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 15:12:20 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 15:01:30 2009 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.ea1a77f66868c599148519be7f821e14@localhost> #1074: -fwarn-unused-imports complains about wrong import ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): I've added a test case (based on the tar package). The expected outcome is no warnings with -Wall. The current outcome is: {{{ Test.hs:3:0: Warning: Module `System.FilePath' is imported, but nothing from it is used, except perhaps instances visible in `System.FilePath' To suppress this warning, use: import System.FilePath() }}} The specific instance of the problem in this test case is that we import: {{{ import qualified System.FilePath as FilePath.Native import qualified System.FilePath.Posix as FilePath.Posix import qualified System.FilePath.Windows as FilePath.Windows }}} and use things qualified from all three of them. The `System.FilePath` module is a re-export of one of the other two modules (but which one depends on the platform). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 16:15:38 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 16:04:42 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.7ac3e4c0b68d7704b2915784fb851ada@localhost> #3041: Arch independent binary representations -----------------------------+---------------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Comment (by nomeata): Just to be clear: If this code in Binary.hs: {{{ instance Binary Int where #if SIZEOF_HSINT == 4 put_ bh i = put_ bh (fromIntegral i :: Int32) get bh = do x <- get bh return $! (fromIntegral (x :: Int32)) #elif SIZEOF_HSINT == 8 put_ bh i = put_ bh (fromIntegral i :: Int64) get bh = do x <- get bh return $! (fromIntegral (x :: Int64)) #else #error "unsupported sizeof(HsInt)" #endif -- getF bh = getBitsF bh 32 }}} could be changed to this code (Int64 or Int32, but choose one) {{{ instance Binary Int where put_ bh i = put_ bh (fromIntegral i :: Int32) get bh = do x <- get bh return $! (fromIntegral (x :: Int32)) }}} then the Binary serialization would be arch-independent again. (At least, AFAICT) Is there any reason not to do so? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 16:53:03 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 16:43:16 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.97ff86f0eb5b1b0d8bb7755e1520bb53@localhost> #3041: Arch independent binary representations -----------------------------+---------------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Comment (by kaol): I'd use this, to add some error checking. {{{ instance Binary Int where put_ bh i = if i < (minBound::Int32) || i > (maxBound::Int32) then error "Binary.instance Binary Int: Int out of bounds for Int32" else put_ bh (fromIntegral i :: Int32) get bh = do x <- get bh return $! (fromIntegral (x :: Int32)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 17:00:49 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 16:49:49 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.4e0b201df1d688bf924a31c05de094a4@localhost> #3041: Arch independent binary representations -----------------------------+---------------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Comment (by dons): N.B. this isnt' referring to Data.Binary, which serialises as: {{{ -- Ints are are written as Int64s, that is, 8 bytes in big endian format instance Binary Int where put i = put (fromIntegral i :: Int64) get = liftM fromIntegral (get :: Get Int64) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 18:35:31 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 18:24:35 2009 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.c8f679f8379e9ca089632f523123061e@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Comment (by sof): I believe I have a trivial fix for this, and can forward for testing & commit, if still of interest. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 18:35:45 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 18:24:48 2009 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.a3503d5be427bc8d7662fcaf55b0a855@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Changes (by sof): * cc: sof (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 24 21:19:43 2009 From: trac at galois.com (GHC) Date: Tue Feb 24 21:08:50 2009 Subject: [GHC] #3048: Heap size suggestion gets ignored when -G1 flag is passed Message-ID: <042.4a4de14d2a27edaf21ce0d0005e7a315@localhost> #3048: Heap size suggestion gets ignored when -G1 flag is passed -----------------------------+---------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Try running any program with {{{-G1}}} and a large {{{-H}}} option -- for example, cichelli from the nofib suite: {{{ $ ./cichelli +RTS -s -H32M -G1 [output snipped] 41,211,752 bytes allocated in the heap 19,329,984 bytes copied during GC 1,760,916 bytes maximum residency (34 sample(s)) 36,724 bytes maximum slop 7 MB total memory in use (0 MB lost due to fragmentation) }}} Here, the suggestion of 32M seems to have been ignored, as the heap is at most 7M during execution. Whereas without {{{-G1}}}: {{{ ./cichelli +RTS -s -H32M [output snipped] 41,212,300 bytes allocated in the heap 1,121,304 bytes copied during GC 49,484 bytes maximum residency (1 sample(s)) 36,824 bytes maximum slop 31 MB total memory in use (0 MB lost due to fragmentation) }}} Here, the size suggestion is used and a 32M heap is allocated. Shouldn't the GC use the heap size suggestion even when there is only one generation? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 25 02:52:25 2009 From: trac at galois.com (GHC) Date: Wed Feb 25 02:41:25 2009 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@localhost> References: <042.bfabde61c4aa31a17887ff9436d679ab@localhost> Message-ID: <051.3f42b9d658162718cf49d40d85fd1637@localhost> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work ---------------------------------+------------------------------------------ Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): cf #3046 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 25 03:37:05 2009 From: trac at galois.com (GHC) Date: Wed Feb 25 03:26:05 2009 Subject: [GHC] #3049: STM with data invariants crashes GHC Message-ID: <046.1d33a67baae883decd123e9a74ad7517@localhost> #3049: STM with data invariants crashes GHC -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Ben Franksen writes: my ghc(i) crashes when using STM data invariants. This little piece of code demonstrates the problem: {{{ module Bug where import Control.Concurrent.STM test = do x <- atomically $ do v <- newTVar 0 always $ return True -- remove this line and all is fine return v atomically (readTVar x) >>= print }}} This is what ghci makes of it: {{{ ben@sarun> ghci Bug.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, modules loaded: Bug. *Bug> test Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package stm-2.1.1.2 ... linking ... done. zsh: segmentation fault ghci Bug.hs }}} I am using ghc-6.10.1 freshly installed from source with just a 'cabal install stm' thrown after it. BTW, the documentation for `Control.Concurrent.STM.TVar` lists... nothing. Similar with `Control.Monad.STM`. Well, at least the source link works, so one isn't completely lost... :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 25 04:51:04 2009 From: trac at galois.com (GHC) Date: Wed Feb 25 04:40:06 2009 Subject: [GHC] #1884: Win64 Port In-Reply-To: <047.1fa130761f7e9ddaef7c551aeff5576e@localhost> References: <047.1fa130761f7e9ddaef7c551aeff5576e@localhost> Message-ID: <056.b9c67ba33e80d22ed73051e4fd1fff6f@localhost> #1884: Win64 Port -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by guest): * cc: Bulat.Ziganshin@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 25 06:12:57 2009 From: trac at galois.com (GHC) Date: Wed Feb 25 06:02:02 2009 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.d898af1be271e09e1c68cdb0b1e6a28a@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Comment (by simonmar): Replying to [comment:17 sof]: > I believe I have a trivial fix for this, and can forward for testing & commit, if still of interest. Yes please! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 25 06:22:22 2009 From: trac at galois.com (GHC) Date: Wed Feb 25 06:11:36 2009 Subject: [GHC] #3049: STM with data invariants crashes GHC In-Reply-To: <046.1d33a67baae883decd123e9a74ad7517@localhost> References: <046.1d33a67baae883decd123e9a74ad7517@localhost> Message-ID: <055.89dd7dcd310d72a4b09f7a1e9ada8f76@localhost> #3049: STM with data invariants crashes GHC ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: kfrdbs@gmail.com (added) Comment: FWIW, it segfaults in 6.8.2 too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 25 13:14:22 2009 From: trac at galois.com (GHC) Date: Wed Feb 25 13:03:24 2009 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.6af4a6c831ee9b4cd444b550c6fd104a@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Comment (by sof): ok, not futzing with making this a proper patch: {{{ --- old-base/cbits/consUtils.c 2009-02-25 10:06:10.631125000 -0800 +++ new-base/cbits/consUtils.c 2009-02-25 10:06:10.646750000 -0800 @@ -25,10 +25,13 @@ DWORD flgs = ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT; if ( (h = (HANDLE)_get_osfhandle(fd)) != INVALID_HANDLE_VALUE ) { + /* Only for console-connected Handles */ + if ( GetFileType(h) == FILE_TYPE_CHAR ) { if ( GetConsoleMode(h,&st) && - SetConsoleMode(h, cooked ? (st | ENABLE_LINE_INPUT) : st & ~flgs) ) { + SetConsoleMode(h, cooked ? (st | flgs) : st & ~flgs) ) { return 0; } + } } return -1; } --- old-base/GHC/Handle.hs 2009-02-25 10:06:10.631125000 -0800 +++ new-base/GHC/Handle.hs 2009-02-25 10:06:10.646750000 -0800 @@ -1374,13 +1374,10 @@ is_tty <- fdIsTTY (haFD handle_) when (is_tty && isReadableHandleType (haType handle_)) $ case mode of -#ifndef mingw32_HOST_OS - -- 'raw' mode under win32 is a bit too specialised (and troublesome - -- for most common uses), so simply disable its use here. + -- Note: we used to disable 'cooked' mode setting + -- for mingw / win32 here, but it is now back on (and well + -- behaved for Console-connected Handles.) NoBuffering -> setCooked (haFD handle_) False -#else - NoBuffering -> return () -#endif _ -> setCooked (haFD handle_) True -- throw away spare buffers, they might be the wrong size }}} i.e., reliably (un)setting the line buffering flags of the underlying Console handle (if there's one) takes care of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 25 13:50:55 2009 From: trac at galois.com (GHC) Date: Wed Feb 25 13:39:56 2009 Subject: [GHC] #3050: parsec: bug in caret escape parsing Message-ID: <042.5f70547f1aef0fa66cee3b055ba52438@localhost> #3050: parsec: bug in caret escape parsing -----------------------------+---------------------------------------------- Reporter: sof | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The parsing of escape carets in character literals isn't quite right: * off-by-one (i.e., \^A == \NUL; ought to be \^A=\001) * only A-Z carets are supported. The following minor mod takes care of the problem: {{{ --- Text/ParserCombinators/Parsec/Token.hs 2009-02-20 10:49:32.115500000 -0800 +++ Text/ParserCombinators/Parsec/Token.hs.~1~ 2009-02-20 10:02:45.896750000 -0800 @@ -193,8 +193,8 @@ -- charControl :: CharParser st Char charControl = do{ char '^' - ; code <- (oneOf ['@'..'_']) <|> char '?' - ; return (if code == '?' then '\DEL' else toEnum (fromEnum code - fromEnum '@')) + ; code <- upper + ; return (toEnum (fromEnum code - fromEnum 'A')) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 25 17:15:21 2009 From: trac at galois.com (GHC) Date: Wed Feb 25 17:04:42 2009 Subject: [GHC] #2739: GHC API crashes on template haskell splices In-Reply-To: <044.3bac7d34665c04ceca674c8a12436d56@localhost> References: <044.3bac7d34665c04ceca674c8a12436d56@localhost> Message-ID: <053.d756add94a3d51ef1d871c5cc2c0e108@localhost> #2739: GHC API crashes on template haskell splices ---------------------------------+------------------------------------------ Reporter: waern | Owner: nominolo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by nominolo): * status: assigned => closed * resolution: => fixed Comment: The above patched has been back-ported and appears to work. Re-open this bug if you encounter any problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 26 01:47:07 2009 From: trac at galois.com (GHC) Date: Thu Feb 26 01:36:07 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.352d0fea36a868905ed9e39f9e072a75@localhost> #3041: Arch independent binary representations -----------------------------+---------------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Comment (by kaol): Here's another thought regarding this. Let's remove the whole {{{instance Binary Int}}}. That'd make anyone using Binary to have to choose between using Int32 and Int64. Having an Int instance is just asking for errors when moving data between 32 and 64 bit architectures, at some point. It may be inconvenient for people using Binary, but I assume that it's meant to be a low level interface, anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 26 10:41:35 2009 From: trac at galois.com (GHC) Date: Thu Feb 26 10:31:18 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.a7a6cd021116d053fab895e65550f19a@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by clemens): * cc: clemens@endorphin.org (removed) * status: assigned => new * owner: clemens => simonmar Comment: Simon, I didn't see any serious attempts to get buildbots going. Iirc I fixed "make install" to that extent where regression tests could have been run. Also I do not see any reason, how establishing base line quality is related to deployment upgrading and installation lifetime issues. If GHC doesn't have a way of regression testing shared libs in whatever conceptual broken they may be now than GHC will fail to deliver. That's simply because shared libs will bitrot in the ongoing development. As I can't put this bug into an unassigned status, I hope simon you don't mind if I reassign it to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 26 10:57:44 2009 From: trac at galois.com (GHC) Date: Thu Feb 26 10:47:22 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.437119059dd671530aba01acef5cd1fd@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => Comment: Replying to [comment:21 clemens]: > Simon, I didn't see any serious attempts to get buildbots going. Iirc I fixed "make install" to that extent where regression tests could have been run. > > Also I do not see any reason, how establishing base line quality is related to deployment upgrading and installation lifetime issues. If GHC doesn't have a way of regression testing shared libs in whatever conceptual broken they may be now than GHC will fail to deliver. That's simply because shared libs will bitrot in the ongoing development. You're right, nothing prevents us from setting up buildbots (except lack of time). But I would really like to have a clear plan of action for getting us to the goal of having shared libs deployed. It's probably not difficult, but someone/people need to sit down and seriously think about how all this is going to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 04:08:01 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 03:56:54 2009 Subject: [GHC] #3051: Add product/sum/maximum/minimum specialisations for more atomic types Message-ID: <050.4cbbe590f771bebce8bcbc747d03bc73@localhost> #3051: Add product/sum/maximum/minimum specialisations for more atomic types -----------------------------+---------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Quoting dons (http://www.haskell.org/pipermail/glasgow-haskell- users/2009-February/016707.html): ... product/sum/maximum/minimum on lists have specialisations for some atomic types (Int, Integer) but not all (needs a ticket for this too). So here is that ticket, just to help us remember. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 06:59:35 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 06:48:39 2009 Subject: [GHC] #3052: ghc FFI doesn't support thiscall Message-ID: <047.ea34806f73921c57cbc395f3f5a9a535@localhost> #3052: ghc FFI doesn't support thiscall ---------------------+------------------------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------+------------------------------------------------------ The ghc FFI does not support the "thiscall" calling convention. This is the calling convention used by Microsoft C++ for calling methods. It's like the stdcall calling convention, except that the "this" pointer is passed in ECX. Without this calling convention it's impossible to interact with (Msft) C++ objects. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 08:25:35 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 08:14:31 2009 Subject: [GHC] #3053: Modular arithmetic bug? Message-ID: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> #3053: Modular arithmetic bug? --------------------+------------------------------------------------------- Reporter: vlaad | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: critical Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- GHC dies here (please note the x < 200 limit): take 15 [x | x <- [1..], x < 200, x `mod` 6 == 1, x `mod` 6 == 5] And here (nothing with infix notation): take 15 [x | x <- [1..], x < 200, mod x 6 == 1, mod x 6 == 5] But *not* here: take 15 [x | x <- [1..], mod x 6 == 1, x < 200, x > 100] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 08:35:17 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 08:24:11 2009 Subject: [GHC] #3053: Modular arithmetic bug? In-Reply-To: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> References: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> Message-ID: <053.025a85b8d40e84185f0cdd74b7f3ab4e@localhost> #3053: Modular arithmetic bug? ----------------------+----------------------------------------------------- Reporter: vlaad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by claus): The `x<200` is a *filter*, not a limit. Perhaps you mean {{{ Prelude> [x|x<-[1..200],x`mod`6==1,x`mod`6==5] [] }}} Otherwise, GHC will happily try and dismiss all those numbers in `[200..]`, which will keep it busy for a while!-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 08:46:53 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 08:35:55 2009 Subject: [GHC] #3053: Modular arithmetic bug? In-Reply-To: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> References: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> Message-ID: <053.82c21adc933710ce782ed6b94ca82139@localhost> #3053: Modular arithmetic bug? ----------------------+----------------------------------------------------- Reporter: vlaad | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: invalid Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Changes (by augustss): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 08:51:26 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 08:40:27 2009 Subject: [GHC] #3053: Modular arithmetic bug? In-Reply-To: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> References: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> Message-ID: <053.84face2266f001bf735a36b8296b01e4@localhost> #3053: Modular arithmetic bug? ----------------------+----------------------------------------------------- Reporter: vlaad | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Changes (by vlaad): * status: closed => reopened * resolution: invalid => Comment: > Otherwise, GHC will happily try and dismiss all those numbers in `[200..]`, which will keep it busy for a while!-) Why then we forget about infinite series support, if we have to wait the GHCi to approach the infinity? Here is another one NOT WORKING: take 2 [x | x <- [1,2..], x < 195, x > 188, mod x 6 == 2] Please don't tell me that GHCi will enumerate from 1 to infinity, what about this WORKING example: take 2 [x | x <- [255255..], mod x 15 == 2] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 09:01:48 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 08:50:48 2009 Subject: [GHC] #3053: Modular arithmetic bug? In-Reply-To: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> References: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> Message-ID: <053.282e771cff13f25b0f13f232c132e4b7@localhost> #3053: Modular arithmetic bug? ----------------------+----------------------------------------------------- Reporter: vlaad | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: invalid Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Changes (by augustss): * status: reopened => closed * resolution: => invalid Comment: Both ghc and ghci are working exactly as they should. If you say {{{ [ x | x <- [1..], x < 10] }}} then it will let x go through all the numbers from 1 and up, and only keep those that are < 10. The compiler "does not know" that the seqeunce is monotonically increasing, so it has to loop after delivering 9, because it "thinks" that somewhere in the infinite list (beyond 9) there could again be a number < 10. This is '''not''' a bug. (And indeed, for some non-standard kind of numbers it could very well be that enumFrom would deliver some smaller numbers later.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 09:11:00 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 09:00:00 2009 Subject: [GHC] #3053: Modular arithmetic bug? In-Reply-To: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> References: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> Message-ID: <053.aea368f55f32f63d4afe21ac06a2175e@localhost> #3053: Modular arithmetic bug? ----------------------+----------------------------------------------------- Reporter: vlaad | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: invalid Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by vlaad): Well, if this is *not* a bug, then please explain how in your first response we are getting an empty list? (or better, stop thinking, and pass it to the guys, please). ("Perhaps you mean [x|x<-[1..200],x`mod`6==1,x`mod`6==5]") {{{ Prelude> [x|x<-[1..20],x`mod`6==5] [5,11,17] Prelude> [x|x<-[1..20],x`mod`6==1] [1,7,13,19] Prelude> [x|x<-[1..20],x`mod`6==1,x`mod`6==5] [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 09:13:03 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 09:02:04 2009 Subject: [GHC] #3053: Modular arithmetic bug? In-Reply-To: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> References: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> Message-ID: <053.f306ce55a7b668e3844698d9c33caf6d@localhost> #3053: Modular arithmetic bug? ----------------------+----------------------------------------------------- Reporter: vlaad | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: invalid Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by vlaad): I'm sorry. Wrong example. This is stupid. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 09:20:42 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 09:09:48 2009 Subject: [GHC] #3053: Modular arithmetic bug? In-Reply-To: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> References: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> Message-ID: <053.02fe53423f0780a7abfcae4830c76541@localhost> #3053: Modular arithmetic bug? ----------------------+----------------------------------------------------- Reporter: vlaad | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: invalid Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by vlaad): However, I'm totally dicouraged in using GHC, thanks to the fact that it is the only Haskell compiler around, and thanks to your fanatic dedication to it's advocacy (I've just happily uninstalled it). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 09:46:19 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 09:35:20 2009 Subject: [GHC] #3053: Modular arithmetic bug? In-Reply-To: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> References: <044.7eeb05a218f2cd60f9d5254f19c717db@localhost> Message-ID: <053.481cb392ba01b192e78433035b2530e7@localhost> #3053: Modular arithmetic bug? ----------------------+----------------------------------------------------- Reporter: vlaad | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: critical | Resolution: invalid Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by augustss): Why are you discouraged by ghc? What you reported is not a bug and all Haskell implementations will give you the same answer. To put it another way, of you have a list comprehension [ e | x <- gen, ... ] and you look at the resulting list then the result list will only ever end when the generator (gen) gets to the end of its list. This is according to the definition of Haskell and has nothing to do with ghc. If you want a language where list comprehensions behave in some other way, then you'll have to look elsewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 10:51:29 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 10:40:22 2009 Subject: [GHC] #1891: New RTS "--info" option not in help message In-Reply-To: <044.c4d7d82a3e73e3a3ea77f97a5cdf5109@localhost> References: <044.c4d7d82a3e73e3a3ea77f97a5cdf5109@localhost> Message-ID: <053.c6b40281205c0726736383232a2ac195@localhost> #1891: New RTS "--info" option not in help message ---------------------------------+------------------------------------------ Reporter: Orphi | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the patch! I've applied it to HEAD and 6.10. `"GHC RTS"` is always `"YES"`. It's partly because being sure you're looking at what you think you're looking at is useful, and partly because it makes the code simpler (all the other lines start ` ,(` but that one starts ` [(` so it's simpler to make it a hardcoded string than to generalise the code for printing lines). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 14:38:48 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 14:27:42 2009 Subject: [GHC] #2997: Package names starting with a numeric character cause assembler errors In-Reply-To: <044.06fddb0d2b915fea9056d01f9dd6ea43@localhost> References: <044.06fddb0d2b915fea9056d01f9dd6ea43@localhost> Message-ID: <053.5a8c61c38c48ca3b6fff91977619f883@localhost> #2997: Package names starting with a numeric character cause assembler errors ---------------------------------+------------------------------------------ Reporter: mboes | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.10: {{{ Fri Feb 27 18:00:29 GMT 2009 Ian Lynagh * z-encode digits at the start of a symbol name; fixes trac #2997 Digits already have a couple of meanings in z-encoding (Z3T is a tuple, and z123U is a unicode character), so we encode digits as unicode characters to avoid trying to squeeze in another meaning. Also removed a little GHC < 6.2 compatibility hack. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 18:44:15 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 18:33:07 2009 Subject: [GHC] #2983: Segmentation fault in ray tracer with certain options In-Reply-To: <052.ab008e7a26a83a06094f6364ea685223@localhost> References: <052.ab008e7a26a83a06094f6364ea685223@localhost> Message-ID: <061.4ec94d0ddedc5fbf08aa5fd881ef82ac@localhost> #2983: Segmentation fault in ray tracer with certain options --------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: seg fault, ray tracer | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | --------------------------------------+------------------------------------- Comment (by igloo): This instruction: {{{ 0x00001915 : xorpd 0x18deb8,%xmm0 }}} fails as the first argument is not 16-byte aligned. Unfortunately the error: {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x00000000 }}} is rather cryptic (0x00000000?). This is related to #2917, and the planned short-term fix of 16-byte aligning everything should fix it. These flags are sufficient to trigger it: `-O2 -funbox-strict-fields -fvia-C`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 18:44:29 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 18:33:30 2009 Subject: [GHC] #2917: alloca and allocaArray do not respect alignment In-Reply-To: <044.ae4012da6404813e981e2064d26c5c85@localhost> References: <044.ae4012da6404813e981e2064d26c5c85@localhost> Message-ID: <053.694fa049ba9adcc8a66a6e0eea0c5eb2@localhost> #2917: alloca and allocaArray do not respect alignment ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler (FFI) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): See also #2983. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 27 19:29:47 2009 From: trac at galois.com (GHC) Date: Fri Feb 27 19:18:39 2009 Subject: [GHC] #3035: :steplocal and :stepmodule should not polute trace history In-Reply-To: <046.666e1eb28f46a24ca4e7454edb2b85e1@localhost> References: <046.666e1eb28f46a24ca4e7454edb2b85e1@localhost> Message-ID: <055.0e25845fb571045b7c3754f72808a849@localhost> #3035: :steplocal and :stepmodule should not polute trace history ---------------------------------+------------------------------------------ Reporter: phercek | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 28 01:37:03 2009 From: trac at galois.com (GHC) Date: Sat Feb 28 01:25:54 2009 Subject: [GHC] #3054: ghc crashes with unicode escape and literal character together Message-ID: <050.72ac5435f2e7988cfb77528882a5529e@localhost> #3054: ghc crashes with unicode escape and literal character together ------------------------+--------------------------------------------------- Reporter: iamfishhead | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ------------------------+--------------------------------------------------- On debian testing, ghc panics on the atached file. The file simply has a unicode character escape followed by the character itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 28 05:22:23 2009 From: trac at galois.com (GHC) Date: Sat Feb 28 05:11:14 2009 Subject: [GHC] #2998: Expose the internals of the network library to make it more extensible In-Reply-To: <044.38e242663cf791489f4226de94cd9e56@localhost> References: <044.38e242663cf791489f4226de94cd9e56@localhost> Message-ID: <053.9617e08e179f539686806b34a19c474a@localhost> #2998: Expose the internals of the network library to make it more extensible ----------------------------------+----------------------------------------- Reporter: tibbe | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by tibbe): * owner: => igloo Comment: All four patches that make up the new module are in `expose-socket- internals-in-a-new-module_.dpatch`. That file subsumes `internal.patch`. I would like to make a new release of the library as soon as possible as I have a second library I want to release that needs these changes. What can I do to help with the release process? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 28 08:22:41 2009 From: trac at galois.com (GHC) Date: Sat Feb 28 08:11:37 2009 Subject: [GHC] #1377: GHCi debugger tasks In-Reply-To: <047.b3e158073b17fc81d3d320da105cad09@localhost> References: <047.b3e158073b17fc81d3d320da105cad09@localhost> Message-ID: <056.4f0a2c311c8586cb9cf873bcd5f0405f@localhost> #1377: GHCi debugger tasks ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: mnislaih Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: igloo => mnislaih Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 28 08:58:21 2009 From: trac at galois.com (GHC) Date: Sat Feb 28 08:53:34 2009 Subject: [GHC] #2957: GHC head build fails on non-GNU system assuming `patch' command is GNU patch In-Reply-To: <046.69b0f585273150506f0caa1d5b147736@localhost> References: <046.69b0f585273150506f0caa1d5b147736@localhost> Message-ID: <055.dae97c8d7d9bde8607dc62c56bf62602@localhost> #2957: GHC head build fails on non-GNU system assuming `patch' command is GNU patch -------------------------------+-------------------------------------------- Reporter: kgardas | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Done: {{{ Sat Feb 28 13:27:29 GMT 2009 Ian Lynagh * Use gpatch rather than patch if it exists; trac #2957 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 28 09:08:10 2009 From: trac at galois.com (GHC) Date: Sat Feb 28 08:57:00 2009 Subject: [GHC] #2998: Expose the internals of the network library to make it more extensible In-Reply-To: <044.38e242663cf791489f4226de94cd9e56@localhost> References: <044.38e242663cf791489f4226de94cd9e56@localhost> Message-ID: <053.6c7bed6be8b5c849659ef7f1baf03023@localhost> #2998: Expose the internals of the network library to make it more extensible ----------------------------------+----------------------------------------- Reporter: tibbe | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 28 10:50:04 2009 From: trac at galois.com (GHC) Date: Sat Feb 28 10:38:54 2009 Subject: [GHC] #2942: witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case-sensitive file system In-Reply-To: <050.2d88d56a844b36381f7e789271b08f2d@localhost> References: <050.2d88d56a844b36381f7e789271b08f2d@localhost> Message-ID: <059.ca0dde71a68c87a77a0d5db62921a42b@localhost> #2942: witten/ghc-6.10.1-powerpc-apple-darwin.tar.bz2: make install fails on case- sensitive file system ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: None | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: The tarball contains a directory `ghc-6.10.1/dist/utils/haddock/dist- install/build/Haddock/`. I can't work out how this can happen, and I've failed to reproduce it. I'm going to assume that some manual tweak caused the problem, but if anyone can reproduce it then please reopen this ticket. Incidentally, here's how to make a case-sensitive file system on OS X: {{{ dd if=/dev/zero bs=4096 count=1048576 of=disk.img hdid -nomount disk.img # prints /dev/disk1 newfs_hfs -s /dev/disk1 mkdir mnt mount -t hfs /dev/disk1 mnt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 28 11:06:09 2009 From: trac at galois.com (GHC) Date: Sat Feb 28 10:55:10 2009 Subject: [GHC] #2884: Compiled code performance worsens when module names are long enough In-Reply-To: <049.881bd6a7c8430691cda844d87df64824@localhost> References: <049.881bd6a7c8430691cda844d87df64824@localhost> Message-ID: <058.1cb3390ad32e32d8ca204b3cfb8eeefb@localhost> #2884: Compiled code performance worsens when module names are long enough -----------------------------------------+---------------------------------- Reporter: jcpetruzza | Owner: igloo Type: run-time performance bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Looks good: {{{ ./long-modname-ver > /dev/null 25.63s user 0.02s system 99% cpu 25.664 total ./short-modname-ver > /dev/null 25.49s user 0.01s system 100% cpu 25.488 total ./long-modname-ver > /dev/null 25.33s user 0.02s system 100% cpu 25.349 total ./short-modname-ver > /dev/null 25.29s user 0.02s system 99% cpu 25.323 total }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 28 11:54:16 2009 From: trac at galois.com (GHC) Date: Sat Feb 28 11:43:06 2009 Subject: [GHC] #2923: Documentation contains (broken) links to /home/ian In-Reply-To: <047.8599083b3310893fae769d528dbb6224@localhost> References: <047.8599083b3310893fae769d528dbb6224@localhost> Message-ID: <056.889ace09c71ace73baa1439c8e6a2050@localhost> #2923: Documentation contains (broken) links to /home/ian ---------------------------------+------------------------------------------ Reporter: matthijs | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Documentation | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: The paths look OK to me when merging the docs from: {{{ ghc-6.10.1.20090226-i386-unknown-linux.tar.bz2 ghc-6.10.1.20090226-i386-unknown-mingw32.tar.bz2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 28 13:43:37 2009 From: trac at galois.com (GHC) Date: Sat Feb 28 13:32:27 2009 Subject: [GHC] #2996: Network.Socket.sClose should change socket status In-Reply-To: <046.41f89e25a108f554724958983d75e152@localhost> References: <046.41f89e25a108f554724958983d75e152@localhost> Message-ID: <055.86b69d3e89c6071d11a1a1b5df8527dd@localhost> #2996: Network.Socket.sClose should change socket status ----------------------------------+----------------------------------------- Reporter: amthrax | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * owner: igloo => tibbe Comment: tibbe, this looks related to things you've been working on recently, and I think you are considering becoming the network maintainer? Can you take a look please? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler