From trac at galois.com Thu Feb 1 06:35:22 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:11 2007 Subject: [GHC] #926: infinite loop in ShutdownIOManager() In-Reply-To: <071.86ee97d4857ba270234e4df36500cca2@localhost> References: <071.86ee97d4857ba270234e4df36500cca2@localhost> Message-ID: <080.e0bcf75bcb341d1bb8c863325c4667df@localhost> #926: infinite loop in ShutdownIOManager() ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'm looking at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 1 06:58:31 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:11 2007 Subject: [GHC] #926: infinite loop in ShutdownIOManager() In-Reply-To: <071.86ee97d4857ba270234e4df36500cca2@localhost> References: <071.86ee97d4857ba270234e4df36500cca2@localhost> Message-ID: <080.e88521431e11a77f0145be3d16e497e5@localhost> #926: infinite loop in ShutdownIOManager() ----------------------------+----------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * milestone: 6.6.1 => _|_ * priority: normal => lowest Comment: Fixed in the threaded RTS: {{{ Thu Feb 1 03:40:47 PST 2007 Simon Marlow * Partial fix for #926 It seems that when a program exits with open DLLs on Windows, the system attempts to shut down the DLLs, but it also terminates (some of?) the running threads. The RTS isn't prepared for threads to die unexpectedly, so it sits around waiting for its workers to finish. This bites in two places: ShutdownIOManager() in the the unthreaded RTS, and shutdownCapability() in the threaded RTS. So far I've modified the latter to notice when worker threads have died unexpectedly and continue shutting down. It seems a bit trickier to fix the unthreaded RTS, so for now the workaround for #926 is to use the threaded RTS. }}} I'll leave the bug open, but at a low priority since there are good workarounds. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 1 07:03:36 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:11 2007 Subject: [GHC] #1114: Socket code dies with SIGPIPE In-Reply-To: <071.8c4d161251ac79ad24ee4058a7b86539@localhost> References: <071.8c4d161251ac79ad24ee4058a7b86539@localhost> Message-ID: <080.5eec090728ce5a85ea9c8495dce75a7c@localhost> #1114: Socket code dies with SIGPIPE ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: hslibs/net | Version: 6.6 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------+--------------------------------------------------- Changes (by simonmar): * resolution: => invalid * status: new => closed Comment: Not a bug: this is the correct (although perhaps unexpected) behaviour. It's documented in the docs for the `Network` module. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 1 07:43:20 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1108: -package and -idir in OPTIONS_GHC are ignored, but manual says that they're dynamic In-Reply-To: <071.2ec6a2378018138b05a8fe91c12aafea@localhost> References: <071.2ec6a2378018138b05a8fe91c12aafea@localhost> Message-ID: <080.7ce0bd2c18229b796a3682260f2c05d3@localhost> #1108: -package and -idir in OPTIONS_GHC are ignored, but manual says that they're dynamic --------------------------------+------------------------------------------- Reporter: bjorn@bringert.net | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: These flags are not fully dynamic: they work with GHCi's `:set`, but not in `OPTIONS_GHC`. I've now documented that. Ian, please merge: {{{ Thu Feb 1 12:40:58 GMT 2007 Simon Marlow * some dynamic flags cannot be used with OPTIONS_GHC, e.g. -i, -package fixes #1108 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 1 07:49:42 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1125: "module main:Foo is not loaded" when trying to load a module from a user package in ghci In-Reply-To: <071.58f58fdb3ad60dee1a89a750492ea87b@localhost> References: <071.58f58fdb3ad60dee1a89a750492ea87b@localhost> Message-ID: <080.f0fa1b4c36ec4296f7075fe1ac4150e9@localhost> #1125: "module main:Foo is not loaded" when trying to load a module from a user package in ghci ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * resolution: => invalid * status: new => closed Comment: This isn't a bug. It works like this: * You have built and installed a package "p", containing module `Foo`. * You start up GHCi and ask it to add module `Foo` to the context, you expect to get `p:Foo`. * GHCi finds the file `Foo.hs` in the current directory. It assumes that this contains module `Foo` from the `main` package: `main:Foo`. Modules from the `main` package take precedence over package modules for the purposes of `import` and `:module`. * Since you haven't loaded `main:Foo` in your current GHCi session, GHCi emits an error to that effect. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 1 07:59:09 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1106: During install, network's Typeable.h clobbers base's copy In-Reply-To: <071.e8cc3e5e32654f07bcd20620447c547c@localhost> References: <071.e8cc3e5e32654f07bcd20620447c547c@localhost> Message-ID: <080.8073e0b1553ad96a55d97a9eb64c42ee@localhost> #1106: During install, network's Typeable.h clobbers base's copy ----------------------+----------------------------------------------------- Reporter: bos | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Fixed. To merge: {{{ Thu Feb 1 12:58:21 GMT 2007 Simon Marlow * don't install Typeable.h, fixes #1106 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 1 08:36:05 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #978: install-sh has wrong permissions In-Reply-To: <071.b27e03aa783341a1a5bb17de078f9e46@localhost> References: <071.b27e03aa783341a1a5bb17de078f9e46@localhost> Message-ID: <080.d6e6e5defe83f9893d19de22e63f3cf3@localhost> #978: install-sh has wrong permissions -----------------------------+---------------------------------------------- Reporter: giraudr@unbc.ca | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Build System | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -----------------------------+---------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Fixed. To merge: {{{ Thu Feb 1 05:11:25 PST 2007 Simon Marlow * chmod +x install-sh, see bug #978 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 1 08:43:02 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #985: Memory Leak in freeHaskellFunPtr In-Reply-To: <071.9cb80b2e06bee3baa5c2661f50fb5b56@localhost> References: <071.9cb80b2e06bee3baa5c2661f50fb5b56@localhost> Message-ID: <080.cd7809ff905401f4d48e039edced8b42@localhost> #985: Memory Leak in freeHaskellFunPtr ----------------------------------------------+----------------------------- Reporter: mattcbro@earthlink.net | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: callback, FFI, freeHaskellFunPtr | Difficulty: Unknown Testcase: provided | Architecture: Multiple Os: Windows | ----------------------------------------------+----------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'll look into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 1 08:56:24 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #985: Memory Leak in freeHaskellFunPtr In-Reply-To: <071.9cb80b2e06bee3baa5c2661f50fb5b56@localhost> References: <071.9cb80b2e06bee3baa5c2661f50fb5b56@localhost> Message-ID: <080.637a5ad0ae7476eb896597038f520021@localhost> #985: Memory Leak in freeHaskellFunPtr ----------------------------------------------+----------------------------- Reporter: mattcbro@earthlink.net | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: callback, FFI, freeHaskellFunPtr | Difficulty: Unknown Testcase: provided | Architecture: Multiple Os: Windows | ----------------------------------------------+----------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed. Patch to merge (from 6.6 to HEAD): {{{ Thu Feb 1 13:53:33 GMT 2007 Simon Marlow * fix memory leak in allocExec/freeExec (see bug #985) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 2 05:05:11 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #916: windows installer should play nice with other Haskell tools In-Reply-To: <071.1c16afbb02d1b735d89fd95dfc2c062e@localhost> References: <071.1c16afbb02d1b735d89fd95dfc2c062e@localhost> Message-ID: <080.598f4af92f5e94afc686f5e71054649e@localhost> #916: windows installer should play nice with other Haskell tools -------------------------------------+-------------------------------------- Reporter: claus.reinke@talk21.com | Owner: neil Type: bug | Status: new Priority: low | Milestone: 6.6.2 Component: Build System | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: Unknown Os: Windows | -------------------------------------+-------------------------------------- Changes (by neil): * difficulty: Unknown => Difficult (1 week) * component: GHCi => Build System * priority: normal => low * owner: => neil Comment: One option is WiX, as bug 604 suggests. I've also copied the priority/settings from that bug to this one. I intend to solve this at the same time as doing an installer for Yhc/Hugs/Cabal etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 2 05:06:07 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #604: Windows installer: use WiX In-Reply-To: <071.6d8ec6bcf0782d06f763c5fe4aa61ad9@localhost> References: <071.6d8ec6bcf0782d06f763c5fe4aa61ad9@localhost> Message-ID: <080.09120218de287fbf108b766e88734129@localhost> #604: Windows installer: use WiX --------------------------+------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: low | Milestone: 6.6.1 Component: Build System | Version: None Severity: normal | Resolution: duplicate Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by guest): * resolution: None => duplicate * status: new => closed Comment: Bug 916 is more general than this bug - this bug is just one option, that bug is the whole problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 2 16:17:12 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #998: Tab-completion of filenames does not work in GHCi 6.6 In-Reply-To: <071.6210fcc1137fd53f42bfc89f0aabacc7@localhost> References: <071.6210fcc1137fd53f42bfc89f0aabacc7@localhost> Message-ID: <080.ce565e2e3fa2fd062b751d23a5924858@localhost> #998: Tab-completion of filenames does not work in GHCi 6.6 ------------------------------------+--------------------------------------- Reporter: dm.maillists@gmail.com | Owner: judahj Type: bug | Status: new Priority: low | Milestone: 6.6.1 Component: GHCi | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ------------------------------------+--------------------------------------- Changes (by judahj): * owner: => judahj Comment: I'm looking into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 2 19:36:23 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1106: During install, network's Typeable.h clobbers base's copy In-Reply-To: <071.e8cc3e5e32654f07bcd20620447c547c@localhost> References: <071.e8cc3e5e32654f07bcd20620447c547c@localhost> Message-ID: <080.f70213de101c11608b55dc86ed3a82d8@localhost> #1106: During install, network's Typeable.h clobbers base's copy ----------------------+----------------------------------------------------- Reporter: bos | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: network is an extralib, so no merging to be done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 2 20:15:48 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1108: -package and -idir in OPTIONS_GHC are ignored, but manual says that they're dynamic In-Reply-To: <071.2ec6a2378018138b05a8fe91c12aafea@localhost> References: <071.2ec6a2378018138b05a8fe91c12aafea@localhost> Message-ID: <080.c96935453b30bdd8d3924b27b5f8b62e@localhost> #1108: -package and -idir in OPTIONS_GHC are ignored, but manual says that they're dynamic --------------------------------+------------------------------------------- Reporter: bjorn@bringert.net | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 2 20:16:29 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #978: install-sh has wrong permissions In-Reply-To: <071.b27e03aa783341a1a5bb17de078f9e46@localhost> References: <071.b27e03aa783341a1a5bb17de078f9e46@localhost> Message-ID: <080.b2668e541054e4d41101990d90aa985c@localhost> #978: install-sh has wrong permissions -----------------------------+---------------------------------------------- Reporter: giraudr@unbc.ca | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Build System | Version: 6.6 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -----------------------------+---------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From sven.panne at aedion.de Sat Feb 3 07:04:41 2007 From: sven.panne at aedion.de (Sven Panne) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #985: Memory Leak in freeHaskellFunPtr In-Reply-To: <080.637a5ad0ae7476eb896597038f520021@localhost> References: <071.9cb80b2e06bee3baa5c2661f50fb5b56@localhost> <080.637a5ad0ae7476eb896597038f520021@localhost> Message-ID: <200702031304.41820.sven.panne@aedion.de> Am Donnerstag, 1. Februar 2007 14:56 schrieb GHC: > #985: Memory Leak in freeHaskellFunPtr > ----------------------------------------------+---------------------------- >- Reporter: mattcbro@earthlink.net | Owner: igloo > Type: merge | Status: new Priority: > normal | Milestone: 6.6.1 Component: > Compiler | Version: 6.6 Severity: normal > | Resolution: > Keywords: callback, FFI, freeHaskellFunPtr | Difficulty: Unknown > Testcase: provided | Architecture: Multiple > Os: Windows | > ----------------------------------------------+---------------------------- >- Changes (by simonmar): > > * owner: simonmar => igloo > * type: bug => merge > > Comment: > > Fixed. Patch to merge (from 6.6 to HEAD): > > {{{ > Thu Feb 1 13:53:33 GMT 2007 Simon Marlow > * fix memory leak in allocExec/freeExec (see bug #985) > }}} Hmmm, I think I haven't seen this patch in the HEAD yet. In general: The current quite liberal (a.k.a. chaotic :-) ) style where patches are somtetimes applied to STABLE first and merged to HEAD later and vice versa gives me some headaches. In good old times we fixed the HEAD and simply merged this to STABLE. :-( Is there an automatic way to see which patches should still be merged into which direction? If not, we should handle things a bit stricter, I guess... Cheers, S. From igloo at earth.li Sat Feb 3 09:01:05 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #985: Memory Leak in freeHaskellFunPtr In-Reply-To: <200702031304.41820.sven.panne@aedion.de> References: <071.9cb80b2e06bee3baa5c2661f50fb5b56@localhost> <080.637a5ad0ae7476eb896597038f520021@localhost> <200702031304.41820.sven.panne@aedion.de> Message-ID: <20070203140105.GA24689@matrix.chaos.earth.li> On Sat, Feb 03, 2007 at 01:04:41PM +0100, Sven Panne wrote: > Am Donnerstag, 1. Februar 2007 14:56 schrieb GHC: > > > > Fixed. Patch to merge (from 6.6 to HEAD): > > > > {{{ > > Thu Feb 1 13:53:33 GMT 2007 Simon Marlow > > * fix memory leak in allocExec/freeExec (see bug #985) > > }}} > > Hmmm, I think I haven't seen this patch in the HEAD yet. I haven't seen it anywhere; I think Simon forgot to push it (either that or I'm just being dopier than normal). > Is there an automatic way to see which patches > should still be merged into which direction? The http://cvs.haskell.org/trac/ghc/wiki/6.6_Branch page describes how to check that there are no patches in 6.6 only that should be in the HEAD (although I haven't been actively keeping the list of exceptions up-to-date; I think it'll be easier to do a bulk update when checking that the HEAD is not missing anything, as there shouldn't be many new patches missing from the head, and most of them should be called "MERGED.*"). For patches in the HEAD that should be in 6.6, the number of exceptions would make the same system impractical. To make sure a patch doesn't get missed, open a trac ticket of type "merge" and put the patch name in it. (Noting that it should be merged in the patch description or sending an e-mail to ask for it to be merged are also OK, but obviously if I miss them then there is no easy way of noticing). Thanks Ian From trac at galois.com Sat Feb 3 11:28:33 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1131: newArray_ allocates an array full of garbage Message-ID: <071.6b2cae20fb162cd1f285dd3e5c20892b@localhost> #1131: newArray_ allocates an array full of garbage -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- In http://www.haskell.org/pipermail/haskell-cafe/2006-December/020115.html Stefan O'Rear points out that newArray_ allocates an array full of garbage. For ST this violates referential transparency, and it presumably also means we are leaking information we shouldn't. For example, running {{{ import Control.Monad.ST import Data.Array.ST import Data.Array import System.Mem tickle :: Int tickle = runST (do { x <- newArray_ (0,100) ; (readArray :: STUArray s Int Int -> Int -> ST s Int) x 3 }) main :: IO () main = do print $ length (replicate 100000 'a') performGC print tickle }}} produced {{{ $ ./q 100000 46912506425344 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 5 00:49:25 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1132: Data.ByteString.Lazy.Char8's readInt does no bounds checking Message-ID: <071.f6a11ad39c747aef4388695410f44fdd@localhost> #1132: Data.ByteString.Lazy.Char8's readInt does no bounds checking ----------------------------+----------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hslibs/data | Version: 6.6 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Multiple | Os: Multiple ----------------------------+----------------------------------------------- I think it should be failing with Nothing if given a string of digits that's too long. {{{~ $ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :m +Data.ByteString.Lazy.Char8 Prelude Data.ByteString.Lazy.Char8> readInt (pack "99999999999999999999") Just (7766279631452241919,LPS [])}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 5 00:50:17 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1132: Data.ByteString.Lazy.Char8's readInt does no bounds checking In-Reply-To: <071.f6a11ad39c747aef4388695410f44fdd@localhost> References: <071.f6a11ad39c747aef4388695410f44fdd@localhost> Message-ID: <080.a748e56692ca18cbb4c75e4192d432a9@localhost> #1132: Data.ByteString.Lazy.Char8's readInt does no bounds checking -------------------------+-------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hslibs/data | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Comment (by bos): Hmm, guess I can't use WikiFormatting after all. Sorry for the mess! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 5 00:57:41 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1132: Data.ByteString.Lazy.Char8's readInt does no bounds checking In-Reply-To: <071.f6a11ad39c747aef4388695410f44fdd@localhost> References: <071.f6a11ad39c747aef4388695410f44fdd@localhost> Message-ID: <080.4994ecb4898b4f73c7c375f6535cc51f@localhost> #1132: Data.ByteString.Lazy.Char8's readInt does no bounds checking -------------------------+-------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hslibs/data | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Comment (by bos): Don points out that this behaviour is consistent with that of read, so depending on your perspective, we have either one bug (in two places), two bugs, or no bugs :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 5 15:46:33 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #985: Memory Leak in freeHaskellFunPtr In-Reply-To: <071.9cb80b2e06bee3baa5c2661f50fb5b56@localhost> References: <071.9cb80b2e06bee3baa5c2661f50fb5b56@localhost> Message-ID: <080.f893b24ce9246164e280d160063bef0e@localhost> #985: Memory Leak in freeHaskellFunPtr ----------------------------------------------+----------------------------- Reporter: mattcbro@earthlink.net | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: callback, FFI, freeHaskellFunPtr | Difficulty: Unknown Testcase: provided | Architecture: Multiple Os: Windows | ----------------------------------------------+----------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 5 16:49:53 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1133: auto-derivation of Enum is disallowed with recursive imports Message-ID: <071.d5d73cdf8d0ef2e9bad73dace1fd9e1c@localhost> #1133: auto-derivation of Enum is disallowed with recursive imports -------------------------+-------------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- A data type with one single-parameter constructor can normally be declared deriving(Enum) when compiling with -fglasgow-exts. However, when the data type is also declared in a hs-boot file, this is not accepted. The following test case demonstrates the problem. The same thing happens if the 'deriving' clause is also present in the hs-boot file. {{{ {- file X.hs-boot -} module X where newtype X = X Int {- file X.hs -} module X where import {-# SOURCE #-} X newtype X = X Int deriving(Enum) }}} > ghc -c -fglasgow-exts X.hs-boot X.hs The error occurs in X.hs: {{{Can't make a derived instance of `Enum X' (`X' has non-nullary constructors)}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 04:52:01 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1134: swap minView/maxView return value Message-ID: <071.1d16a01fab839e0adc11599f4864434e@localhost> #1134: swap minView/maxView return value --------------------------------+------------------------------------------- Reporter: jpbernardy | Owner: jpbernardy Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.6 Severity: normal | Keywords: collections Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- New proposed types: Data.Set: minView,maxView:: Monad m => Set a -> m (a, Set a) Data.Map: minViewWithKey,maxViewWithKey :: Monad m => Map k a -> m ((k,a), Map k a) minView,maxView :: Monad m => Map k a -> m (a, Map k a) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 04:52:23 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1134: swap minView/maxView return value In-Reply-To: <071.1d16a01fab839e0adc11599f4864434e@localhost> References: <071.1d16a01fab839e0adc11599f4864434e@localhost> Message-ID: <080.002797dbfb8c3984e4f33fea6179708b@localhost> #1134: swap minView/maxView return value -----------------------------+---------------------------------------------- Reporter: jpbernardy | Owner: jpbernardy Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: collections | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Old description: > New proposed types: > > Data.Set: > minView,maxView:: Monad m => Set a -> m (a, Set a) > > Data.Map: > minViewWithKey,maxViewWithKey :: Monad m => Map k a -> m ((k,a), Map k a) > minView,maxView :: Monad m => Map k a -> m (a, Map k a) New description: New proposed types: Data.Set: minView,maxView:: Monad m => Set a -> m (a, Set a) Data.Map: minViewWithKey,maxViewWithKey :: Monad m => Map k a -> m ((k,a), Map k a) minView,maxView :: Monad m => Map k a -> m (a, Map k a) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 08:34:56 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1134: swap minView/maxView return value In-Reply-To: <071.1d16a01fab839e0adc11599f4864434e@localhost> References: <071.1d16a01fab839e0adc11599f4864434e@localhost> Message-ID: <080.6a29b40aa6f225f1f5879e474f735070@localhost> #1134: swap minView/maxView return value -----------------------------+---------------------------------------------- Reporter: jpbernardy | Owner: jpbernardy Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: collections | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Old description: > New proposed types: > > Data.Set: > > minView,maxView:: Monad m => Set a -> m (a, Set a) > > Data.Map: > > minViewWithKey,maxViewWithKey :: Monad m => Map k a -> m ((k,a), Map k a) > > minView,maxView :: Monad m => Map k a -> m (a, Map k a) New description: Some time ago (before ghc 6.6 / base 2.0 release), I introduced minView and maxView in Data.Set and Data.Map (at a user's request). I agreed with Robert Dockins to implement the same functionality as in his version of the Edison library. Unfortunately, I uselessly swapped the return values of minView and maxView, introducing a difference both with the corresponding functions in the edison library and similar functions in Data.Map/Set. I propose to restore the symmetry, at the cost of incompatibility. New proposed types: Data.Set: minView,maxView:: Monad m => Set a -> m (a, Set a) Data.Map: minViewWithKey,maxViewWithKey :: Monad m => Map k a -> m ((k,a), Map k a) minView,maxView :: Monad m => Map k a -> m (a, Map k a) The incompatibility is probably acceptable because the functions are still short-lived. relevant urls: http://www.eecs.tufts.edu/~rdocki01/docs/edison/Data-Edison- Coll.html#v%3AminView http://www.eecs.tufts.edu/~rdocki01/docs/edison/Data-Edison- Assoc.html#v%3AminView http://hackage.haskell.org/darcsweb/darcsweb.cgi?r=base;a=commit;h =20060616180121-9c550-c9530b7eab87ea834f826a7d5c531a5bbed22306.gz -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 09:46:03 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1134: swap minView/maxView return value In-Reply-To: <071.1d16a01fab839e0adc11599f4864434e@localhost> References: <071.1d16a01fab839e0adc11599f4864434e@localhost> Message-ID: <080.bf1b49133df2c918501593cfcbf6db72@localhost> #1134: swap minView/maxView return value ----------------------------+----------------------------------------------- Reporter: jpbernardy | Owner: jpbernardy Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: collections | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by jpbernardy): * milestone: 6.8 => 6.6.1 * type: feature request => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 10:10:15 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1135: HsTime.h isn't installed by the Windows installer Message-ID: <071.435aa8d1498796e4ea5be8ea0518c348@localhost> #1135: HsTime.h isn't installed by the Windows installer ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: libraries (other) | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- [I'm not sure if this is really a bug in the Windows installer maker or if it's a problem with building the library with ghc (rather than as a standalone cabal package). I can reproduce it on my Windows install, but not with the Debian packages] Alistair Bayley reports in http://www.haskell.org/pipermail/libraries /2007-February/006864.html If I try to compile this Main.hs: {{{ module Main where import Data.Time main = getCurrentTime >>= print }}} with this ghc-6.6 command: {{{ ghc --make Main -o test -O }}} ... I get this error: C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc728_0\ghc728_0.hc:8:20: HsTime.h: No such file or directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 10:20:40 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1135: HsTime.h isn't installed by the Windows installer In-Reply-To: <071.435aa8d1498796e4ea5be8ea0518c348@localhost> References: <071.435aa8d1498796e4ea5be8ea0518c348@localhost> Message-ID: <080.9db0bcbebd6c4f5e8bd69c2baba40f10@localhost> #1135: HsTime.h isn't installed by the Windows installer -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Old description: > [I'm not sure if this is really a bug in the Windows installer maker or > if it's a problem with building the library with ghc (rather than as a > standalone cabal package). I can reproduce it on my Windows install, but > not with the Debian packages] > > Alistair Bayley reports in http://www.haskell.org/pipermail/libraries > /2007-February/006864.html > > If I try to compile this Main.hs: > > {{{ > module Main where > import Data.Time > main = getCurrentTime >>= print > }}} > > with this ghc-6.6 command: > > {{{ > ghc --make Main -o test -O > }}} > > ... I get this error: > > C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc728_0\ghc728_0.hc:8:20: HsTime.h: > No such file or directory > }}} New description: [I'm not sure if this is really a bug in the Windows installer maker or if it's a problem with building the library with ghc (rather than as a standalone cabal package). I can reproduce it on my Windows install, but not with the Debian packages] Alistair Bayley reports in http://www.haskell.org/pipermail/libraries /2007-February/006864.html If I try to compile this Main.hs: {{{ module Main where import Data.Time main = getCurrentTime >>= print }}} with this ghc-6.6 command: {{{ ghc --make Main -o test -O }}} ... I get this error: {{{ C:\DOCUME~1\bayleya\LOCALS~1\Temp\ghc728_0\ghc728_0.hc:8:20: HsTime.h: No such file or directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 10:50:59 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1136: High memory use when compiling many let bindings. Message-ID: <071.00576b7274413ec93e4b4fdce2069a72@localhost> #1136: High memory use when compiling many let bindings. -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Two programs that generate modules with lots of let bindings that GHC struggles to compile. With the first, {{{ ghc -c J.hs }}} uses >100M of memory which seems a little high. For the second, {{{ ghc -c J2.hs }}} got past 700M before I killed it, with both 6.6 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 10:52:48 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1136: High memory use when compiling many let bindings. In-Reply-To: <071.00576b7274413ec93e4b4fdce2069a72@localhost> References: <071.00576b7274413ec93e4b4fdce2069a72@localhost> Message-ID: <080.f5c31d315982f7d0206b09a51bce44a0@localhost> #1136: High memory use when compiling many let bindings. ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): Forgot to mention: this is based on the report in http://www.haskell.org/pipermail/glasgow-haskell-users/2007- January/011866.html -- Ticket URL: GHC The Glasgow Haskell Compiler From maeder at tzi.de Tue Feb 6 11:17:07 2007 From: maeder at tzi.de (Christian Maeder) Date: Thu Jul 19 09:48:12 2007 Subject: trac-ticket/955 Message-ID: <45C8AA03.6080105@tzi.de> For some reason I cannot login using "guest" "guest" http://hackage.haskell.org/trac/ghc/ticket/955 I only want to suggest to change the milestone to 6.8. Although the code-bloat is not nice, we could live with it. Christian From trac at galois.com Tue Feb 6 11:59:12 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:12 2007 Subject: [GHC] #1128: The impossible happened, code commented In-Reply-To: <071.16c995f8b8783ff8266c59f1ba4f1c33@localhost> References: <071.16c995f8b8783ff8266c59f1ba4f1c33@localhost> Message-ID: <080.059bc570bce1b1b89c535961d04c9119@localhost> #1128: The impossible happened, code commented -----------------------+---------------------------------------------------- Reporter: humasect | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail174 | Architecture: Unknown Os: Unknown | -----------------------+---------------------------------------------------- Changes (by simonpj): * testcase: => tcfail174 * type: bug => merge Comment: This is a plain bug in the type checker. The program should clearly be rejected. I've fixed the bug. MERGE to 6.6.1 branch Tue Feb 6 16:54:56 GMT 2007 simonpj@microsoft.com * Check for escape when unifying forall-types Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 12:03:48 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1111: Too-eager variable capture in forall types In-Reply-To: <071.b27058ff01c5439876ea75b17ccd4ca5@localhost> References: <071.b27058ff01c5439876ea75b17ccd4ca5@localhost> Message-ID: <080.d40512bdd19c805e026e6ac66d812ed6@localhost> #1111: Too-eager variable capture in forall types -----------------------+---------------------------------------------------- Reporter: japple | Owner: simonpj Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail174 | Architecture: x86 Os: Linux | -----------------------+---------------------------------------------------- Changes (by simonpj): * testcase: => tcfail174 * type: bug => merge Comment: This is a plain bug in the type checker. The program should clearly be rejected. I've fixed the bug. MERGE to 6.6.1 branch Tue Feb 6 16:54:56 GMT 2007 simonpj@microsoft.com Check for escape when unifying forall-types Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 12:04:32 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1128: The impossible happened, code commented In-Reply-To: <071.16c995f8b8783ff8266c59f1ba4f1c33@localhost> References: <071.16c995f8b8783ff8266c59f1ba4f1c33@localhost> Message-ID: <080.44a68228d9bbaf4ca3bb28ebaf8812cd@localhost> #1128: The impossible happened, code commented ----------------------+----------------------------------------------------- Reporter: humasect | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * testcase: tcfail174 => * type: merge => bug Comment: Bother. IGNORE my last comment; it was intended for a different bug entirely. Sorry. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 12:16:19 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1128: The impossible happened, code commented In-Reply-To: <071.16c995f8b8783ff8266c59f1ba4f1c33@localhost> References: <071.16c995f8b8783ff8266c59f1ba4f1c33@localhost> Message-ID: <080.20cf569b110fbd1b029cf14c7a207863@localhost> #1128: The impossible happened, code commented ----------------------+----------------------------------------------------- Reporter: humasect | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): I've just compiled the file you sent (on Unix) with GHC 6.6, thus: {{{ ghc --make -fno-implicit-prelude Level.hs }}} It worked fine. Can you help us reproduce this? Send the exact command line, and output you get. Pls start from a clean directory with precisely the download that you attached to this bug report. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 12:27:50 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1133: auto-derivation of Enum is disallowed with recursive imports In-Reply-To: <071.d5d73cdf8d0ef2e9bad73dace1fd9e1c@localhost> References: <071.d5d73cdf8d0ef2e9bad73dace1fd9e1c@localhost> Message-ID: <080.cb58e9c0bdb813ac7e42cdd282f4ed69@localhost> #1133: auto-derivation of Enum is disallowed with recursive imports ----------------------+----------------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): Are you sure you are using -fglasgow-exts. I have just compiled your example with GHC 6.6, thus {{{ bash-3.1$ ghc -c -fglasgow-exts X.hs-boot X.hs bash-3.1$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 bash-3.1$ }}} And all is happy. Without -fglasgow-exts it fails, because in Haskell 98 you can't derive Enum for a newtype. Can you double check your test case and send and exact log of what happened? Remove all .o and .hi and .hi-boot files first. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 12:31:42 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1117: [2,4..10] is not a good list producer In-Reply-To: <071.ec0008f25013e3092a264c2cfa24a151@localhost> References: <071.ec0008f25013e3092a264c2cfa24a151@localhost> Message-ID: <080.cbdc86c0f2bee7b02fd3746e1870d126@localhost> #1117: [2,4..10] is not a good list producer ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: rewrite rules | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * milestone: 6.6.1 => 6.8 * priority: low => lowest Comment: Good data. Duncan Coutts and Roman Leshchinskiy are planning to work on list fusion in the next month or two. Since that will change GHC's list libraries a lot, it'd be a bit of waste to fix the current libraries. So I propose to leave this. I'll make its priority low, but leave it open. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 12:46:36 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1118: Type check loop on impredicativaty + GADT mix In-Reply-To: <071.86d61db216b306e740ea59c53a960be2@localhost> References: <071.86d61db216b306e740ea59c53a960be2@localhost> Message-ID: <080.00edc832f1be9252893c1a29fafae4ea@localhost> #1118: Type check loop on impredicativaty + GADT mix ------------------------------------+--------------------------------------- Reporter: japple | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: impredicativity, GADTs | Difficulty: Unknown Testcase: boxy/Compose | Architecture: x86 Os: Linux | ------------------------------------+--------------------------------------- Changes (by simonpj): * resolution: => fixed * testcase: => boxy/Compose * status: new => closed Comment: Jim, this seems to be OK in the HEAD, and also on the 6.6 branch, but it's certainly broken in 6.6 itself. Ideally I should track down exactly which patch fixed it, but that's a bit time consuming, so I propose simply to regard it as "already fixed". Meanwhile I'll add it to the test suite, so we'll find out if it goes bad again. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 6 18:59:25 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1134: swap minView/maxView return value In-Reply-To: <071.1d16a01fab839e0adc11599f4864434e@localhost> References: <071.1d16a01fab839e0adc11599f4864434e@localhost> Message-ID: <080.7b1d4c448e11924bf8961a4cf6eb0ea2@localhost> #1134: swap minView/maxView return value ----------------------------+----------------------------------------------- Reporter: jpbernardy | Owner: jpbernardy Type: proposal | Status: new Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: collections | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: 6.6.1 => 6.8 * type: bug => proposal Comment: Unfortunately fixing this for 6.6.1 would mean changing the interface, which we don't allow within a stable branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From simonmarhaskell at gmail.com Wed Feb 7 04:35:42 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jul 19 09:48:13 2007 Subject: trac-ticket/955 In-Reply-To: <45C8AA03.6080105@tzi.de> References: <45C8AA03.6080105@tzi.de> Message-ID: <45C99D6E.5030503@gmail.com> Christian Maeder wrote: > For some reason I cannot login using "guest" "guest" > > http://hackage.haskell.org/trac/ghc/ticket/955 > > I only want to suggest to change the milestone to 6.8. > > Although the code-bloat is not nice, we could live with it. Somebody changed the password for guest again. I must figure out how to disable that. Cheers, Simon From trac at galois.com Wed Feb 7 05:04:47 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1025: -ddump-minimal-imports works wrongly In-Reply-To: <071.7c52338398d65e6db9feefd21314034e@localhost> References: <071.7c52338398d65e6db9feefd21314034e@localhost> Message-ID: <080.71f5246eda2319cfc8cc6b57010a8904@localhost> #1025: -ddump-minimal-imports works wrongly ---------------------------+------------------------------------------------ Reporter: maeder@tzi.de | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Changes (by simonpj): * resolution: => fixed * status: new => closed * type: bug => merge Comment: Excellent. I was able to reproduce this nicely, thank you. It was a silly bug in the -ddump-minimal-imports code. Thanks for the report and repo case. I'm not adding a test case because the test is a bit elaborate: build a package and then use it. MERGE to stable. Wed Feb 7 10:02:45 GMT 2007 simonpj@microsoft.com * Force recompilation on all -ddump flags Wed Feb 7 10:00:53 GMT 2007 simonpj@microsoft.com * Force recompilation with -ddump-minimal-imports Wed Feb 7 09:49:45 GMT 2007 simonpj@microsoft.com * Fix bug in -ddump-minimal imports Trac #1025 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 7 05:07:00 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1111: Too-eager variable capture in forall types In-Reply-To: <071.b27058ff01c5439876ea75b17ccd4ca5@localhost> References: <071.b27058ff01c5439876ea75b17ccd4ca5@localhost> Message-ID: <080.113428b119918851e08c4f77a55f0ae7@localhost> #1111: Too-eager variable capture in forall types -----------------------+---------------------------------------------------- Reporter: japple | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail174 | Architecture: x86 Os: Linux | -----------------------+---------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 7 05:08:24 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1025: -ddump-minimal-imports works wrongly In-Reply-To: <071.7c52338398d65e6db9feefd21314034e@localhost> References: <071.7c52338398d65e6db9feefd21314034e@localhost> Message-ID: <080.a150da2ec647a0b0debd9f7d524dd0cf@localhost> #1025: -ddump-minimal-imports works wrongly ---------------------------+------------------------------------------------ Reporter: maeder@tzi.de | Owner: Type: merge | Status: reopened Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Changes (by simonpj): * resolution: fixed => * status: closed => reopened -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 7 05:08:36 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1025: -ddump-minimal-imports works wrongly In-Reply-To: <071.7c52338398d65e6db9feefd21314034e@localhost> References: <071.7c52338398d65e6db9feefd21314034e@localhost> Message-ID: <080.3506e8713c43067ac0bc2b6b6a11e89c@localhost> #1025: -ddump-minimal-imports works wrongly ---------------------------+------------------------------------------------ Reporter: maeder@tzi.de | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Changes (by simonpj): * status: reopened => new * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 7 07:49:46 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <071.25651608723872130592de111f1185a9@localhost> References: <071.25651608723872130592de111f1185a9@localhost> Message-ID: <080.0caadf3e0def3e8e79251b6c25f38110@localhost> #955: more object-code blow-up in ghc-6.6 vs. ghc-6.4.2 (both with optimization) ---------------------------------+------------------------------------------ Reporter: maeder@tzi.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: 6.6.1 => 6.8 Comment: Christian says "[...] suggest to change the milestone to 6.8. Although the code-bloat is not nice, we could live with it." -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 7 09:07:38 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1025: -ddump-minimal-imports works wrongly In-Reply-To: <071.7c52338398d65e6db9feefd21314034e@localhost> References: <071.7c52338398d65e6db9feefd21314034e@localhost> Message-ID: <080.e614dd0eaeaa1c834a8f7760a040acaa@localhost> #1025: -ddump-minimal-imports works wrongly ---------------------------+------------------------------------------------ Reporter: maeder@tzi.de | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 7 09:07:44 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1111: Too-eager variable capture in forall types In-Reply-To: <071.b27058ff01c5439876ea75b17ccd4ca5@localhost> References: <071.b27058ff01c5439876ea75b17ccd4ca5@localhost> Message-ID: <080.3fd4b89a7b2b8157c32a53e521a845af@localhost> #1111: Too-eager variable capture in forall types -----------------------+---------------------------------------------------- Reporter: japple | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tcfail174 | Architecture: x86 Os: Linux | -----------------------+---------------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 8 17:45:06 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #998: Tab-completion of filenames does not work in GHCi 6.6 In-Reply-To: <071.6210fcc1137fd53f42bfc89f0aabacc7@localhost> References: <071.6210fcc1137fd53f42bfc89f0aabacc7@localhost> Message-ID: <080.c1e6ba7b00287d4fc3bc639fa35948f9@localhost> #998: Tab-completion of filenames does not work in GHCi 6.6 ------------------------------------+--------------------------------------- Reporter: dm.maillists@gmail.com | Owner: judahj Type: bug | Status: new Priority: low | Milestone: 6.8 Component: GHCi | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ------------------------------------+--------------------------------------- Changes (by judahj): * milestone: 6.6.1 => 6.8 Comment: This is the problem: Since ghci now expands Haskell names, it tells readline that several extra symbols (such as '+', '-' or '/') are word boundaries; thus tabbing after "foo+len" expands "len" to "length". However, tabbing after ":l folder/file" tries to expand just "file" instead of the full path "folder/file", since readline now thinks that "/" is a word boundary. As a workaround, you can add the following 3 lines to your .ghci file, removing '/' from the list of word boundaries: {{{ :m +System.Console.Readline Data.List getCompleterWordBreakCharacters >>= setCompleterWordBreakCharacters . delete '/' :m -System.Console.Readline Data.List }}} The fix is for ghci to use rl_completion_word_break_hook from the readline library, which lets it change the set of word break characters based on the context of the line. However, that hook isn't currently exported from System.Console.Readline, so this would also require a patch to the readline package. Thus, I'm punting the fix to 6.8; we can use the above workaround in the meantime. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 9 12:03:42 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1137: HashTable.hashString broken Message-ID: <071.05fd84222ae7542c096fdb8fedad2015@localhost> #1137: HashTable.hashString broken ---------------------------------------+------------------------------------ Reporter: j.russell@alum.mit.edu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: x86 | Os: Linux ---------------------------------------+------------------------------------ The output of HashTable.hashString is seriously broken in GHC 6.6. Here is a sample of the output with some strings zipped with their hash values: [(97,"a"),(59,"ba"),(74,"cba"),(69,"dcab"),(73,"edbac"),(72,"fecabd"),(73,"gfdbace"),(74,"hgecabdf"),(75,"ihfdbaceg"),(75,"jigecabdfh"),(76,"kjhfdbacegi"),(77,"lkigecabdfhj"),(77,"mljhfdbacegik"),(78,"nmkigecabdfhjl"),(79,"onljhfdbacegikm"),(80,"pomkigecabdfhjln"),(80,"qpnljhfdbacegikmo"),(81,"rqomkigecabdfhjlnp"),(82,"srpnljhfdbacegikmoq"),(83,"tsqomkigecabdfhjlnpr"),(83,"utrpnljhfdbacegikmoqs"),(84,"vusqomkigecabdfhjlnprt"),(85,"wvtrpnljhfdbacegikmoqsu"),(85,"xwusqomkigecabdfhjlnprtv"),(86,"yxvtrpnljhfdbacegikmoqsuw"),(87,"zywusqomkigecabdfhjlnprtvx")] The output from GHC 6.4.2, for comparison: [(97,"a"),(12641,"ba"),(134650,"cba"),(1348750,"dcab"),(686898,"edbac"),(531877,"fecabd"),(659882,"gfdbace"),(781094,"hgecabdf"),(924023,"ihfdbaceg"),(85405,"jigecabdfh"),(306085,"kjhfdbacegi"),(1152971,"lkigecabdfhj"),(1259361,"mljhfdbacegik"),(1179474,"nmkigecabdfhjl"),(489548,"onljhfdbacegikm"),(231688,"pomkigecabdfhjln"),(805762,"qpnljhfdbacegikmo"),(26414,"rqomkigecabdfhjlnp"),(1005367,"srpnljhfdbacegikmoq"),(394080,"tsqomkigecabdfhjlnpr"),(1010834,"utrpnljhfdbacegikmoqs"),(1178465,"vusqomkigecabdfhjlnprt"),(421802,"wvtrpnljhfdbacegikmoqsu"),(263363,"xwusqomkigecabdfhjlnprtv"),(1417299,"yxvtrpnljhfdbacegikmoqsuw"),(675868,"zywusqomkigecabdfhjlnprtvx")] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Feb 9 12:38:53 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1115: GHC concurrency runtime "breaks" every 497 (and a bit) days In-Reply-To: <071.66906655ac7f12c4161eae4010a5d2fe@localhost> References: <071.66906655ac7f12c4161eae4010a5d2fe@localhost> Message-ID: <080.98c7ae507da06adecba04180bbbfa74e@localhost> #1115: GHC concurrency runtime "breaks" every 497 (and a bit) days ----------------------------+----------------------------------------------- Reporter: Neil Davies | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.6 Severity: major | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: I've applied this patch, and another that does the same for Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 10 00:24:05 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1138: The -fexcess-precision flag is ignored if supplied on the command line. Message-ID: <071.cf63259a36ad2b8981af65aece60734f@localhost> #1138: The -fexcess-precision flag is ignored if supplied on the command line. ----------------------------+----------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.6 Severity: normal | Keywords: numerics, excess-precision Difficulty: Easy (1 hr) | Testcase: Architecture: x86 | Os: Unknown ----------------------------+----------------------------------------------- The numerics/Double-based programs on the great language shootout were performing poorly. Investigations revealed that the -fexcess-precision flag was being silently ignored by GHC when supplied as a command line flag. If it is supplied as a {-# OPTIONS -fexcess-precision #-} pragma, it is respected. Consider the following shootout entry for the 'mandelbrot' benchmark. It writes the mandelbrot set as bmp format to stdout. {{{ import System import System.IO import Foreign import Foreign.Marshal.Array main = do w <- getArgs >>= readIO . head let n = w `div` 8 m = 2 / fromIntegral w putStrLn ("P4\n"++show w++" "++show w) p <- mallocArray0 n unfold n (next_x w m n) p (T 1 0 0 (-1)) unfold :: Int -> (T -> Maybe (Word8,T)) -> Ptr Word8 -> T -> IO () unfold !i !f !ptr !x0 = loop x0 where loop !x = go ptr 0 x go !p !n !x = case f x of Just (w,y) | n /= i -> poke p w >> go (p `plusPtr` 1) (n+1) y Nothing -> hPutBuf stdout ptr i _ -> hPutBuf stdout ptr i >> loop x {-# NOINLINE unfold #-} data T = T !Int !Int !Int !Double next_x !w !iw !bw (T bx x y ci) | y == w = Nothing | bx == bw = Just (loop_x w x 8 iw ci 0, T 1 0 (y+1) (iw+ci)) | otherwise = Just (loop_x w x 8 iw ci 0, T (bx+1) (x+8) y ci) loop_x !w !x !n !iw !ci !b | x < w = if n == 0 then b else loop_x w (x+1) (n-1) iw ci (b+b+v) | otherwise = b `shiftL` n where v = fractal 0 0 (fromIntegral x * iw - 1.5) ci 50 fractal :: Double -> Double -> Double -> Double -> Int -> Word8 fractal !r !i !cr !ci !k | r2 + i2 > 4 = 0 | k == 0 = 1 | otherwise = fractal (r2-i2+cr) ((r+r)*i+ci) cr ci (k-1) where (!r2,!i2) = (r*r,i*i) }}} We can compile and run this as follows: {{{ $ ghc -O -fglasgow-exts -optc-march=pentium4 -fbang-patterns -funbox- strict-fields -optc-O2 -optc-mfpmath=sse -optc-msse2 -fexcess-precision -o m1 mandel3.hs -no-recomp $ time ./m1 3000 > /dev/null ./m1 3000 > /dev/null 8.12s user 0.00s system 99% cpu 8.143 total }}} 8s is around 3x the speed of C (or worse). now, if we add the following pragma to the top of the file: {{{ {-# OPTIONS -fexcess-precision #-} }}} and recompile and rerun: {{{ $ ghc -O -fglasgow-exts -optc-march=pentium4 -fbang-patterns -funbox- strict-fields -optc-O2 -optc-mfpmath=sse -optc-msse2 -fexcess-precision -o m1 mandel3.hs -no-recomp $ time ./m1 3000 > /dev/null ./m1 3000 > /dev/null 2.94s user 0.00s system 99% cpu 2.945 total }}} Nearly 3x faster, and competitive with C. Across the board the -fexcess-precision flag seems to be ignored by GHC, affecting all Double-based entries on the shootout. A diff on the ghc -v3 output shows that -ffloat-store is not being passed to GCC when -fexcess-precision is supplied on the command line. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 10 10:52:35 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1138: The -fexcess-precision flag is ignored if supplied on the command line. In-Reply-To: <071.cf63259a36ad2b8981af65aece60734f@localhost> References: <071.cf63259a36ad2b8981af65aece60734f@localhost> Message-ID: <080.2c1f0312de102f99fe00c000680455cf@localhost> #1138: The -fexcess-precision flag is ignored if supplied on the command line. ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: numerics, excess-precision | Difficulty: Easy (1 hr) Testcase: | Architecture: x86 Os: Unknown | ----------------------------------------+----------------------------------- Old description: > The numerics/Double-based programs on the great language shootout were > performing poorly. Investigations revealed that the -fexcess-precision > flag was being silently ignored by GHC when supplied as a command line > flag. If it is supplied as a {-# OPTIONS -fexcess-precision #-} pragma, > it is respected. > > Consider the following shootout entry for the 'mandelbrot' benchmark. It > writes the mandelbrot set as bmp format to stdout. > > {{{ > import System > import System.IO > import Foreign > import Foreign.Marshal.Array > > main = do > w <- getArgs >>= readIO . head > let n = w `div` 8 > m = 2 / fromIntegral w > putStrLn ("P4\n"++show w++" "++show w) > p <- mallocArray0 n > unfold n (next_x w m n) p (T 1 0 0 (-1)) > > unfold :: Int -> (T -> Maybe (Word8,T)) -> Ptr Word8 -> T -> IO () > unfold !i !f !ptr !x0 = loop x0 > where > loop !x = go ptr 0 x > > go !p !n !x = case f x of > Just (w,y) | n /= i -> poke p w >> go (p `plusPtr` 1) (n+1) y > Nothing -> hPutBuf stdout ptr i > _ -> hPutBuf stdout ptr i >> loop x > {-# NOINLINE unfold #-} > > data T = T !Int !Int !Int !Double > > next_x !w !iw !bw (T bx x y ci) > | y == w = Nothing > | bx == bw = Just (loop_x w x 8 iw ci 0, T 1 0 (y+1) (iw+ci)) > | otherwise = Just (loop_x w x 8 iw ci 0, T (bx+1) (x+8) y ci) > > loop_x !w !x !n !iw !ci !b > | x < w = if n == 0 > then b > else loop_x w (x+1) (n-1) iw ci (b+b+v) > | otherwise = b `shiftL` n > where > v = fractal 0 0 (fromIntegral x * iw - 1.5) ci 50 > > fractal :: Double -> Double -> Double -> Double -> Int -> Word8 > fractal !r !i !cr !ci !k > | r2 + i2 > 4 = 0 > | k == 0 = 1 > | otherwise = fractal (r2-i2+cr) ((r+r)*i+ci) cr ci (k-1) > where > (!r2,!i2) = (r*r,i*i) > }}} > > We can compile and run this as follows: > > {{{ > $ ghc -O -fglasgow-exts -optc-march=pentium4 -fbang-patterns -funbox- > strict-fields -optc-O2 -optc-mfpmath=sse -optc-msse2 -fexcess-precision > -o m1 mandel3.hs -no-recomp > > $ time ./m1 3000 > /dev/null > ./m1 3000 > /dev/null 8.12s user 0.00s system 99% cpu 8.143 total > }}} > > 8s is around 3x the speed of C (or worse). > > now, if we add the following pragma to the top of the file: > > {{{ > {-# OPTIONS -fexcess-precision #-} > }}} > > and recompile and rerun: > > {{{ > $ ghc -O -fglasgow-exts -optc-march=pentium4 -fbang-patterns -funbox- > strict-fields -optc-O2 -optc-mfpmath=sse -optc-msse2 -fexcess-precision > -o m1 mandel3.hs -no-recomp > > $ time ./m1 3000 > /dev/null > ./m1 3000 > /dev/null 2.94s user 0.00s system 99% cpu 2.945 total > }}} > > Nearly 3x faster, and competitive with C. > > Across the board the -fexcess-precision flag seems to be ignored by GHC, > affecting all Double-based entries on the shootout. > > A diff on the ghc -v3 output shows that -ffloat-store is not being passed > to GCC when -fexcess-precision is supplied on the command line. New description: The numerics/Double-based programs on the great language shootout were performing poorly. Investigations revealed that the -fexcess-precision flag was being silently ignored by GHC when supplied as a command line flag. If it is supplied as a {-# OPTIONS -fexcess-precision #-} pragma, it is respected. Consider the following shootout entry for the 'mandelbrot' benchmark. It writes the mandelbrot set as bmp format to stdout. {{{ import System import System.IO import Foreign import Foreign.Marshal.Array main = do w <- getArgs >>= readIO . head let n = w `div` 8 m = 2 / fromIntegral w putStrLn ("P4\n"++show w++" "++show w) p <- mallocArray0 n unfold n (next_x w m n) p (T 1 0 0 (-1)) unfold :: Int -> (T -> Maybe (Word8,T)) -> Ptr Word8 -> T -> IO () unfold !i !f !ptr !x0 = loop x0 where loop !x = go ptr 0 x go !p !n !x = case f x of Just (w,y) | n /= i -> poke p w >> go (p `plusPtr` 1) (n+1) y Nothing -> hPutBuf stdout ptr i _ -> hPutBuf stdout ptr i >> loop x {-# NOINLINE unfold #-} data T = T !Int !Int !Int !Double next_x !w !iw !bw (T bx x y ci) | y == w = Nothing | bx == bw = Just (loop_x w x 8 iw ci 0, T 1 0 (y+1) (iw+ci)) | otherwise = Just (loop_x w x 8 iw ci 0, T (bx+1) (x+8) y ci) loop_x !w !x !n !iw !ci !b | x < w = if n == 0 then b else loop_x w (x+1) (n-1) iw ci (b+b+v) | otherwise = b `shiftL` n where v = fractal 0 0 (fromIntegral x * iw - 1.5) ci 50 fractal :: Double -> Double -> Double -> Double -> Int -> Word8 fractal !r !i !cr !ci !k | r2 + i2 > 4 = 0 | k == 0 = 1 | otherwise = fractal (r2-i2+cr) ((r+r)*i+ci) cr ci (k-1) where (!r2,!i2) = (r*r,i*i) }}} We can compile and run this as follows: {{{ $ ghc -O -fglasgow-exts -optc-march=pentium4 -fbang-patterns -funbox- strict-fields -optc-O2 -optc-mfpmath=sse -optc-msse2 -fexcess-precision -o m1 mandel3.hs -no-recomp $ time ./m1 3000 > /dev/null ./m1 3000 > /dev/null 8.12s user 0.00s system 99% cpu 8.143 total }}} 8s is around 3x the speed of C (or worse). now, if we add the following pragma to the top of the file: {{{ {-# OPTIONS -fexcess-precision #-} }}} and recompile and rerun: {{{ $ ghc -O -fglasgow-exts -optc-march=pentium4 -fbang-patterns -funbox- strict-fields -optc-O2 -optc-mfpmath=sse -optc-msse2 -fexcess-precision -o m1 mandel3.hs -no-recomp $ time ./m1 3000 > /dev/null ./m1 3000 > /dev/null 2.94s user 0.00s system 99% cpu 2.945 total }}} Nearly 3x faster, and competitive with C. Across the board the -fexcess-precision flag seems to be ignored by GHC, affecting all Double-based entries on the shootout. A diff on the ghc -v3 output shows that -ffloat-store is not being passed to GCC when -fexcess-precision is supplied on the command line. Comment (by dons): A smaller example: {{{ import Text.Printf main = go (1/3) 3 1 go :: Double -> Double -> Int -> IO () go !x !y !i | i == 100000000 = printf "%f\n" (x+y) | otherwise = go (x*y/3) (x*9) (i+1) }}} This program, run with the following flags: {{{ $ ghc -O -fexcess-precision -fbang-patterns -optc-O -optc-ffast-math -optc-mfpmath=sse -optc-msse2 A.hs -o a }}} Runs in: {{{ $ time ./a 3.3333333333333335 ./a 4.23s user 0.01s system 97% cpu 4.350 total }}} If we then move -fexcess-precision into the file, as a pragma: {{{ $ time ./a 3.3333333333333335 ./a 0.91s user 0.00s system 99% cpu 0.908 total }}} Note that asking GCC to generate sse instructions makes a 10% or better improvment too. For reference, this C program: {{{ #include int main() { double x = 1.0/3.0; double y = 3.0; int i = 1; for (; i<=100000000; i++) { x = x*y/3.0; y = x*9.0; } printf("%f\n", x+y); return 0; } }}} {{{ $ gcc -O3 -ffast-math -mfpmath=sse -msse2 t.c -o a.out -std=c99 $ time ./a.out 3.333333 ./a.out 1.00s user 0.00s system 98% cpu 1.012 total }}} Which is pretty nice for GHC :-) But now I wonder, how much of the bad numerics press has been soley due to -fexcess-precision being ignored? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 10 10:57:10 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1138: The -fexcess-precision flag is ignored if supplied on the command line. In-Reply-To: <071.cf63259a36ad2b8981af65aece60734f@localhost> References: <071.cf63259a36ad2b8981af65aece60734f@localhost> Message-ID: <080.51dcfa20e23da8d29422e5af384d6280@localhost> #1138: The -fexcess-precision flag is ignored if supplied on the command line. ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: numerics, excess-precision | Difficulty: Easy (1 hr) Testcase: | Architecture: x86 Os: Unknown | ----------------------------------------+----------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Feb 10 11:13:03 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1138: The -fexcess-precision flag is ignored if supplied on the command line. In-Reply-To: <071.cf63259a36ad2b8981af65aece60734f@localhost> References: <071.cf63259a36ad2b8981af65aece60734f@localhost> Message-ID: <080.f036758422b19ae688a700a98541de37@localhost> #1138: The -fexcess-precision flag is ignored if supplied on the command line. ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: numerics, excess-precision | Difficulty: Easy (1 hr) Testcase: | Architecture: x86 Os: Unknown | ----------------------------------------+----------------------------------- Comment (by dons): By the way, here's the Core loop for the above 'go' function that seems to consistently beat gcc: {{{ Main_zdwgo_info: .text movl 16(%ebp), %eax cmpl $1000000000, %eax jne .L7 movl $r1s7_closure, %esi addl $20, %ebp movl (%ebp), %eax .L8: jmp *%eax .L7: incl %eax movsd .LC2, %xmm0 movsd (%ebp), %xmm1 mulsd %xmm0, %xmm1 movsd 8(%ebp), %xmm0 mulsd (%ebp), %xmm0 mulsd .LC1, %xmm0 movl %eax, 16(%ebp) movsd %xmm1, 8(%ebp) movsd %xmm0, (%ebp) movl $Main_zdwgo_info, %eax jmp .L8 }}} Even with the indirect jump! -- Ticket URL: GHC The Glasgow Haskell Compiler From unsilicon at nm.ru Sat Feb 10 14:54:31 2007 From: unsilicon at nm.ru (unsilicon@nm.ru) Date: Thu Jul 19 09:48:13 2007 Subject: [Visual Haskell 0.2] Installation to a directory other than standard fails Message-ID: <20070210195431.4054.qmail@flock1.newmail.ru> Hello all. Attempt to install Visual Haskell 0.2 for VS2005 to a directory other than standard ?c:\Program Files\Visual Haskell? failed because some of the files were installed to a correct (specified in installer) location and some other still went to ?c:\Program Files\Visual Haskell? and installation script failed to register the Visual Haskell plugin into Visual Studio. Please, fix this. From trac at galois.com Sat Feb 10 19:51:59 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1139: Error when running ghci in emacs buffer Message-ID: <071.15d98cfbc9e648f27d65fd4a8b6d78ac@localhost> #1139: Error when running ghci in emacs buffer ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: x86 | Os: Windows ------------------------+--------------------------------------------------- I'm running ghci inside of an emacs buffer. I was trying to load the Control.Monad.Identity module into ghci and encountered this. Prelude> :add Control.Monad.Identity : module `Control.Monad.Identity' is a package module Failed, modules loaded: none. Prelude> import Control.Monad.Identity :1:0: parse error on input `import' Prelude> :show modules : panic! (the 'impossible' happened) (GHC version 6.6 for i386-unknown-mingw32): missing linkable 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 11 08:02:42 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1140: Use ccall for OpenAL on Windows (was part of #918) Message-ID: <071.31c95cb1c461f5596260f40271545aa8@localhost> #1140: Use ccall for OpenAL on Windows (was part of #918) ----------------------------------+----------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.4.2 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: N/A Architecture: Unknown | Os: MacOS X ----------------------------------+----------------------------------------- The patch attached to this ticket is part of a patch originally attached to #918 by shelarcy . This original patch (file {{{openal-mac-os-x.patch}}}) corrected a Mac OS X OpenAL build problem and a Windows OpenAL build problem. The part of the patch attached here is the part that corrects a Windows OpenAL build problem. The file name ({{{openal-mac-os-x-part-2.patch}}}) contains the name of the original patch, but it is a Windows-related patch in spite of its name. Please refer to #918 for additional details. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 11 08:18:30 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #918: Fix HOpenAL's configure.ac bug that can't find OpenAL framework under Mac OS X In-Reply-To: <071.8c3d248a9dd983bcc7eb685ed6474b3a@localhost> References: <071.8c3d248a9dd983bcc7eb685ed6474b3a@localhost> Message-ID: <080.7773c7500bcea1662de188ba2b5429f6@localhost> #918: Fix HOpenAL's configure.ac bug that can't find OpenAL framework under Mac OS X -------------------------------+-------------------------------------------- Reporter: guest | Owner: thorkilnaur Type: task | Status: new Priority: normal | Milestone: 6.6.1 Component: libraries (other) | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: N/A | Architecture: Unknown Os: MacOS X | -------------------------------+-------------------------------------------- Comment (by thorkilnaur): Since I am unable to test the Windows part of this patch, I have split off the Windows-related part of the patch and attached it to a new ticket: #1140. The Mac OS X-related part of the patch (attached file openal-mac- os-x-part-1.patch) has been tested with success on a PPC Mac OS X 10.4. The difference in the configure output before and after applying the patch is summarized here: {{{ 829a830,832 > checking build system type... powerpc-apple-darwin8.6.0 > checking host system type... powerpc-apple-darwin8.6.0 > checking target system type... powerpc-apple-darwin8.6.0 839,840c842,985 < checking for library containing alGenSources... no < configure: WARNING: no OpenAL library found, so this package will not be built --- > checking how to run the C preprocessor... gcc -E ... > checking value of ALC_CAPTURE_SAMPLES... 786 845d989 < config.status: include/HsOpenALConfig.h is unchanged 847d990 < config.status: include/HsOpenAL.h is unchanged }}} The patch has also been tested on a (SuSE) Linux system to ensure that OpenAL is still detected. For Linux, the difference between the configure output before and after applying the patch is less marked, as we would expect: {{{ 834a835,837 > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu 983d985 < config.status: include/HsOpenALConfig.h is unchanged 985d986 < config.status: include/HsOpenAL.h is unchanged }}} I should stress that the above test has only served to ensure that OpenAL after the change is detected and that the OpenAL package is then being built. The functions of the OpenAL package have not been tested. Based on this, I recommend that the attached patch openal-mac- os-x-part-1.patch is applied and the ticket closed. Ian, please ...? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 11 08:23:07 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #918: Fix HOpenAL's configure.ac bug that can't find OpenAL framework under Mac OS X In-Reply-To: <071.8c3d248a9dd983bcc7eb685ed6474b3a@localhost> References: <071.8c3d248a9dd983bcc7eb685ed6474b3a@localhost> Message-ID: <080.5570da8bc8204a39b17dfdf313ff0025@localhost> #918: Fix HOpenAL's configure.ac bug that can't find OpenAL framework under Mac OS X -------------------------------+-------------------------------------------- Reporter: guest | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.6.1 Component: libraries (other) | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: N/A | Architecture: Unknown Os: MacOS X | -------------------------------+-------------------------------------------- Changes (by thorkilnaur): * owner: thorkilnaur => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 11 13:17:31 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1007: Add parsing (and some more) to the time package In-Reply-To: <071.c8021700cf20c7d6896023727b6801a8@localhost> References: <071.c8021700cf20c7d6896023727b6801a8@localhost> Message-ID: <080.122925b6cae2b0c217c8341a4a10b9d9@localhost> #1007: Add parsing (and some more) to the time package -------------------------------------+-------------------------------------- Reporter: bringert@cs.chalmers.se | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by bringert): Almost all of the proposed changes are now implemented. These are still unimplemented: * Add Eq and Ord instances for ZonedTime. * Add Typeable and Data instances for all the time package types. * toJulianYearAndDay and isJulianLeapYear -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 11 18:52:39 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1141: Add extra completion functionality to readline package Message-ID: <071.a2507923a7638641f22a977a9e0556e0@localhost> #1141: Add extra completion functionality to readline package ----------------------------------+----------------------------------------- Reporter: judahj | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- I propose adding a few functions having to do with readline word completion: The rl_completion_word_break_hook variable lets us control what characters readline considers as word boundaries during completion. This function was added in readline version 5.0; we should not include this hook when compiling against earlier versions of the library. Additionally, we should allow get/set of the rl_attempted_completion_over variable. If this variable is nonzero, readline won't use its default completer when our custom completer returns no results. These will be used to fix ghc bug #998. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 11 21:08:31 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1142: Access denied to Snapshot distributions Message-ID: <071.6c9354ff8e1c7975a4156e4bea6e640f@localhost> #1142: Access denied to Snapshot distributions -------------------------------------------+-------------------------------- Reporter: ken.takusagawa.2@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------------------+-------------------------------- I get "403 Forbidden" when I try to download [http://www.haskell.org/ghc/dist/current/dist/ghc-6.7.20070208-src- extralibs.tar.bz2] The problem occurs for other files in that directory, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Feb 11 23:39:35 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1143: prettyprint case alternatives get pushed too far to the right Message-ID: <071.f59a959e7eba930cacbcfd0cd187505d@localhost> #1143: prettyprint case alternatives get pushed too far to the right -------------------------------------------+-------------------------------- Reporter: ken.takusagawa.2@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hslibs/hssource | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------------------+-------------------------------- I've been trying to make case statements, or more specifically HsGuardedAlts not get pushed way far to the right when the pattern (HsPat) is long (wide). I've had good results with the attached patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 12 03:50:36 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #998: Tab-completion of filenames does not work in GHCi 6.6 In-Reply-To: <071.6210fcc1137fd53f42bfc89f0aabacc7@localhost> References: <071.6210fcc1137fd53f42bfc89f0aabacc7@localhost> Message-ID: <080.0e61563fe0992fbf5de38beef60b3e72@localhost> #998: Tab-completion of filenames does not work in GHCi 6.6 ------------------------------------+--------------------------------------- Reporter: dm.maillists@gmail.com | Owner: judahj Type: bug | Status: new Priority: low | Milestone: 6.8 Component: GHCi | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ------------------------------------+--------------------------------------- Comment (by judahj): I've attached a patch which fixes this bug. Note that it requires the changes to the readline package which are described in (and attached to) #1141. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 12 06:37:14 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1137: HashTable.hashString broken In-Reply-To: <071.05fd84222ae7542c096fdb8fedad2015@localhost> References: <071.05fd84222ae7542c096fdb8fedad2015@localhost> Message-ID: <080.94b060333ae7a7dfd17b7bd95b97ba7f@localhost> #1137: HashTable.hashString broken ------------------------------------+--------------------------------------- Reporter: j.russell@alum.mit.edu | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------+--------------------------------------- Changes (by simonmar): * milestone: => 6.6.1 Comment: I've asked Jan-Willem Maessen (who supplied the `hashString` code in 6.6). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 12 06:53:51 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1138: The -fexcess-precision flag is ignored if supplied on the command line. In-Reply-To: <071.cf63259a36ad2b8981af65aece60734f@localhost> References: <071.cf63259a36ad2b8981af65aece60734f@localhost> Message-ID: <080.dac91780561dcedbd2a4f1da3ea1ef90@localhost> #1138: The -fexcess-precision flag is ignored if supplied on the command line. ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 6.6 Severity: normal | Resolution: fixed Keywords: numerics, excess-precision | Difficulty: Easy (1 hr) Testcase: | Architecture: x86 Os: Unknown | ----------------------------------------+----------------------------------- Changes (by simonmar): * resolution: => fixed * status: new => closed Comment: already fixed, in both the 6.6 branch and HEAD, this is the patch: {{{ Fri Dec 1 16:41:57 GMT 2006 Simon Marlow * Ugly hack to fix -fexcess-precision }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 12 07:30:12 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1142: Access denied to Snapshot distributions In-Reply-To: <071.6c9354ff8e1c7975a4156e4bea6e640f@localhost> References: <071.6c9354ff8e1c7975a4156e4bea6e640f@localhost> Message-ID: <080.3ac0754a241ace2afe61ff826595bd9b@localhost> #1142: Access denied to Snapshot distributions ----------------------------------------+----------------------------------- Reporter: ken.takusagawa.2@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------------+----------------------------------- Changes (by simonmar): * resolution: => fixed * status: new => closed Comment: Fixed, thanks. For future reference: it's necessary to set the `umask` in the BuildBot client config, otherwise it defaults to '077', and these permissions are copied by default by rsync when uploading a distribution. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Feb 12 16:02:16 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1144: reduction count for ghci Message-ID: <071.1dfb51fd80d55fe374bd709c8b5c14e1@localhost> #1144: reduction count for ghci --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: minor | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- It would be nice to extend ghci's statistics capabilities to include the number of reductions, similar to the feature already present in hugs -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 13 13:21:31 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1145: class instance lost during re-export & packaging Message-ID: <071.584e901cbf439854741bdcfdd7ceddd7@localhost> #1145: class instance lost during re-export & packaging -------------------------+-------------------------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- The package [http://hackage.haskell.org/cgi-bin/hackage- scripts/package/TV-0.2 TV] defines an instance OFun (in module [http://darcs.haskell.org/packages/TV/doc/html/Interface-TV-OFun.html Interface.TV.OFun], source [http://darcs.haskell.org/packages/TV/doc/html/src/Interface/TV/OFun.hs.html here]) for a type class [http://darcs.haskell.org/packages/DeepArrow/doc/html/Data- FunArr.html#t%3AFunArr| FunArr] in the package [http://hackage.haskell.org /cgi-bin/hackage-scripts/package/DeepArrow-0.0.1 DeepArrow]. The module [http://darcs.haskell.org/packages/TV/doc/html/Interface-TV.html Interface.TV] (source [http://darcs.haskell.org/packages/TV/doc/html/src/Interface/TV.hs.html here]) re-exports Interface.TV.OFun in its entirety. When I compile a test program that imports Interface.TV, under ghc-6.6, the OFun instance of !FunArr is not found. If the test module also says "import Interface.TV.OFun()", the instance is found. I get this behavior with ghc, ghc --make, and ghci. The test program: {{{ module Bug where import Interface.TV.UI -- Required to pick up the FunArr instance for OFun. GHC bug? import Interface.TV.OFun() reverseT :: TV KIO (String -> String) reverseT = tv (oTitle "reverse" defaultOut) reverse revTwice :: TV KIO (String -> String) revTwice = reverseT ->| reverseT }}} Test compile: {{{ bash-3.2$ ghc -c Bug.hs bash-3.2$ }}} If I comment out the second import line, the problem surfaces: {{{ ghc -c Bug.hs Bug.hs:12:11: No instance for (FunArr ar (Output KIO)) arising from use of `->|' at Bug.hs:12:11-31 Possible fix: add an instance declaration for (FunArr ar (Output KIO)) In the expression: reverseT ->| reverseT In the definition of `revTwice': revTwice = reverseT ->| reverseT bash-3.2$ }}} More details: {{{ bash-3.2$ uname -a CYGWIN_NT-5.1 Compy 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin bash-3.2$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 bash-3.2$ ghc -v -c Bug.hs Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6 Using package config file: c:\ghc\ghc-6.6\package.conf wired-in package base mapped to base-2.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.0 Hsc static flags: -static Created temporary directory: c:/tmp/ghc3880_0 *** Checking old interface for main:Bug: *** Parser: *** Renamer/typechecker: Bug.hs:12:11: No instance for (FunArr ar (Output KIO)) arising from use of `->|' at Bug.hs:12:11-31 Possible fix: add an instance declaration for (FunArr ar (Output KIO)) In the expression: reverseT ->| reverseT In the definition of `revTwice': revTwice = reverseT ->| reverseT *** Deleting temp files: Deleting: c:/tmp/ghc3880_0/ghc3880_0.s Warning: deleting non-existent c:/tmp/ghc3880_0/ghc3880_0.s *** Deleting temp dirs: Deleting: c:/tmp/ghc3880_0 bash-3.2$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Feb 13 19:59:13 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1146: Fork bomb should throw an exception Message-ID: <071.50f7584541112d2b45d6643096c6d5f5@localhost> #1146: Fork bomb should throw an exception -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Linux -------------------------------+-------------------------------------------- When fork bombing (example code below, just run 'f'), a failed forkIO should raise an exception, but on 6.7.20070206 it just brings my system to its knees for a while then sometimes crashes and sometimes I just have to kill it. (printouts included just for the heck of it) {{{ import Control.Concurrent f = do a <- forkIO g b <- forkIO g putStrLn $ "f(): Forked a: " ++ (show a) ++ " and b: " ++ (show b) return () g = do a <- forkIO f b <- forkIO f putStrLn $ "g(): Forked a: " ++ (show a) ++ " and b: " ++ (show b) return () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 14 06:28:43 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1010: ghci crashes when running out of heap. In-Reply-To: <071.0a75a83f6404aa1f22d6f1f235984ce2@localhost> References: <071.0a75a83f6404aa1f22d6f1f235984ce2@localhost> Message-ID: <080.27693e5a36249ed559a1ae5e7f4aa9b1@localhost> #1010: ghci crashes when running out of heap. --------------------------------+------------------------------------------- Reporter: tullsen@galois.com | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'm looking at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 14 07:24:04 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1010: ghci crashes when running out of heap. In-Reply-To: <071.0a75a83f6404aa1f22d6f1f235984ce2@localhost> References: <071.0a75a83f6404aa1f22d6f1f235984ce2@localhost> Message-ID: <080.fba1f8504785996cc9a6822f31b4fa9f@localhost> #1010: ghci crashes when running out of heap. --------------------------------+------------------------------------------- Reporter: tullsen@galois.com | Owner: simonmar Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: bug10101 | Architecture: x86 Os: MacOS X | --------------------------------+------------------------------------------- Changes (by simonmar): * testcase: => bug10101 * type: bug => merge Comment: Fixed, to merge: {{{ Wed Feb 14 12:04:01 GMT 2007 Simon Marlow * fix closure_sizeW_() for AP closures }}} and the test: {{{ Wed Feb 14 12:21:24 GMT 2007 Simon Marlow * add test for bug #1010 }}} the test program also illustrates a nasty O(n^2) case in the compacting GC which I knew about but we don't have a ticket for, so I'll add one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 14 07:40:39 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1147: Quadratic behaviour in the compacting GC Message-ID: <071.0c1520aeaeb8e951fd2aaef4ec8683d0@localhost> #1147: Quadratic behaviour in the compacting GC -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Run the following program under GHCi with `+RTS -c -RTS`: {{{ module Main where break2 p (x:xs) = if p x then ([],x:xs) else let (b1,b2) = break2 p xs in (x : b1, b2) break2 p [] = ([],[]) surprise xs = b1 ++ "\n surprise " ++ b2 where (b1,b2) = break2 (=='\n') xs test n = length $ surprise $ [head (show i) | i <-[1..n] ] ++ "\n the end" main = print $ test 1000000 }}} Notice how it hangs. This is because of the call to `get_threaded_info()` in `thread_PAP_payload()` in the compacting GC. We have a lot of APs pointing to the same BCO, so the thread gets really long, and needs to be unravelled for every AP. One partial fix would be to cache the fun's info table in the spare field of an AP during the mark phase; this fixes the problem for APs, but not for PAPs (which don't have a spare field). Related to this is the `get_threaded_info()` call in `update_fwd_compact()`, which is inefficient, but not quadratic. It would be nice to fix this too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 14 11:42:34 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <071.bd4ae66865d4330446a06eaf62a80a52@localhost> References: <071.bd4ae66865d4330446a06eaf62a80a52@localhost> Message-ID: <080.001add24efa6bd68c3c69ba9b267fda8@localhost> #1110: Setting PATH needed in Windows Vista ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: Type: bug | Status: new Priority: high | Milestone: 6.6.1 Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high Comment: Vista support is a high prio for 6.6.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 14 11:43:07 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1010: ghci crashes when running out of heap. In-Reply-To: <071.0a75a83f6404aa1f22d6f1f235984ce2@localhost> References: <071.0a75a83f6404aa1f22d6f1f235984ce2@localhost> Message-ID: <080.e468c5855af940643f0934b2d8989485@localhost> #1010: ghci crashes when running out of heap. --------------------------------+------------------------------------------- Reporter: tullsen@galois.com | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: bug10101 | Architecture: x86 Os: MacOS X | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 14 17:52:30 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:13 2007 Subject: [GHC] #1148: Bad warnings about unused imports that are in fact needed Message-ID: <071.57d0623b10a209349baf4154e355c29f@localhost> #1148: Bad warnings about unused imports that are in fact needed -------------------------+-------------------------------------------------- Reporter: brianh | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6 Severity: trivial | Keywords: warning unused import Difficulty: Unknown | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- If I compile the following code with the `-W` flag I get a warning about the import of `Data.Ix` that shouldn't be generated, since this import is actually needed: {{{ {-# OPTIONS_GHC -fglasgow-exts #-} module ArrayBoundedU ( T , create , at ) where import Data.Ix import qualified Data.Array.Unboxed as Array import Data.Array.Base (unsafeAt) newtype T i e = T (Array.UArray i e) create :: (Ix i, Bounded i, Array.IArray Array.UArray e) => [(i,e)] -> T i e create ies = T (Array.array (minBound, maxBound) ies) at :: (Ix i, Bounded i, Array.IArray Array.UArray e) => T i e -> i -> e at (T a) i = unsafeAt a (index (minBound, maxBound) i) }}} with a sample `Main` {{{ module Main where import Data.Ix import ArrayBoundedU data I = One | Two | Three deriving (Eq, Ord, Ix, Bounded) main = do let a = create [(One, 10::Int), (Two, 20), (Three, 30)] putStrLn (show (at a Two)) }}} built using ghc6.6 with: {{{ ghc --make Main.hs -W }}} I get the warning: {{{ ArrayBoundedU.hs:8:0: Warning: Module `Data.Ix' is imported, but nothing from it is used, except perhaps instances visible in `Data.Ix' To suppress this warning, use: import Data.Ix() }}} However if I do this then the code doesn't compile at all, since the import '''is''' needed. This is just a very trivial little thing but it prevents me from being able to get my code to compile with no warnings (unless I switched the warning off altogether but then something else which really was unused would go undetected). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Feb 14 20:36:32 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:14 2007 Subject: [GHC] #998: Tab-completion of filenames does not work in GHCi 6.6 In-Reply-To: <071.6210fcc1137fd53f42bfc89f0aabacc7@localhost> References: <071.6210fcc1137fd53f42bfc89f0aabacc7@localhost> Message-ID: <080.48f1e463512157ea15ece0f3e5e20ecc@localhost> #998: Tab-completion of filenames does not work in GHCi 6.6 ------------------------------------+--------------------------------------- Reporter: dm.maillists@gmail.com | Owner: judahj Type: bug | Status: new Priority: low | Milestone: 6.8 Component: GHCi | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ------------------------------------+--------------------------------------- Comment (by judahj): One more note: this patch requires readline version 5.0 or later. In contrast, the proposed changes in #1141 are compatible with earlier version of readline (they will only include the relevant functions if compiled against a new enough version of the library). Thus, there probably needs to be something changed or added in the configuration scripts of ghc itself to bump up the requirements for readline. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Feb 15 04:40:46 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:14 2007 Subject: [GHC] #1149: Socket handles are not properly closed after hDuplicate Message-ID: <071.b94f95ea646870002fd86e9cbbdba418@localhost> #1149: Socket handles are not properly closed after hDuplicate --------------------------------------------+------------------------------- Reporter: cb224@student.cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/network | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: x86 | Os: Linux --------------------------------------------+------------------------------- After accepting a handle using Network's accept, then using hDuplicate from GHC.Handle to get separate read/write channels, hClose on both Handles does not appear to properly close the socket. {{{ $ cat >bug.hs import GHC.Handle (hDuplicate) import Network import System.IO main = serve 1234 serve port = withSocketsDo $ do gate <- listenOn (PortNumber port) accept_clients gate where accept_clients gate = do (h,host,port) <- accept gate let h_in = h h_out = h h_out <- hDuplicate h hClose h_in hClose h_out accept_clients gate }}} compile, run, and connect: {{{ $ ghc --make -o bug -v bug.hs Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6 .6 Using package config file: /u