From trac at galois.com Fri May 1 15:14:27 2009 From: trac at galois.com (GHC) Date: Fri May 1 15:00:08 2009 Subject: [GHC] #3173: Install fails when using DESTDIR In-Reply-To: <045.8d36b199003970aa7bab88684104eafe@localhost> References: <045.8d36b199003970aa7bab88684104eafe@localhost> Message-ID: <054.e56146f11a7f6f4019858e0f90d57fdc@localhost> #3173: Install fails when using DESTDIR -----------------------------+---------------------------------------------- Reporter: fidori | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.2 Severity: normal | Resolution: Keywords: DESTDIR | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 Comment: Ah, I see, this is only broken when installing from a bindist, not from a built source tree. I'm not sure if DESTDIR has ever worked with a bindist, but I don't think it should be hard, so let's look at doing it in the new build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 1 18:24:37 2009 From: trac at galois.com (GHC) Date: Fri May 1 18:10:35 2009 Subject: [GHC] #3204: Binary package of GHC 6.10.2 fails to install on debian etch (amd64) Message-ID: <042.64dd93caf2590348951f733f5c60e514@localhost> #3204: Binary package of GHC 6.10.2 fails to install on debian etch (amd64) -------------------+-------------------------------------------------------- Reporter: sol | Owner: Type: bug | Status: new Priority: normal | Component: Package system Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- Released package http://www.haskell.org/ghc/dist/6.10.2/ghc-6.10.2-x86_64 -unknown-linux-libedit2.tar.bz2 fails to install on Debian GNU/Linux 4.0 r3 with: /usr/bin/strip: /home/sol/.install/ghc/ghc-6.10.2-inst/lib/ghc-6.10.2/ghc- pkg: File format not recognized {{{strip --version}}} gives: {{{ GNU strip 2.17 Debian GNU/Linux }}} {{{uname -a}}} gives: {{{ Linux gcc14 2.6.18-6-vserver-amd64 #1 SMP Fri Dec 12 06:15:44 UTC 2008 x86_64 GNU/Linux }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 1 20:00:02 2009 From: trac at galois.com (GHC) Date: Fri May 1 19:45:54 2009 Subject: [GHC] #2952: ghci fails to start from start menu on windows 7 In-Reply-To: <044.ff62699b4016eeac0215e90934c5496e@localhost> References: <044.ff62699b4016eeac0215e90934c5496e@localhost> Message-ID: <053.0c29f4d0efe9cbf9d72950d2e655f482@localhost> #2952: ghci fails to start from start menu on windows 7 -----------------------+---------------------------------------------------- Reporter: larsv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Comment (by larsv): This bug seems to be fixed with 6.10.2 in the Windows 7 and Windows Server 2008 R2 Release Candidate 1 build (7100.0.090421-1700_x64fre). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 3 16:58:20 2009 From: trac at galois.com (GHC) Date: Sun May 3 16:43:53 2009 Subject: [GHC] #3205: Generalized isomorphic deriving Message-ID: <042.5465e02313ec0c86ef0c59c5b9869960@localhost> #3205: Generalized isomorphic deriving -----------------------------+---------------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- A newtype is isomorphic to the type that it is based on. For example, newtype A = A Int is isomorphic to Int, so it is possible to automatically derive all of Int's instance for A. It would be nice if this could be extended to other datatypes that were isomorphic to each other. For example, this would work {{{ data K a = K a a a instance C (K a) where ... data L a = L a a a deriving (Eq,C<-K,Show) }}} where the {{{C<-K}}} notation means "derive an instance of C for this type that is 'the same as' the instance of C for K". The compiler would have to check that K and L were actually isomorphic. I don't know if this is possible with the current internals of GHC, but it would be cool if it would be done. My main usage scenario would be deriving things for single-argument data constructors based on tuples; for example for serialization classes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 3 17:18:57 2009 From: trac at galois.com (GHC) Date: Sun May 3 17:04:58 2009 Subject: [GHC] #3204: Binary package of GHC 6.10.2 fails to install on debian etch (amd64) In-Reply-To: <042.64dd93caf2590348951f733f5c60e514@localhost> References: <042.64dd93caf2590348951f733f5c60e514@localhost> Message-ID: <051.9d960d8904cf8bca029db3920f68b061@localhost> #3204: Binary package of GHC 6.10.2 fails to install on debian etch (amd64) -------------------------------+-------------------------------------------- Reporter: sol | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 6.10.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: I'm afraid you will have to install a newer version of `binutils` if you want to install this bindist. I don't think that the imminent 6.10.3 bindists will have this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 5 06:36:27 2009 From: trac at galois.com (GHC) Date: Tue May 5 06:21:54 2009 Subject: [GHC] #3203: System.Directory.getDirectoryContents functionality on empty String In-Reply-To: <048.8a2ab99b80c2114640f1b0f51860768a@localhost> References: <048.8a2ab99b80c2114640f1b0f51860768a@localhost> Message-ID: <057.53bb536161c5c2c474d8ffb739c857fc@localhost> #3203: System.Directory.getDirectoryContents functionality on empty String ---------------------------------+------------------------------------------ Reporter: jberryman | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: System.Directory | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid * cc: NeilMitchell (added) Comment: Replying to [comment:2 duncan]: > I have to say, I don't like the idea. There is no file or directory named "", though it's true that we alias the file "foo" with "./foo". > > The solution to your examples with `System.FilePath` functions is to fix them to return "." rather than "". I recall there being some discussion on this point elsewhere. Agreed. See #2034 (In FilePath, current directory should be ".", not "") -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 5 06:43:42 2009 From: trac at galois.com (GHC) Date: Tue May 5 06:29:10 2009 Subject: [GHC] #2952: ghci fails to start from start menu on windows 7 In-Reply-To: <044.ff62699b4016eeac0215e90934c5496e@localhost> References: <044.ff62699b4016eeac0215e90934c5496e@localhost> Message-ID: <053.2e267203ddb99ef35b6f1862f52e4135@localhost> #2952: ghci fails to start from start menu on windows 7 -----------------------+---------------------------------------------------- Reporter: larsv | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Thanks - I reported the bug against Win 7 beta recently, but the bug was summarily closed with the reason that I had to re-test with the RC (which I haven't done yet). Since you had a positive result, I'll close this ticket, and we can re-open if the bug emerges again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 5 08:38:15 2009 From: trac at galois.com (GHC) Date: Tue May 5 08:23:58 2009 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> Message-ID: <060.48deb61fcc0827a4df0f0abc9dc71b2d@localhost> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): Replying to [comment:22 simonpj]: > "I absolutely hate it if I have to write a .hc-boot file" (I assume you mean hs-boot file). I'm interested in identifying precisely what it is that you hate, lest we fix the wrong thing: > > * Do you hate writing the type signatures of the functions that the module exports? (After all, most Haskell programmers do that routinely.) No, and I do it, too. > * Do you hate putting those type signatures in a physically different file? That is would the hate be alleviated if the signatures were in the same file as the module implementation? No; in fact sometimes I wish I could make module interfaces more explicit a la ML or Modula. > * Or perhaps you hate something else? Such as having to pick a place to cut the recursive loop at all? Yes. This is just distracting. Knowing that the compiler could do it automatically, I don't like to do it manually. Another point is that hc-boot files are non-standard. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 5 16:19:54 2009 From: trac at galois.com (GHC) Date: Tue May 5 16:05:36 2009 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> Message-ID: <060.2c19c35f97553afe4f5f4ce35c018f61@localhost> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): The "physically separate file" frustrates me. It would be less specifically-frustrating if type signatures were *always* in a separate file, not just the ones for loop-breaking... but I've been to C and C++ and I can't say that it made me happy to keep those different header/source files in sync. -Isaac Dupree -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 5 19:44:45 2009 From: trac at galois.com (GHC) Date: Tue May 5 19:30:09 2009 Subject: [GHC] #3206: Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission denied Message-ID: <048.13ce0c84cab41116f3aa554bc7977596@localhost> #3206: Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission denied ----------------------------------+----------------------------------------- Reporter: Dmitry123 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: getMBlock mmap denied | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------------------+----------------------------------------- I have been trying to find a binary package of ghc that will work on Redhat EL5. The problem is, none of the binaries I have found work all giving the same error..... [root@spot]# ghc ghc-6.8.3: internal error: getMBlock: mmap: Permission denied (GHC version 6.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 6 07:37:16 2009 From: trac at galois.com (GHC) Date: Wed May 6 07:22:41 2009 Subject: [GHC] #3207: readMutVar# is inlined/duplicated Message-ID: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> #3207: readMutVar# is inlined/duplicated -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The following code: {{{ module Main where import Control.Monad.ST.Lazy import Data.STRef.Lazy import Data.Array.ST import Int import Debug.Trace data Refs s = Refs { memory :: STArray s Int8 Int8 , pc :: STRef s Int8 } main :: IO () main = do print $ runST m where m = do m <- newArray_ (0,30) p <- newSTRef 0 let r = Refs m p writeArray m 0 0x4 v <- readSTRef p modifySTRef p (+1) trace ("v: " ++ show v) $ return () op <- readArray m v case trace ("v: " ++ show v) $ op of 0x4 -> modifySTRef p (+100) -- should run this n -> error ("should never match this: " ++ show n) }}} generates this output: {{{ > ./st v: 0 v: 1 st: MArray: undefined array element }}} That is, the two instances of `trace (show v)` are printing different results, for the same v! Looking at the Core, the problem seems to be that a call to `readMutVar#` has been inlined and duplicated. The `readMutVar#` primop doesn't have the `has_side_effects` flag set, and setting it (in `primops.txt.pp`) fixes it, but I'm not completely sure if that's the right fix. If it is, then there are lots of other similar primops that also need that flag set. Bug report originally from a haskell-cafe post: [http://www.haskell.org/pipermail/haskell-cafe/2009-May/061010.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 6 08:17:32 2009 From: trac at galois.com (GHC) Date: Wed May 6 08:02:56 2009 Subject: [GHC] #3207: readMutVar# is inlined/duplicated In-Reply-To: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> References: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> Message-ID: <056.2b37ad5ae56f7c5954f5b484769aecac@localhost> #3207: readMutVar# is inlined/duplicated ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by tobsan): When running the listed code under GNU/Linux on i686, the output is not the same as you listed. [tobsi@wobsi] $ ./st 0 0 () -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 6 08:38:03 2009 From: trac at galois.com (GHC) Date: Wed May 6 08:23:29 2009 Subject: [GHC] #3207: readMutVar# is inlined/duplicated In-Reply-To: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> References: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> Message-ID: <056.1f84ce1ba90dc7e83fd3bf4c92ee7aa1@localhost> #3207: readMutVar# is inlined/duplicated ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by daniel.is.fischer): Confirmed, if compiled without optimisations: {{{ dafis@linux-mkk1:~/Haskell/CafeTesting> ghc --make simonMar [1 of 1] Compiling Main ( simonMar.hs, simonMar.o ) Linking simonMar ... dafis@linux-mkk1:~/Haskell/CafeTesting> ./simonMar v: 0 v: 0 () }}} However, with optimisations: {{{ dafis@linux-mkk1:~/Haskell/CafeTesting> touch simonMar.hs dafis@linux-mkk1:~/Haskell/CafeTesting> ghc -O2 --make simonMar [1 of 1] Compiling Main ( simonMar.hs, simonMar.o ) Linking simonMar ... dafis@linux-mkk1:~/Haskell/CafeTesting> ./simonMar v: 0 v: 1 simonMar: MArray: undefined array element }}} Strangely, the code from haskell-cafe, when I include an explicit export list (main), behaves differently: {{{ dafis@linux-mkk1:~/Haskell/CafeTesting> ghc --make tobOlau [1 of 1] Compiling Main ( tobOlau.hs, tobOlau.o ) Linking tobOlau ... dafis@linux-mkk1:~/Haskell/CafeTesting> ./tobOlau tobOlau: should never match this dafis@linux-mkk1:~/Haskell/CafeTesting> touch tobOlau.hs dafis@linux-mkk1:~/Haskell/CafeTesting> ghc -O --make tobOlau [1 of 1] Compiling Main ( tobOlau.hs, tobOlau.o ) Linking tobOlau ... dafis@linux-mkk1:~/Haskell/CafeTesting> ./tobOlau 101 dafis@linux-mkk1:~/Haskell/CafeTesting> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 dafis@linux-mkk1:~/Haskell/CafeTesting> uname -a Linux linux-mkk1 2.6.27.21-0.1-pae #1 SMP 2009-03-31 14:50:44 +0200 i686 i686 i386 GNU/Linux }}} while without export list, behaviour is independent of optimisation level. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 6 12:48:40 2009 From: trac at galois.com (GHC) Date: Wed May 6 12:34:06 2009 Subject: [GHC] #3208: Type family panic (taking the IdInfo of a coercion variable) Message-ID: <046.41bf598a01dd8c4891c9aac614d23c08@localhost> #3208: Type family panic (taking the IdInfo of a coercion variable) -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Jan Jakubuv found [http://www.haskell.org/pipermail/glasgow-haskell- users/2009-May/017147.html this]: {{{ {-# OPTIONS -fglasgow-exts #-} module Foo where class SUBST s where type STerm s class OBJECT o where type OTerm o apply :: (SUBST s, OTerm o ~ STerm s) => s -> o fce' f = fce . apply $ f fce f = fce' f }}} yields, with GHC 6.10 or the HEAD: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.2 for i386-unknown-linux): idInfo co{v agz} [tv] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 6 19:36:36 2009 From: trac at galois.com (GHC) Date: Wed May 6 19:21:58 2009 Subject: [GHC] #3209: Use Levenshtein distance for unknown identifier errors Message-ID: <042.94b65b91b3aa47b37e02df15d7189236@localhost> #3209: Use Levenshtein distance for unknown identifier errors -----------------------------+---------------------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- That is, instead of saying {{{ Could not find module `IPprint': Use -v to see a list of the files searched for. }}} Say {{{Could not find module `IPprint': Use -v to see a list of the files searched for. Did you mean `IPPrint'? }}} , likewise for the other namespaces. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 6 21:30:00 2009 From: trac at galois.com (GHC) Date: Wed May 6 21:15:24 2009 Subject: [GHC] #3208: Type family panic (taking the IdInfo of a coercion variable) In-Reply-To: <046.41bf598a01dd8c4891c9aac614d23c08@localhost> References: <046.41bf598a01dd8c4891c9aac614d23c08@localhost> Message-ID: <055.a6e05e4a2283401dee20d0c812be1c9c@localhost> #3208: Type family panic (taking the IdInfo of a coercion variable) ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by chak): * version: 6.10.2 => 6.11 Comment: Seems to be related to (if not a duplicate of) #2767. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 7 10:28:35 2009 From: trac at galois.com (GHC) Date: Thu May 7 10:13:57 2009 Subject: [GHC] #3210: Allow programs to change the number of capabilities Message-ID: <051.bb934f2dd576d96d5354d86a9c82db8c@localhost> #3210: Allow programs to change the number of capabilities -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It would be useful for a program to choose the number of capabilities it has, perhaps in response to a flag. i.e. I'd like users to type {{{hlint -j3}}} rather than {{{hlint +RTS -N3}}}. To support this change one option would be to allow increasing the number of capabilities after a program has started. Another option would be to provide a primitive {{{restartWithCapabilities :: Int -> IO ()}}} that aborted the program, and restarted {{{main}}} but with the required settings. Using RTS flags is unsuitable for people who use Haskell programs but aren't really Haskell developers. As more programs go multi-core, this feature will probably become more desirable. However, it's not too important and can always be solved by a little shell script. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 7 11:42:46 2009 From: trac at galois.com (GHC) Date: Thu May 7 11:28:06 2009 Subject: [GHC] #3211: Typos in RTS documentation Message-ID: <044.ffb7a01a62d3159b407a9f3ce1e13679@localhost> #3211: Typos in RTS documentation -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- From: http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime- control.html#rts-options-gc "Next there is the CPU time and wall clock time elapsedm broken down by what the runtiem system was doing at the time." Two typos: "elapsedm" and "runtiem". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 8 01:06:53 2009 From: trac at galois.com (GHC) Date: Fri May 8 00:52:13 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.2dbc0ac6e2c89b391f42a55ccdb889a7@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ksf): * cc: barsoap@web.de (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 8 04:30:33 2009 From: trac at galois.com (GHC) Date: Fri May 8 04:15:53 2009 Subject: [GHC] #3206: Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission denied In-Reply-To: <048.13ce0c84cab41116f3aa554bc7977596@localhost> References: <048.13ce0c84cab41116f3aa554bc7977596@localhost> Message-ID: <057.e039bea2c883b17c87b13e6563d753fd@localhost> #3206: Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission denied --------------------------------------+------------------------------------- Reporter: Dmitry123 | Owner: Type: bug | Status: new Priority: low | Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: getMBlock mmap denied | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Changes (by simonmar): * priority: normal => low * difficulty: => Unknown * milestone: => 6.12.1 Comment: I think you may be experiencing #783. Try with 6.10.2 and let us know if that fixes it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 8 04:33:11 2009 From: trac at galois.com (GHC) Date: Fri May 8 04:18:29 2009 Subject: [GHC] #3211: Typos in RTS documentation In-Reply-To: <044.ffb7a01a62d3159b407a9f3ce1e13679@localhost> References: <044.ffb7a01a62d3159b407a9f3ce1e13679@localhost> Message-ID: <053.2da453586ca880412847a80154e1d7ec@localhost> #3211: Typos in RTS documentation ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 8 09:57:24 2009 From: trac at galois.com (GHC) Date: Fri May 8 09:42:42 2009 Subject: [GHC] #2781: Install permissions broken In-Reply-To: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> References: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> Message-ID: <053.eef4361f6237ab2bb8a7574d4049d371@localhost> #2781: Install permissions broken ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: install permissions | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by Feuerbach): * status: closed => reopened * resolution: worksforme => Comment: I confirm that, if using umask 022, everything is ok. However if you use umask 077 then you will get permissions that OP showed. I guess OP was confused by the fact that, if you change umask to 022 and redo ./configure && make install, it doesn't help. To solve the problem you need to set umask 022 before you untar the archive, so that files get right permissions from the beginning. I agree with OP that permissions should be set correctly during installation no matter which umask user prefers, so let me reopen this ticket. (Note: just setting desired umask in the install script doesn't help for the reasons described above. In other words, installation should not make any assumption about files permissions apart from being able to read them.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 8 09:58:56 2009 From: trac at galois.com (GHC) Date: Fri May 8 09:44:12 2009 Subject: [GHC] #2781: Install permissions broken In-Reply-To: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> References: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> Message-ID: <053.7324d9daaf464245de8643d254b2bc4f@localhost> #2781: Install permissions broken ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.2 Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: install permissions | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Comment (by Feuerbach): BTW, I tested this with ghc-6.10.2-i386-unknown-linux-libedit2.tar.bz2 on Debian Lenny. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 8 10:38:09 2009 From: trac at galois.com (GHC) Date: Fri May 8 10:23:28 2009 Subject: [GHC] #3207: readMutVar# is inlined/duplicated In-Reply-To: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> References: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> Message-ID: <056.510c0c6cb21c800c2024781a3e48ad35@localhost> #3207: readMutVar# is inlined/duplicated ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by j.waldmann): I will attach a file (STCheck) that is perhaps related. Behaviour is: when using ghc-6.10.2 and STRef.Lazy, it enters a <> (in ghci, it just hangs, prompt never returns). When compiled with ghc-6.8.3, it prints the expected answer (1). With ghc-6.10.2 and STRef.Strict, it works. With ghc-6.10.2 and replacing readSTRef/writeSTRef (end of program) by modifySTRef, it works as well. (This actually cost me several hours to isolate. The "cache" function is from a real program.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 8 23:29:46 2009 From: trac at galois.com (GHC) Date: Fri May 8 23:15:02 2009 Subject: [GHC] #3212: getOptions'.parseLanguage(2) went past eof token Message-ID: <042.c0f8decac3d750e7da6de499b5a859fa@localhost> #3212: getOptions'.parseLanguage(2) went past eof token -----------------------------------------------------------+---------------- Reporter: Jig | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: minor Keywords: getOptions'.parseLanguage(2) XFlexibleContexts | Testcase: Os: Windows | Architecture: Unknown/Multiple -----------------------------------------------------------+---------------- {-# LANGUAGE -XFlexibleContexts #-} module Pngloadtest where import Control.Monad import Control.Arrow import Codec.Image.PNG import Data.Array.MArray import Data.Array.Storable import GHC.Word --import Data.Array.MArray import qualified Data.Matrix.DenseMatrix as DM openImage :: IO PNGImage openImage = do a <- loadPNGFile "C:/users/saftarn/desktop/datasets/pics/face2.png" case a of Left err -> error err Right img -> return img dims :: PNGImage -> (Int, Int) dims img = join (***) fromIntegral $ dimensions img size :: PNGImage -> Int size img = uncurry (*) $ dims img --imgToList :: (MArray StorableArray Word8 m, Num b) => PNGImage -> m [b] imgToList img = do es <- getElems $ imageData img return $ map fromIntegral es imgToMatrix :: (MArray StorableArray Word8 m) => PNGImage -> m DM.DenseMatrix imgToMatrix im = do let (w,_) = dims im xs <- imgToList im return $ DM.fromFlatList w xs main = do im <- openImage a <- imgToList im print $ dims im print $ size im --print a *Pngloadtest> :load "ComputerVision/Pngloadtest.hs" [1 of 2] Compiling Data.Matrix.DenseMatrix ( Data\Matrix\DenseMatrix.hs, interpreted ) [2 of 2] Compiling Pngloadtest ( ComputerVision\Pngloadtest.hs, interpreted ) ComputerVision\Pngloadtest.hs:29:0: Non type-variable argument in the constraint: MArray StorableArray Word8 m (Use -XFlexibleContexts to permit this) In the type signature for `imgToMatrix': imgToMatrix :: (MArray StorableArray Word8 m) => PNGImage -> m DM.DenseMatrix Failed, modules loaded: Data.Matrix.DenseMatrix. *Data.Matrix.DenseMatrix> :load "ComputerVision/Pngloadtest.hs" : panic! (the 'impossible' happened) (GHC version 6.10.2 for i386-unknown-mingw32): getOptions'.parseLanguage(2) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Works if using: {-# LANGUAGE FlexibleContexts #-} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 9 00:08:17 2009 From: trac at galois.com (GHC) Date: Fri May 8 23:53:35 2009 Subject: [GHC] #3213: Failure in parsing a malformed LANGUAGE pragma Message-ID: <046.4a378e75187677cb4dffb5ad70bf5920@localhost> #3213: Failure in parsing a malformed LANGUAGE pragma -----------------------------+---------------------------------------------- Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Very simple failure case! {{{ {-# LANGUAGE - #-} module Hs where schwee = "schwoo" {- results in output@ ghc: panic! (the 'impossible' happened) (GHC version 6.10.2 for i386-unknown-linux): getOptions'.parseLanguage(2) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug when trying ghc --make Hs also blows up if you replace that - with, say, "-XBangpatterns" or whatever. -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 9 20:56:18 2009 From: trac at galois.com (GHC) Date: Sat May 9 20:41:33 2009 Subject: [GHC] #3214: "undefined reference to..." when compiling parallel code Message-ID: <048.1bcea8bd308db2861bde0326485cbaa9@localhost> #3214: "undefined reference to..." when compiling parallel code --------------------------------+------------------------------------------- Reporter: fhsanches | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: undefined reference | Testcase: Os: Linux | Architecture: Unknown/Multiple --------------------------------+------------------------------------------- First of all, sorry if it's not a bug in GHC, but I just don't know where to file it. When compiling a file that imports Control.Parallel (par), I receive the following error: death-star% ghc par.hs -O2 par.o: In function `s15L_info': (.text+0xce3): undefined reference to `__stginit_parallelzm1zi0zi0zi0_ControlziParallel_' collect2: ld returned 1 exit status Disabling optimizations just make things worse: death-star% ghc par.hs -fforce-recomp par.o: In function `r6b_info': (.text+0x106d): undefined reference to `parallelzm1zi0zi0zi0_ControlziParallel_par_closure' par.o: In function `sEr_info': (.text+0x143b): undefined reference to `__stginit_parallelzm1zi0zi0zi0_ControlziParallel_' par.o: In function `r6b_srt': (.data+0x368): undefined reference to `parallelzm1zi0zi0zi0_ControlziParallel_par_closure' collect2: ld returned 1 exit status Is this a bug in GHC? In ld? Any missing dependency in my distro? I'm using Ubuntu 9.04, GHC 6.8.2 built from the repositories. Thanks for your time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 9 21:05:29 2009 From: trac at galois.com (GHC) Date: Sat May 9 20:51:01 2009 Subject: [GHC] #3214: "undefined reference to..." when compiling parallel code In-Reply-To: <048.1bcea8bd308db2861bde0326485cbaa9@localhost> References: <048.1bcea8bd308db2861bde0326485cbaa9@localhost> Message-ID: <057.17cdf7ee68f84292b91be19c653113ab@localhost> #3214: "undefined reference to..." when compiling parallel code ---------------------------------+------------------------------------------ Reporter: fhsanches | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: undefined reference | Testcase: Os: Linux | Architecture: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by fhsanches): * version: 6.10.2 => 6.8 Comment: Sorry, I just realized I'm using an old GHC version (and filed the bug agains the new one). Sorry for the burden. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 9 21:08:13 2009 From: trac at galois.com (GHC) Date: Sat May 9 20:53:29 2009 Subject: [GHC] #3214: "undefined reference to..." when compiling parallel code In-Reply-To: <048.1bcea8bd308db2861bde0326485cbaa9@localhost> References: <048.1bcea8bd308db2861bde0326485cbaa9@localhost> Message-ID: <057.8f9c370b992d4464fe17eb210cafeced@localhost> #3214: "undefined reference to..." when compiling parallel code ---------------------------------+------------------------------------------ Reporter: fhsanches | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8 Severity: normal | Resolution: invalid Keywords: undefined reference | Testcase: Os: Linux | Architecture: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by fhsanches): * status: new => closed * resolution: => invalid Comment: Sigh, sorry for the flood here, I forgot to pass the "--make" flag to the compiler. I'm really, really sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 10 13:51:52 2009 From: trac at galois.com (GHC) Date: Sun May 10 13:37:04 2009 Subject: [GHC] #3215: Calling freeHaskellFunPtr on the current function Message-ID: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> #3215: Calling freeHaskellFunPtr on the current function -------------------+-------------------------------------------------------- Reporter: cmcq | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- This is based on code in gtk2hs. $ valgrind -q ./finalizer_queue finalizer_queue: internal error: stg_ap_v_ret (GHC version 6.10.3 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Killed Unfortunately this test doesn't crash without Valgrind. My guess is that this bit is the problem: finalizer <- fixIO $ \dPtr -> mkThunk $ do freeHaskellFunPtr callback freeHaskellFunPtr dPtr Perhaps the documentation should say not to do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 10 14:51:10 2009 From: trac at galois.com (GHC) Date: Sun May 10 14:36:21 2009 Subject: [GHC] #3216: Terminal output in GHCi 10.3 on Mac OS X Message-ID: <044.015402d518098531d13d84633eabcb1e@localhost> #3216: Terminal output in GHCi 10.3 on Mac OS X --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- ''Results of expressions are printed on the same line:[[BR]] '' > ghci[[BR]] GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help[[BR]] Loading package ghc-prim ... linking ... done.[[BR]] Loading package integer ... linking ... done.[[BR]] Loading package base ... linking ... done.[[BR]] 7relude> 3+4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 10 23:48:41 2009 From: trac at galois.com (GHC) Date: Tue May 12 04:01:01 2009 Subject: [GHC] #3216: Terminal output in GHCi 10.3 on Mac OS X In-Reply-To: <044.015402d518098531d13d84633eabcb1e@localhost> References: <044.015402d518098531d13d84633eabcb1e@localhost> Message-ID: <053.27918fdf3795c955d28a156e51c0f3af@localhost> #3216: Terminal output in GHCi 10.3 on Mac OS X ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ Comment (by judah): Did you build from source or install from a binary distribution? If a binary, which one? Are you running ghci in Terminal.app or X11? Finally, please paste the output of these two commands: {{{ stty -a infocmp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 11 04:51:20 2009 From: trac at galois.com (GHC) Date: Tue May 12 04:03:54 2009 Subject: [GHC] #3215: Calling freeHaskellFunPtr on the current function In-Reply-To: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> References: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> Message-ID: <052.0f0d11b6aed8f0eb9d76b681ba67ad24@localhost> #3215: Calling freeHaskellFunPtr on the current function ----------------------------+----------------------------------------------- Reporter: cmcq | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.10.3 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------------+----------------------------------------------- Changes (by cmcq): * status: new => closed * resolution: => invalid Comment: This was just a Valgrind problem with self-modifying code. "--smc- check=all" fixes it. I think that due to the LIFO free list used by rts/Stable.c, the functions are reversed the second time round. Because of Valgrind's caching, the finalizer was being called first. I noticed this paragraph in rts/Adjustor.c, so I assume that calling freeHaskellFunPtr on the current function IS allowed. When generating an adjustor thunk that uses the C calling convention, we have to make sure that the thunk kicks off the process of jumping into Haskell with a tail jump. Why? Because as a result of jumping in into Haskell we may end up freeing the very adjustor thunk we came from using freeHaskellFunctionPtr(). Hence, we better not return to the adjustor code on our way out, since it could by then point to junk. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 11 08:17:59 2009 From: trac at galois.com (GHC) Date: Tue May 12 04:16:56 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions Message-ID: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- It's becoming clear that in GHCi we want to have a separate set of command-line flags for * Compiling Haskell expressions typed at the GHCi prompt * Compiling entire modules, eg via `:load` Examples of this need are: * We already have an ad-hoc difference in the way that type-class defaults are applied: http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive- evaluation.html#extended-default-rules * In #3202 there's a well-argued request to change behaviour of the monomorphism restriction So the new feature would consist of: * The `InteractiveContext` should contain a set of `DynFlags` used for compiling command-line Haskell expressions (the ''interactive `DynFlags`'') * The `:set` command would change both the `DynFlags` maintained by GHCi for compiling entire modules (the ''batch `DynFlags`''), and the interactive `DynFlags`. * A new `:seti` command to change the interactive flags * Just possibly a `:setb` command to set the batch flags but leave the interactive ones unchanged. Arguably it'd be good to have a command to display the current flag settings (of either `DynFlags`) but that's another blob of work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 11 08:18:58 2009 From: trac at galois.com (GHC) Date: Tue May 12 04:17:08 2009 Subject: [GHC] #3202: Make XNoMonomorphismRestriction the default in GHCi In-Reply-To: <047.d2e31e41b925b8804676d46611405d7d@localhost> References: <047.d2e31e41b925b8804676d46611405d7d@localhost> Message-ID: <056.1fdcb26eed077043e2b20bbce376b057@localhost> #3202: Make XNoMonomorphismRestriction the default in GHCi ---------------------------------+------------------------------------------ Reporter: YitzGale | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Simon and I talked about this, and wrote a feature request #3217. Once that's done, it'll be easy to change the default interactive-flag setings. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 11 08:34:49 2009 From: trac at galois.com (GHC) Date: Tue May 12 04:18:35 2009 Subject: [GHC] #3212: getOptions'.parseLanguage(2) went past eof token In-Reply-To: <042.c0f8decac3d750e7da6de499b5a859fa@localhost> References: <042.c0f8decac3d750e7da6de499b5a859fa@localhost> Message-ID: <051.03a1e5908b7ceb8f708db4d06cf82d3d@localhost> #3212: getOptions'.parseLanguage(2) went past eof token ---------------------------------------------------------------+------------ Reporter: Jig | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: minor | Resolution: Keywords: getOptions'.parseLanguage(2) XFlexibleContexts | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------------------------------------+------------ Changes (by simonmar): * difficulty: => Unknown Old description: > {-# LANGUAGE -XFlexibleContexts #-} > module Pngloadtest where > import Control.Monad > import Control.Arrow > import Codec.Image.PNG > import Data.Array.MArray > import Data.Array.Storable > import GHC.Word > --import Data.Array.MArray > import qualified Data.Matrix.DenseMatrix as DM > > openImage :: IO PNGImage > openImage = do > a <- loadPNGFile "C:/users/saftarn/desktop/datasets/pics/face2.png" > case a of Left err -> error err > Right img -> return img > > dims :: PNGImage -> (Int, Int) > dims img = join (***) fromIntegral $ dimensions img > > size :: PNGImage -> Int > size img = uncurry (*) $ dims img > > --imgToList :: (MArray StorableArray Word8 m, Num b) => PNGImage -> m [b] > imgToList img = do > es <- getElems $ imageData img > return $ map fromIntegral es > > imgToMatrix :: (MArray StorableArray Word8 m) => PNGImage -> > m DM.DenseMatrix > imgToMatrix im = do > let (w,_) = dims im > xs <- imgToList im > return $ DM.fromFlatList w xs > > main = do > im <- openImage > a <- imgToList im > print $ dims im > print $ size im > --print a > > > > *Pngloadtest> :load "ComputerVision/Pngloadtest.hs" > [1 of 2] Compiling Data.Matrix.DenseMatrix ( Data\Matrix\DenseMatrix.hs, > interpreted ) > [2 of 2] Compiling Pngloadtest ( ComputerVision\Pngloadtest.hs, > interpreted ) > > ComputerVision\Pngloadtest.hs:29:0: > Non type-variable argument > in the constraint: MArray StorableArray Word8 m > (Use -XFlexibleContexts to permit this) > In the type signature for `imgToMatrix': > imgToMatrix :: (MArray StorableArray Word8 m) => > PNGImage -> m DM.DenseMatrix > Failed, modules loaded: Data.Matrix.DenseMatrix. > *Data.Matrix.DenseMatrix> :load "ComputerVision/Pngloadtest.hs" > : panic! (the 'impossible' happened) > (GHC version 6.10.2 for i386-unknown-mingw32): > getOptions'.parseLanguage(2) went past eof token > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > > > > > > Works if using: > {-# LANGUAGE FlexibleContexts #-} New description: {{{ {-# LANGUAGE -XFlexibleContexts #-} module Pngloadtest where import Control.Monad import Control.Arrow import Codec.Image.PNG import Data.Array.MArray import Data.Array.Storable import GHC.Word --import Data.Array.MArray import qualified Data.Matrix.DenseMatrix as DM openImage :: IO PNGImage openImage = do a <- loadPNGFile "C:/users/saftarn/desktop/datasets/pics/face2.png" case a of Left err -> error err Right img -> return img dims :: PNGImage -> (Int, Int) dims img = join (***) fromIntegral $ dimensions img size :: PNGImage -> Int size img = uncurry (*) $ dims img --imgToList :: (MArray StorableArray Word8 m, Num b) => PNGImage -> m [b] imgToList img = do es <- getElems $ imageData img return $ map fromIntegral es imgToMatrix :: (MArray StorableArray Word8 m) => PNGImage -> m DM.DenseMatrix imgToMatrix im = do let (w,_) = dims im xs <- imgToList im return $ DM.fromFlatList w xs main = do im <- openImage a <- imgToList im print $ dims im print $ size im --print a *Pngloadtest> :load "ComputerVision/Pngloadtest.hs" [1 of 2] Compiling Data.Matrix.DenseMatrix ( Data\Matrix\DenseMatrix.hs, interpreted ) [2 of 2] Compiling Pngloadtest ( ComputerVision\Pngloadtest.hs, interpreted ) ComputerVision\Pngloadtest.hs:29:0: Non type-variable argument in the constraint: MArray StorableArray Word8 m (Use -XFlexibleContexts to permit this) In the type signature for `imgToMatrix': imgToMatrix :: (MArray StorableArray Word8 m) => PNGImage -> m DM.DenseMatrix Failed, modules loaded: Data.Matrix.DenseMatrix. *Data.Matrix.DenseMatrix> :load "ComputerVision/Pngloadtest.hs" : panic! (the 'impossible' happened) (GHC version 6.10.2 for i386-unknown-mingw32): getOptions'.parseLanguage(2) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} Works if using: {-# LANGUAGE FlexibleContexts #-} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 11 08:36:26 2009 From: trac at galois.com (GHC) Date: Tue May 12 04:18:46 2009 Subject: [GHC] #3212: getOptions'.parseLanguage(2) went past eof token In-Reply-To: <042.c0f8decac3d750e7da6de499b5a859fa@localhost> References: <042.c0f8decac3d750e7da6de499b5a859fa@localhost> Message-ID: <051.fea0d1eff2d0477fcd9651aea01f5a57@localhost> #3212: getOptions'.parseLanguage(2) went past eof token ---------------------------------------------------------------+------------ Reporter: Jig | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: minor | Resolution: duplicate Keywords: getOptions'.parseLanguage(2) XFlexibleContexts | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------------------------------------+------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Thanks for the report; duplicate of #3153, fixed in HEAD. {{{ ~/scratch > ghc-testing2 -c 3212.hs 3212.hs:1:0: cannot parse LANGUAGE pragma: comma-separated list expected }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 11 08:37:07 2009 From: trac at galois.com (GHC) Date: Tue May 12 04:18:55 2009 Subject: [GHC] #3213: Failure in parsing a malformed LANGUAGE pragma In-Reply-To: <046.4a378e75187677cb4dffb5ad70bf5920@localhost> References: <046.4a378e75187677cb4dffb5ad70bf5920@localhost> Message-ID: <055.06604c342c73df0c953a50803802e5f3@localhost> #3213: Failure in parsing a malformed LANGUAGE pragma ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report; duplicate of #3153. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 11 08:51:34 2009 From: trac at galois.com (GHC) Date: Tue May 12 04:19:32 2009 Subject: [GHC] #3214: "undefined reference to..." when compiling parallel code In-Reply-To: <048.1bcea8bd308db2861bde0326485cbaa9@localhost> References: <048.1bcea8bd308db2861bde0326485cbaa9@localhost> Message-ID: <057.fd4473a09b87ba9f896a05a39ec13cd9@localhost> #3214: "undefined reference to..." when compiling parallel code ------------------------------------+--------------------------------------- Reporter: fhsanches | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8 Severity: normal | Resolution: invalid Keywords: undefined reference | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Replying to [comment:2 fhsanches]: > Sigh, sorry for the flood here, I forgot to pass the "--make" flag to the compiler. I'm really, really sorry. Not at all - thanks for taking the time to help improve GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 11 09:53:22 2009 From: trac at galois.com (GHC) Date: Tue May 12 04:23:56 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.0fe64336c45419dc1fd13279eb1a86d1@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: simonmar => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 11 11:25:59 2009 From: trac at galois.com (GHC) Date: Tue May 12 04:29:17 2009 Subject: [GHC] #3218: Proposal: System.Posix.fdReadBuf/fdWriteBuf Message-ID: <047.b7cb1e3962f0323d9c43a62d2f6b6e90@localhost> #3218: Proposal: System.Posix.fdReadBuf/fdWriteBuf -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Functions for reading/writing actual arrays of bytes in memory. At the moment, `System.Posix` only provides {{{ fdRead :: Fd -> ByteCount -- ^How many bytes to read -> IO (String, ByteCount) -- ^The bytes read, how many bytes were read. fdWrite :: Fd -> String -> IO ByteCount }}} which are not only wrong (`String`?), but too slow for many purposes. I propose {{{ Mon May 11 16:21:02 BST 2009 Simon Marlow * add fdReadBuf, fdWriteBuf -- | Read data from an 'Fd' into memory. This is exactly equivalent -- to the POSIX @read@ function. fdReadBuf :: Fd -> Ptr Word8 -- ^ Memory in which to put the data -> ByteCount -- ^ Maximum number of bytes to read -> IO Bytecount -- ^ Number of bytes read (zero for EOF) -- | Write data from memory to an 'Fd'. This is exactly equivalent -- to the POSIX @write@ function. fdWriteBuf :: Fd -> Ptr Word8 -- ^ Memory containing the data to write -> ByteCount -- ^ Maximum number of bytes to write -> IO ByteCount -- ^ Number of bytes written }}} darcs patches are attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 11 17:39:16 2009 From: trac at galois.com (GHC) Date: Tue May 12 04:47:47 2009 Subject: [GHC] #3201: ar: Bad file number In-Reply-To: <047.ca53a7792b62a7186d0a18c99b7dae36@localhost> References: <047.ca53a7792b62a7186d0a18c99b7dae36@localhost> Message-ID: <056.6a764500dc4b08a7f96c50566c357570@localhost> #3201: ar: Bad file number -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by asklinge): * cc: asklingenberg@gmail.com (added) Comment: I get the same error. It appears to me to be a problem with xargs that does not realize it overflows the Windows command line, and passes truncated file names to `ar`. What I do to get GHC to build in MSYS is move `/bin/xargs.exe` to `/bin/_xargs.exe` and create an `xargs` shell script: {{{ #!/bin/sh _xargs -s 32767 $@ }}} And it works with `SplitObjs` enabled. Quicker than editing multiple Makefiles, but it's a hack. Maybe a solution is to set up a wrapper in the build system to call `xargs` in this fashion when building on MSYS? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 11 23:12:11 2009 From: trac at galois.com (GHC) Date: Tue May 12 05:02:35 2009 Subject: [GHC] #3219: functions on records with overloaded names can be given a too-specific type Message-ID: <044.143ec55a3248b988597db7e16741a0a4@localhost> #3219: functions on records with overloaded names can be given a too-specific type -----------------------------+---------------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Here's a reduced test-case showing a discrepancy between the symmetric functions `foo` and `bar`; the inferred type for `foo` is too specific. {{{ data T a = A{ m1 :: a } | B{ m1, m2 :: a } | C{ m2 :: a } -- bar :: (t -> a) -> T t -> T a bar f x@(A m) = x{m1 = f m} -- foo :: (a -> a) -> T a -> T a foo f x@(C m) = x{m2 = f m} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 05:36:07 2009 From: trac at galois.com (GHC) Date: Tue May 12 05:21:40 2009 Subject: [GHC] #3220: type variables appearing only in type equality constraints are not generalized Message-ID: <044.61e1ea4a3856a3ecde009628edb5e8f4@localhost> #3220: type variables appearing only in type equality constraints are not generalized -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- {{{ {-# LANGUAGE TypeFamilies, ScopedTypeVariables#-} class Foo m where type Bar m :: * action :: m -> Bar m -> m right x m = action m (Right x) right' :: (Either a b ~ Bar m, Foo m) => b -> m -> m right' x m = action m (Right x) instance Foo Int where type Bar Int = Either Int Int action m a = either (*) (+) a m main = print $ right (1::Int) (3 :: Int) }}} with the above code i get: {{{ *Main> :type right right :: (Either Int b ~ Bar m, Foo m) => b -> m -> m }}} without the main definition i get instead: {{{ *Main> :t right right :: (Either GHC.Prim.Any b ~ Bar m, Foo m) => b -> m -> m }}} while i expect the correct type to be the one of right'. It looks related to bug #1813 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 06:21:06 2009 From: trac at galois.com (GHC) Date: Tue May 12 06:06:20 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.286b1187b54e643603a84d2292810a48@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by claus): I'm no fan of either MonoMorphismRestriction or GHCi's extended defaulting rules (the '()' part, in particular), but I wonder whether adding yet another level of settings would really be an improvement. It is bad enough that GHCi doesn't easily inherit options/language flags from the modules it loads (if I work in a module that has, eg, `LANGUAGE QuasiQuotes`, I still need to `:set -XQuasiQuotes` in the GHCi session, and so on) - I wouldn't want to have to think about a third level of settings. But as long as there is a way for me never to let the various levels of settings get out of sync, I don't need to stand in the way of people who are really, really sure they want to do this to themselves.. >Arguably it'd be good to have a command to display the current flag settings (of either DynFlags) but that's another blob of work. Part of it is there, but it is complicated by the distinction between language and other options, as well as the sheer number of options GHC has accumulated. `:set` not only shows current *non-language* dynamic flag settings, it has a separate group for settings that are particularly likely to be relevant for working in GHCi. And `:show languages` shows currently active language flags. {{{ Prelude> :set options currently set: none. GHCi-specific dynamic flag settings: -fno-print-explicit-foralls -fno-print-bind-result -fno-break-on-exception -fno-break-on-error -fno-print-evld-with-show other dynamic, non-language, flag settings: -fwarn-dodgy-foreign-imports -fno-warn-dodgy-imports -fwarn-duplicate-exports -fno-warn-hi-shadowing ... }}} {{{ Prelude> :show languages active language flags: -XImplicitPrelude -XMonomorphismRestriction -XMonoPatBinds }}} I'm not exactly sure why this latter list is as it is (it was decided to show only non-default language flags there, but I've certainly not set `MonomorphismRestriction` explicitly)? Perhaps `:show languages` should be changed to show all language flag settings, with a separate group for non- default settings (or perhaps just listing for each entry whether or not it has the default setting, and use the separate group to highlight GHCi- specific flags instead, similar to `:set`)? But if users are not aware of the current settings, or the ways to display/change them, are they really going to be aware of another level of settings that influences what is going on? Could raising awareness of current possibilities achieve the same goal with less confusion? Talking about confusion, I had thought the '()' part of `ExtendedDefaultRules` was GHCi-only (or is this distinction part of what you are aiming for with this ticket?).. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 07:06:58 2009 From: trac at galois.com (GHC) Date: Tue May 12 06:52:12 2009 Subject: [GHC] #3219: functions on records with overloaded names can be given a too-specific type In-Reply-To: <044.143ec55a3248b988597db7e16741a0a4@localhost> References: <044.143ec55a3248b988597db7e16741a0a4@localhost> Message-ID: <053.fbe033ca95cd034667dbcb35d2df4d54@localhost> #3219: functions on records with overloaded names can be given a too-specific type ----------------------------------------+----------------------------------- Reporter: dmwit | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: What you say is true but depends, in a way that's invisible to the type system, on the pattern match on C. If you had {{{ -- foo1 :: (a -> a) -> T a -> T a foo1 f x = x{m2 = f m} }}} then indeed the inferred type would be right. For better or worse, the type system takes no account of which data constructors are matched in an enclosing context ''except'' for GADTs, and that is a different story. In short, this is more of a feature request than a bug, so I'll close it as invalid. If you want to make a feature request, by all means do, but personally I doubt that there'd be a big market for it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 07:43:10 2009 From: trac at galois.com (GHC) Date: Tue May 12 07:28:20 2009 Subject: [GHC] #3198: inliner fails to kick in for Double (*) In-Reply-To: <048.75717b4393891392703b39647b819ff8@localhost> References: <048.75717b4393891392703b39647b819ff8@localhost> Message-ID: <057.3f59e0771e847297c4403148500f3a9e@localhost> #3198: inliner fails to kick in for Double (*) ---------------------------------+------------------------------------------ Reporter: JulesBean | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Actually in the HEAD the inlining is kicking in: {{{ Print.a = \ (f_af9 :: GHC.Types.Double) (g_afb :: GHC.Types.Double) (eta_B1 :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.IO.a23 GHC.Handle.stdout (case f_af9 of _ { GHC.Types.D# x_aAO -> case g_afb of _ { GHC.Types.D# y_aAS -> GHC.Float.$w$sshowSignedFloat1 GHC.Float.$sshowFloat GHC.Base.zeroInt (GHC.Prim.*## x_aAO y_aAS) (GHC.Types.[] @ GHC.Types.Char) } }) eta_B1 of _ { (# new_s_azB, _ #) -> GHC.IO.$wa13 GHC.Handle.stdout '\n' new_s_azB } }}} Because the ''context'' of the call to `timesDouble` suggests that doing so is a good idea. I'm not quite sure why 6.10 does not do so, but it's not a big deal either way, so I think I'll close this ticket. Keep an eye out when we move to 6.12... there are quite a few changes to inlining in the pipeline, so we need vigilant users to tell us if there are regressions. thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 11:58:39 2009 From: trac at galois.com (GHC) Date: Tue May 12 11:43:57 2009 Subject: [GHC] #3221: Incorrect "defined but not used" warning for data types using deriving Message-ID: <051.1c3c57be6f72429406e355f3cf480220@localhost> #3221: Incorrect "defined but not used" warning for data types using deriving -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Consider: {{{ module Main() where import System data Foo = Bar | Baz deriving (Show,Read) main = do [x] <- getArgs print (read x :: Foo) }}} When we compile: {{{ $ ghc -c Test.hs -fwarn-unused-binds Test.hs:6:11: Warning: Defined but not used: data constructor `Bar' Test.hs:6:17: Warning: Defined but not used: data constructor `Baz' }}} This is incorrect. If a data type derives {{{Read}}}, {{{Enum}}} or {{{Bounded}}} (and for {{{Bounded}}}, is either the first or last element), then the values are used - even if not by name. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 12:05:48 2009 From: trac at galois.com (GHC) Date: Tue May 12 11:50:59 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.986d4616f66a053e4a73ccb90ca579cc@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): The trouble is that there already '''is''' another layer of settings for interactive expressions, namely the baked-in ones concerning extended defaults. The proposal here is to make that explicit, and controllable, rather than hidden and baked in. The hidden, baked-in version is vulnerable to feature request for new baking-in, such as #3202. If it was controllable, people could do that in their `.ghci` file. And if you want identical flags for both, then in your `.ghci` you can set the interactive flags to exactly match the batch flags. So I think its arguable that this ticket would make things simpler. The other simplicity approach would to insist that the interactive and batch flags were identical -- but that'd mean no extended defaults which people would hate. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 12:12:12 2009 From: trac at galois.com (GHC) Date: Tue May 12 11:57:25 2009 Subject: [GHC] #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 Message-ID: <053.190394749e5862e303daca81830a576b@localhost> #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 ---------------------------+------------------------------------------------ Reporter: GregFrascadore | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 ---------------------------+------------------------------------------------ Using GHC 6.10.3 to build GLFW 0.3 dies with: /usr/lib/gcc/i686-apple-darwin9/4.0.1/include/xmmintrin.h:35:3: error: #error "SSE instruction set not enabled" on Mac OSX 10.5.6 (intel) By downgrading to 6.10.1 the build works. I saw some IRC chat logs where others had this problem with 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 13:18:55 2009 From: trac at galois.com (GHC) Date: Tue May 12 13:04:14 2009 Subject: [GHC] #3179: Linking unix package fails In-Reply-To: <044.ae8162f5a98c9f4e805028c0bd796c43@localhost> References: <044.ae8162f5a98c9f4e805028c0bd796c43@localhost> Message-ID: <053.9bb452ef612154bc95574c3db505bfc4@localhost> #3179: Linking unix package fails ----------------------------+----------------------------------------------- Reporter: eelco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 6.10.2 Severity: major | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------------+----------------------------------------------- Comment (by antonvs): I ran into this exact error with GHC 6.10.3 on Debian 4.0, when trying to configure happstack with "runhaskell Setup.hs configure". There's a thread here which sheds more light on the problem: http://www.mail-archive.com/cvs-ghc@haskell.org/msg13274.html I attempted to use the workaround described in that thread, symlinking /usr/lib/librt.so to /lib/tls/librt.so.1, but then ran into other problems, e.g. doing "cabal install time" gave the following error: {{{ /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/librt.so: undefined reference to `__pthread_unwind@GLIBC_PRIVATE }}} However, I didn't rebuild GHC after changing the symlink (don't currently have time to experiment like that), so that may have been part of the problem. I've reverted to GHC 6.10.1, which doesn't have this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 13:31:33 2009 From: trac at galois.com (GHC) Date: Tue May 12 13:16:43 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.f65f50b3542142c5a52b3a7425f24bc5@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by claus): 1. Ok. In batch mode, in-source flags/options apply to the current module only, not to imports or importers, while commandline flags/options apply transitively to the whole session. In GHCi, there is currently no equivalent to the former, only to the latter. Your "interactive flags" that apply to the current session prompt only, not to code loaded during the session, would be the equivalent to GHCi prompt pragmas, just that you are suggesting a different syntax/interface. I agree that offering both prompt and session flags would be more consistent. I'm still slightly concerned about the interface, which could easily become more confusing rather than simpler. 2. This was beginning to sound more and more like deja vu (does that even apply to sounds?-), and indeed: "Change the meaning of -fextended-default- rules" #1877 3. In current GHC head, what baked-in rules are not switched off by `:set -XNoExtendedDefaults`? 4. While you're dealing with this, could you please remove the current inconsistency that in-source flags are not propagated to the interactive flags? Given module {{{ {-# LANGUAGE PatternGuards #-} f x | () <- x = x }}} I would expect to have `PatternGuards` available when GHCi is in `*Main` (as opposed to `Main`), but that isn't the case: {{{ Ok, modules loaded: Main. *Main> let g x | () <- x = x :1:8: Warning: accepting non-standard pattern guards (use -XPatternGuards to suppress this message) () <- x }}} and having to repeat all those pragma flags in the GHCi session is somewhat tedious. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 13:45:30 2009 From: trac at galois.com (GHC) Date: Tue May 12 13:30:39 2009 Subject: [GHC] #3223: please detect multiple kind errors in one run Message-ID: <041.880e4c2c759ec207fd4c53b9f6e72b3d@localhost> #3223: please detect multiple kind errors in one run -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- GHC 6.8 stops after the first kind error. Run one: {{{ cmm/ZDF5ex.hs:926:19: Kind error: `BackwardFixedPoint' is applied to too many type arguments In the type `BackwardFixedPoint m l e x a ()' In the type `ZipGF m l e x -> BackwardFixedPoint m l e x a ()' In the type `ZMaybe x a -> ZipGF m l e x -> BackwardFixedPoint m l e x a ()' }}} Run two: {{{ cmm/ZDF5ex.hs:420:31: Kind error: `ForwardFixedPoint' is applied to too many type arguments In the type `ForwardFixedPoint m l O C a (ZipGF m l O C)' In the type `FuelMonad (ForwardFixedPoint m l O C a (ZipGF m l O C))' In the type `ZipGF m l O C -> FuelMonad (ForwardFixedPoint m l O C a (ZipGF m l O C))' }}} These errors are in unrelated parts of the code and could both be detected on the same run. If this problem has already been fixed in 6.10, please accept my apologies ---6.10 has not hit Debian yet... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 14:00:41 2009 From: trac at galois.com (GHC) Date: Tue May 12 13:45:51 2009 Subject: [GHC] #3224: compiler panic: funResultTy base:GHC.Prim.*{(w) tc 34d} Message-ID: <041.327933e98ebcf6336e9bea2edc0ea59b@localhost> #3224: compiler panic: funResultTy base:GHC.Prim.*{(w) tc 34d} -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- To reproduce the panic, {{{ git clone linux.cs.tufts.edu:/r/ghc/git/experimental.git git pull -v origin/norman git branch --track norman origin/norman git checkout norman git revert b02c5c3 ## I'm a little shaky on this one }}} The failing compile command and its error message are: {{{ /usr/bin/ghc -#include cutils.h -DSTAGE=1 -package-name ghc-6.11.20090424 -hide-all-packages -no-user-package-conf -package-conf /usr/local/nr/git/ghc/experimental/libraries/bootstrapping.conf -i -idist- stage1/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist- stage1/build/autogen -Idist-stage1/build/autogen -Idist-stage1/build -Istage1 -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-include -optPdist- stage1/build/autogen/cabal_macros.h -odir dist-stage1/build -hidir dist- stage1/build -stubdir dist-stage1/build -package Cabal-1.7.0 -package array-0.1.0.0 -package base-3.0.1.0 -package bytestring-0.9.0.1 -package containers-0.1.0.1 -package directory-1.0.0.0 -package extensible- exceptions-0.1.1.0 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.0 -package process-1.0.0.0 -package unix-2.3.0.0 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XPatternSignatures -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -idist- stage1/build -Werror -H64m -O0 -fasm -Rghc-timing -c cmm/CmmLiveZ.hs -o dist-stage1/build/CmmLiveZ.o -ohi dist-stage1/build/CmmLiveZ.hi ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): funResultTy base:GHC.Prim.*{(w) tc 34d} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 14:18:03 2009 From: trac at galois.com (GHC) Date: Tue May 12 14:03:15 2009 Subject: [GHC] #3223: please detect multiple kind errors in one run In-Reply-To: <041.880e4c2c759ec207fd4c53b9f6e72b3d@localhost> References: <041.880e4c2c759ec207fd4c53b9f6e72b3d@localhost> Message-ID: <050.904dd668c7ae6cb68af9e8e7c5d9d2f3@localhost> #3223: please detect multiple kind errors in one run ------------------------------+--------------------------------------------- Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by nr): * version: 6.8.2 => 6.10.1 Comment: Confirmed in 6.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 14:28:15 2009 From: trac at galois.com (GHC) Date: Tue May 12 14:13:24 2009 Subject: [GHC] #3224: compiler panic: funResultTy base:GHC.Prim.*{(w) tc 34d} In-Reply-To: <041.327933e98ebcf6336e9bea2edc0ea59b@localhost> References: <041.327933e98ebcf6336e9bea2edc0ea59b@localhost> Message-ID: <050.5fbf8bcb8ae787a9c1377838b04eca61@localhost> #3224: compiler panic: funResultTy base:GHC.Prim.*{(w) tc 34d} ------------------------------+--------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by nr): I was not able to reproduce the panic using 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 14:35:24 2009 From: trac at galois.com (GHC) Date: Tue May 12 14:20:34 2009 Subject: [GHC] #3219: functions on records with overloaded names can be given a too-specific type In-Reply-To: <044.143ec55a3248b988597db7e16741a0a4@localhost> References: <044.143ec55a3248b988597db7e16741a0a4@localhost> Message-ID: <053.ce60809a73b38ac818552f491866638d@localhost> #3219: functions on records with overloaded names can be given a too-specific type ----------------------------------------+----------------------------------- Reporter: dmwit | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by dmwit): * status: closed => reopened * resolution: invalid => Comment: Okay, in that case, I'd like to change the bug description. =) It doesn't bother me so much that the type is too specific; what bothers me is the ''discrepancy'' between `foo` and `bar`. Why wouldn't your argument apply equally well to bar, leading us to expect an inferred type of `bar :: (a -> a) -> T a -> T a`? In other words, either both types should be general, or both types should be specific. I'm re-opening, but I've had my say; if you still consider it invalid, I'll quiesce. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 14:52:57 2009 From: trac at galois.com (GHC) Date: Tue May 12 14:38:05 2009 Subject: [GHC] #3225: Race/Async Exception issue in Network.Socket.connect Message-ID: <043.829bcef080104630e222d7f3dcc2bddd@localhost> #3225: Race/Async Exception issue in Network.Socket.connect -------------------+-------------------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- {{{ import Control.Concurrent import Control.Monad import Network.Socket import Control.Exception as C import System.Timeout import Network.BSD(hostAddresses, getHostByName) import System.IO.Error import Data.Maybe -- someHostName should be replaced by a real host that gives -- "connection refused" errors on connection to ports in the range. -- The latter ip is a junk one that should cause connections to -- hang indefinitely. -- More hostnames with either characteristic can be added to taste -- if that helps to reproduce the bug. servers = [ "someHostName", "126.255.255.255"] ports = [9001..9099] :: [Int] conns = [(h,p) | h <- servers, p <- ports] connectSock :: Integral a => String -> a -> IO Socket connectSock host port = do hn <- maybe (ioError . mkIOError doesNotExistErrorType "No Host Address" Nothing $ Just host) return . listToMaybe . hostAddresses =<< getHostByName host sk <- socket AF_INET Stream 6 connect sk (SockAddrInet (fromIntegral port) hn) `C.onException` sClose sk return sk pMapM f xs = mapM (\x -> forkIO $ f x) xs mapM' f xs = mapM (\x -> (C.try :: IO a -> IO (Either C.SomeException a)) (f x)) xs main = do -- This is the canary thread in the bugmine forkIO $ forever $ putStrLn "chirp" >> threadDelay 100000 -- This is the bug thread forever $ pMapM (\(h,p) -> timeout 1000000 (connectSock h p) >> return ()) conns >> threadDelay 2000000 }}} The above code, compiled with the threaded runtime, causes a race condition. After roughly one to two cycles of the bug thread, the canary thread stops running, indicating that the program has become somehow trashed. (The bug thread stops running as well). In experiments, this race condition is best triggered with at least two servers, one of which yields "connection refused" on connection, and the other of which simply hangs -- the nonsense ip address provided above works for the latter. if the pMapM is replaced by mapM' (i.e. we switch from parallel to serial connection) then the bug does not appear to be triggered. wrapping the call to sClose in a mutex didn't seem to help, so it seems the race condition is in the connect call. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 17:32:12 2009 From: trac at galois.com (GHC) Date: Tue May 12 17:17:19 2009 Subject: [GHC] #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 In-Reply-To: <053.190394749e5862e303daca81830a576b@localhost> References: <053.190394749e5862e303daca81830a576b@localhost> Message-ID: <062.635606aad26e4b36f051bc61b21da98c@localhost> #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 ----------------------------+----------------------------------------------- Reporter: GregFrascadore | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------------+----------------------------------------------- Comment (by judahj): You can work around this with {{{ cabal install GLFW --ghc-option=-optc-msse2 }}} But I don't fully understand what the cause of this problem is, or why it used to work in 6.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 12 23:56:53 2009 From: trac at galois.com (GHC) Date: Tue May 12 23:43:00 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build Message-ID: <041.af1846b041a640c6799f84ed05380953@localhost> #3226: please eliminate error message from Make on every build -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- If I attempt to build a .o file (which is my normal workflow), I ''always'' get this error message: {{{ ghc/ghc.mk:90: ghc/stage1/build/.depend: No such file or directory }}} If this outcome is expected (is it an early-phase thing?), it would be very, very nice to have stderr redirected. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 00:45:24 2009 From: trac at galois.com (GHC) Date: Wed May 13 00:31:05 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.a89877512ce7e56b65f888d580bfe691@localhost> #3226: please eliminate error message from Make on every build ------------------------------+--------------------------------------------- Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: trivial | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by nr): * severity: normal => trivial Comment: It turns out that by going directly to {{{Makefile-stage1}}} I can avoid this error message and also a powerful lot of futzing around. I probably lose some dependencies but it is worth it for the speed. I've knocked the severity down as low as possible; if someone wants to mark it wontfix, I won't bleat. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 03:21:54 2009 From: trac at galois.com (GHC) Date: Wed May 13 03:07:09 2009 Subject: [GHC] #3227: Can't specify type signature of value typed with type families Message-ID: <053.f2241e5897f488c1187ec1e6a30b7764@localhost> #3227: Can't specify type signature of value typed with type families ---------------------------+------------------------------------------------ Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---------------------------+------------------------------------------------ Compiling this: {{{ {-# LANGUAGE TypeFamilies #-} module Bug where class C a where type T a p :: T a p = undefined q :: T a q = p }}} give this: {{{ $ ghc -c Bug.hs -o Bug.o Bug.hs:10:6: Couldn't match expected type `T a1' against inferred type `T a' In the expression: p In the definition of `q': q = p }}} It compiles successfully if the type signature for `q` is omitted. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.3 $ uname -a Linux glastonbury 2.6.28-12-generic #43-Ubuntu SMP Fri May 1 19:31:32 UTC 2009 x86_64 GNU/Linux }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 05:31:27 2009 From: trac at galois.com (GHC) Date: Wed May 13 05:16:44 2009 Subject: [GHC] #1897: Ambiguous types and rejected type signatures In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.b21149f37ce0ccee8342f57e4d5c3098@localhost> #1897: Ambiguous types and rejected type signatures ----------------------------------------+----------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Comment (by simonpj): See also #3227. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 05:32:21 2009 From: trac at galois.com (GHC) Date: Wed May 13 05:17:23 2009 Subject: [GHC] #3227: Can't specify type signature of value typed with type families In-Reply-To: <053.f2241e5897f488c1187ec1e6a30b7764@localhost> References: <053.f2241e5897f488c1187ec1e6a30b7764@localhost> Message-ID: <062.57be8b2d5f7aeb4db9980587414389f5@localhost> #3227: Can't specify type signature of value typed with type families -------------------------------+-------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks. This is a duplicate of #1897 -- see extensive comments there. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 05:45:31 2009 From: trac at galois.com (GHC) Date: Wed May 13 05:30:35 2009 Subject: [GHC] #3225: Race/Async Exception issue in Network.Socket.connect In-Reply-To: <043.829bcef080104630e222d7f3dcc2bddd@localhost> References: <043.829bcef080104630e222d7f3dcc2bddd@localhost> Message-ID: <052.9df22057799a0db6bbf6af12e6c7745b@localhost> #3225: Race/Async Exception issue in Network.Socket.connect -------------------------------+-------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/network | Version: 6.10.3 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------------------+-------------------------------------------- Changes (by tibbe): * status: new => closed * resolution: => invalid Comment: Moved to http://trac.haskell.org/network/ticket/9 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 06:01:31 2009 From: trac at galois.com (GHC) Date: Wed May 13 05:46:37 2009 Subject: [GHC] #3143: Network.Socket.connect: support for sockets w/ bound local endpoints In-Reply-To: <042.e4e98b4e6662bbe35f8aa7664f1d58cb@localhost> References: <042.e4e98b4e6662bbe35f8aa7664f1d58cb@localhost> Message-ID: <051.83b703610cb29acb4c0e5dcadb2dd49c@localhost> #3143: Network.Socket.connect: support for sockets w/ bound local endpoints -------------------------------+-------------------------------------------- Reporter: sof | Owner: tibbe Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by tibbe): * status: assigned => closed * resolution: => invalid Comment: Moved to http://trac.haskell.org/network/ticket/10 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 06:05:04 2009 From: trac at galois.com (GHC) Date: Wed May 13 05:50:08 2009 Subject: [GHC] #3218: Proposal: System.Posix.fdReadBuf/fdWriteBuf In-Reply-To: <047.b7cb1e3962f0323d9c43a62d2f6b6e90@localhost> References: <047.b7cb1e3962f0323d9c43a62d2f6b6e90@localhost> Message-ID: <056.aa7685457109e4617cf12ea144e1ef7f@localhost> #3218: Proposal: System.Posix.fdReadBuf/fdWriteBuf ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 06:13:24 2009 From: trac at galois.com (GHC) Date: Wed May 13 05:58:34 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.103a2fe1bfee6f8e466ea8698d23ab3d@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:3 claus]: > 4. While you're dealing with this, could you please remove the current inconsistency that in-source flags are not propagated to the interactive flags? Given module > {{{ > {-# LANGUAGE PatternGuards #-} > > f x | () <- x = x > }}} > I would expect to have `PatternGuards` available when GHCi is in `*Main` (as opposed to `Main`), but that isn't the case: What do you want to happen when there are multiple modules in scope at the prompt? Take the union of the flags? What if they are contradictory? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 06:56:21 2009 From: trac at galois.com (GHC) Date: Wed May 13 06:41:31 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.9e84ed0dc45aa1c2d50e40f4c2f93685@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by claus): > > 4. While you're dealing with this, could you please remove the current inconsistency that in-source flags are not propagated to the interactive flags? > What do you want to happen when there are multiple modules in scope at the prompt? Take the union of the flags? What if they are contradictory? According to [http://www.haskell.org/ghc/docs/latest/html/users_guide /interactive-evaluation.html#ghci-scope]: The syntax *module indicates that it is the full top-level scope of module that is contributing to the scope for expressions typed at the prompt. Without the *, just the exports of the module are visible. .. GHCi combines the scopes from all of these modules to form the scope that is in effect at the prompt. Naively, I'd interpret that as meaning that the scopes are merged/unioned, and that the scopes have to be compatible for this to succeed. I'd just like this behaviour to be consistently applied to all of the module (if I were to add both `Data.Map` and `Data.IntMap`, things like `empty` would become ambiguous, so such contradictions aren't new). If I'm *in* the top-level scope, the view from the prompt should be the same as from within the module. If I'm trying to combine scopes that couldn't possibly be part of a single module, I'd like to know (eg., I'd be tempted to classify `:m +*Data.Map +*Data.IntMap` as an error, even if the source are available, on the rationale that `:m +mod` means `import` while `:m +*mod` means `include`). Apart from in-source pragmas, GHCi also ignores `default` declarations, which used to bite me when I was still using `default`. Given {{{ import Data.Ratio default (Ratio Int) }}} compare GHCi's {{{ *Main> 1 1 }}} with Hugs' {{{ Main> 1 1 % 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 07:25:49 2009 From: trac at galois.com (GHC) Date: Wed May 13 07:10:54 2009 Subject: [GHC] #788: Class aliases (as proposaed by John Meacham) In-Reply-To: <046.352573f276ea0b65a1451eea70e3a225@localhost> References: <046.352573f276ea0b65a1451eea70e3a225@localhost> Message-ID: <055.2c65494c1feaf274c8b9f85a9a594927@localhost> #788: Class aliases (as proposaed by John Meacham) ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): See also * http://www.haskell.org/haskellwiki/Hac5/Projects#Type_class_aliases -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 09:28:55 2009 From: trac at galois.com (GHC) Date: Wed May 13 09:13:59 2009 Subject: [GHC] #3211: Typos in RTS documentation In-Reply-To: <044.ffb7a01a62d3159b407a9f3ce1e13679@localhost> References: <044.ffb7a01a62d3159b407a9f3ce1e13679@localhost> Message-ID: <053.03e74523e768cbdfc5778f6b29535a72@localhost> #3211: Typos in RTS documentation ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 09:29:14 2009 From: trac at galois.com (GHC) Date: Wed May 13 09:14:18 2009 Subject: [GHC] #3211: Typos in RTS documentation In-Reply-To: <044.ffb7a01a62d3159b407a9f3ce1e13679@localhost> References: <044.ffb7a01a62d3159b407a9f3ce1e13679@localhost> Message-ID: <053.71f028d9610d55e2f95099e098d97397@localhost> #3211: Typos in RTS documentation ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): {{{ Mon May 11 07:49:35 PDT 2009 Simon Marlow * updates to the section describing the +RTS -s/-S output (#3211) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 10:33:39 2009 From: trac at galois.com (GHC) Date: Wed May 13 10:18:58 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.b89777716fcd0530a05004ccd7100a2d@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:5 claus]: > (eg., I'd be tempted to classify `:m +*Data.Map +*Data.IntMap` as an error, even if the source are available, on the rationale that `:m +mod` means `import` while `:m +*mod` means `include`). I'd be tempted to agree, although this is a fairly deep change. The context is currently `([Module],[Module])`, this would mean changing it to `Either Module [Module]`, or perhaps `([Module], Maybe Module)`. Probably this ought to be done at the same time as allowing general import declarations (#2362), since that also changes the type here. If we made this change, then I think it makes sense to take into account the flags and defaults of the "current" module. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 11:45:13 2009 From: trac at galois.com (GHC) Date: Wed May 13 11:30:42 2009 Subject: [GHC] #1633: Improve error message for kind mismatches In-Reply-To: <044.335aa326f8322714457d647c9ee54c0f@localhost> References: <044.335aa326f8322714457d647c9ee54c0f@localhost> Message-ID: <053.b91197229f6a0ac7d0ae3202691f635e@localhost> #1633: Improve error message for kind mismatches --------------------------------------------+------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12 branch Component: Documentation | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/T1633 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T1633 * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Wed May 13 16:11:30 BST 2009 simonpj@microsoft.com * Improve error reporting for kind errors (fix Trac #1633) A long-standing improvement to the error message for kinds. Now instead of Expected kind `* -> *', but `Int' has kind `*' we get The first argument of `T' should have kind `* -> *', but `Int' has kind `*' }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 11:49:26 2009 From: trac at galois.com (GHC) Date: Wed May 13 11:34:56 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.723d93f7b51a4a74cb3c9d3f90d9feb6@localhost> #3226: please eliminate error message from Make on every build ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: `Makefile-stage1` doesn't exist any more - what GHC version are you building here? The missing `.depend` file errors are annoying, but unfortunately not easy to silence. I think I remember coming across a trick somewhere for shutting them up, but can't remember where it was now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 11:50:03 2009 From: trac at galois.com (GHC) Date: Wed May 13 11:35:11 2009 Subject: [GHC] #3219: functions on records with overloaded names can be given a too-specific type In-Reply-To: <044.143ec55a3248b988597db7e16741a0a4@localhost> References: <044.143ec55a3248b988597db7e16741a0a4@localhost> Message-ID: <053.f5e1b4413030d31d7dddf33a4752ff60@localhost> #3219: functions on records with overloaded names can be given a too-specific type -----------------------------------------------+---------------------------- Reporter: dmwit | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T3219 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------+---------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T3219 * status: reopened => closed * resolution: => fixed Comment: Aha! I was looking only at `bar`, for which my claims are correct. I ignored `foo`, and you are quite right: `foo`'s inferred type is utterly wrong. And indeed, compiling your code with `-dcore-lint` barfs in GHC 6.10. Fixed by this patch, with a test case added to the regression suite: {{{ Wed May 13 16:09:22 BST 2009 simonpj@microsoft.com * Fix Trac #3219: type of a record update Record updates are amazingly hard to typecheck right. This is one place where GHC's policy of typechecking the original source is much harder than desugaring and typechecking that! Anyway, the bug here is that to compute the 'fixed' type variables I was only looking at one constructor rather than all the relevant_cons }}} Thank you for being persistent. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 12:03:21 2009 From: trac at galois.com (GHC) Date: Wed May 13 11:48:44 2009 Subject: [GHC] #3224: compiler panic: funResultTy base:GHC.Prim.*{(w) tc 34d} In-Reply-To: <041.327933e98ebcf6336e9bea2edc0ea59b@localhost> References: <041.327933e98ebcf6336e9bea2edc0ea59b@localhost> Message-ID: <050.53e2e01a1343f0d2757689763c9847de@localhost> #3224: compiler panic: funResultTy base:GHC.Prim.*{(w) tc 34d} ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown * milestone: => 6.8 branch Comment: OK well I'll assume it's ok in 6.10 and HEAD, and therefore milestone it for the 6.8 branch (which is essentially dead). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 13:17:20 2009 From: trac at galois.com (GHC) Date: Wed May 13 13:02:27 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.37c02573e7d4eaa2005bb0c78b1b8328@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by claus): > > (eg., I'd be tempted to classify `:m +*Data.Map +*Data.IntMap` as an error, even if the source are available, on the rationale that `:m +mod` means `import` while `:m +*mod` means `include`). > > I'd be tempted to agree, although this is a fairly deep change. The context is currently `([Module],[Module])`, this would mean changing it to `Either Module [Module]`, or perhaps `([Module], Maybe Module)`. I probably misunderstand your intentions there, but `([Module],[Module])` should be fine (assuming that this lists `*`-ed and other modules separately), as long as only modules with compatible pragmas, defaults, and bindings can be added to the `*`-ed modules list. The `*Data.Map`/`*Data.IntMap` example would fail only because both define the same names (which is possible in `import`/`:m +mod`, but not in `include`/`:m +*mod`). > If we made this change, then I think it makes sense to take into account the flags and defaults of the "current" module. Thanks. I think I could live with only one `*`-ed module, if that was necessary to get this consistency, but there's no telling what wonderful uses other GHCi users have come up with, or what their preferences are.. So permitting multiple `*`-ed modules sounds safer - just adding the requirement that they have to be compatible. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 14:50:14 2009 From: trac at galois.com (GHC) Date: Wed May 13 14:35:21 2009 Subject: [GHC] #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 In-Reply-To: <053.190394749e5862e303daca81830a576b@localhost> References: <053.190394749e5862e303daca81830a576b@localhost> Message-ID: <062.24c4b85fb5a40d335c91dff8b5ae9d16@localhost> #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 -------------------------------+-------------------------------------------- Reporter: GregFrascadore | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: Sounds like #2983 broke it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 13 15:00:59 2009 From: trac at galois.com (GHC) Date: Wed May 13 14:46:09 2009 Subject: [GHC] #3223: please detect multiple kind errors in one run In-Reply-To: <041.880e4c2c759ec207fd4c53b9f6e72b3d@localhost> References: <041.880e4c2c759ec207fd4c53b9f6e72b3d@localhost> Message-ID: <050.90f6b062e5c0f45a7e930ae56df20080@localhost> #3223: please detect multiple kind errors in one run ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: With this module: {{{ type F a = Char type G a = Bool f :: F Float Double f = 'c' g :: G Float Double g = True }}} I can reproduce this with 6.8.2: {{{ GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( f.hs, interpreted ) f.hs:9:5: Kind error: `G' is applied to too many type arguments In the type `G Float Double' In the type signature for `g': g :: G Float Double Failed, modules loaded: none. Prelude> }}} but not the HEAD or 6.10, e.g.: {{{ GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( f.hs, interpreted ) f.hs:6:5: Kind error: `F' is applied to too many type arguments In the type `F Float Double' In the type signature for `f': f :: F Float Double f.hs:9:5: Kind error: `G' is applied to too many type arguments In the type `G Float Double' In the type signature for `g': g :: G Float Double Failed, modules loaded: none. Prelude> }}} so I think that this has already been fixed. If you still think it's broken, please reopen and attach a testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 14 11:09:14 2009 From: trac at galois.com (GHC) Date: Thu May 14 10:54:16 2009 Subject: [GHC] #3223: please detect multiple kind errors in one run In-Reply-To: <041.880e4c2c759ec207fd4c53b9f6e72b3d@localhost> References: <041.880e4c2c759ec207fd4c53b9f6e72b3d@localhost> Message-ID: <050.5ed529061b94fb97b3f58193a6d722ec@localhost> #3223: please detect multiple kind errors in one run ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): I cannot reproduce this either with 6.10.1. I've tried modifying `ZDF5ex.hs` (as of today), lines 417 and 922, and I get both kind errors in one sweep. {{{ compiler\cmm\ZDF5ex.hs:417:31: Kind error: `ForwardFixedPoint' is applied to too many type arguments In the type `ForwardFixedPoint m l O C a (ZipGF m l O C)' In the type `FuelMonad (ForwardFixedPoint m l O C a (ZipGF m l O C))' In the type `ZipGF m l O C -> FuelMonad (ForwardFixedPoint m l O C a (ZipGF m l O C))' compiler\cmm\ZDF5ex.hs:922:19: Kind error: `BackwardFixedPoint' is applied to too many type arguments In the type `BackwardFixedPoint m l O C a ()' In the type `ZipGF m l O C -> BackwardFixedPoint m l O C a ()' In the type `BackwardTransfers m l a -> ZipGF m l O C -> BackwardFixedPoint m l O C a ()' }}} If you can give us a repro case, I'll look at it some more. It's possible there is something wrong... after all you said it was still the case with 6.10.1. Pls re-open if you can see it again. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 14 12:25:04 2009 From: trac at galois.com (GHC) Date: Thu May 14 12:10:11 2009 Subject: [GHC] #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function In-Reply-To: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> References: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> Message-ID: <055.32d54fc369f875469ec082a2e04a3254@localhost> #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by fasta): I don't really believe in the "too much overhead" argument, until there is a clear analysis, which demonstrates this. It's often possible during debugging to create a small test case (one which does not take a long time to run). So, even recording all the state changes in the machine would be possible. I also argue that this should be the default. If it is too slow, people would just use some approximation (like is currently being done). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 14 14:15:58 2009 From: trac at galois.com (GHC) Date: Thu May 14 14:02:27 2009 Subject: [GHC] #3128: hClose leaves file descriptor open if it fails In-Reply-To: <045.f474a379b598a39e20f417ce0f4de22b@localhost> References: <045.f474a379b598a39e20f417ce0f4de22b@localhost> Message-ID: <054.bd05544d32134a0184f89f2f19ba9ad0@localhost> #3128: hClose leaves file descriptor open if it fails ---------------------------------+------------------------------------------ Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by Baughn): I would like to add that Handles *should* contain an MVar (Maybe FD) or some such instead of just an FD. Or, rather, after a handle is hClosed - and the socket goes away - it ought to be impossible to use that handle for anything whatsoever. As it is now, it's possible for the FD to be reused, and for code that reuses the closed Handle to touch someone else's FD. This may not violate the haskell spec, but neither would code where you can't do that, and the cost would be trivial. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 14 16:02:42 2009 From: trac at galois.com (GHC) Date: Thu May 14 15:48:43 2009 Subject: [GHC] #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function In-Reply-To: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> References: <046.6f550a6976a51e80c9bdb4b574c0fab8@localhost> Message-ID: <055.cb52fe3aa11edb337d1b68ea08e41c7d@localhost> #2737: add :tracelocal to ghci debugger to trace only the expressions in a given function ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by phercek): Maybe the analysis was done, at least partially. [http://www.haskell.org/~simonmar/papers/ghci-debug.pdf A Lightweight Interactive Debugger for Haskell] paper indicates so at the end of chapter 4.3.[[BR]] As for as the filtering of the trace history, it is not about performace savings but making sure that the right stuff is in it. A possibility of detailed filtering what goes into the trace log is important. I discussed it in this message [http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/16270 my experience with ghci debugger extensions].[[BR]] Btw, a new version of {{{GhciExt}}} (0.6) is available [http://www.hck.sk/users/peter/pub/ here]. It does not require prefixing with {{{:x}}} any more and works with stock ghc 6.10.3. No custom patches to ghc are needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 14 16:31:36 2009 From: trac at galois.com (GHC) Date: Thu May 14 16:16:48 2009 Subject: [GHC] #2946: tracing should be controled by a global flag In-Reply-To: <046.683eb7b4d5d0c38dcae8da9a304188ed@localhost> References: <046.683eb7b4d5d0c38dcae8da9a304188ed@localhost> Message-ID: <055.58103c102e78bde5a908eef2246a5046@localhost> #2946: tracing should be controled by a global flag ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by phercek): * summary: tracing should be controled by a global flag (it should not be resume context specific) => tracing should be controled by a global flag Comment: As I discussed in message [http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/16270 my experience with ghci debugger extensions], the {{{:set trace}}} should have a grammar like this:[[BR]] {{{ -- should everything be traced? :set trace (True|False) -- scopes which should be traced (or should not be traced when ! is present) :set trace ( (!)? scopeid )* -- add/remove individual scopeids to/from the trace specification :set trace (+|-) (!)? scopeid -- scopeid = ( conid . )* ( varid . )* varid | { breakPointArgs } }}} {{{scopeId}}} can be specified by its hierarchical identifier or by breakpoint arguments in curly braces. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 14 16:33:38 2009 From: trac at galois.com (GHC) Date: Thu May 14 16:18:37 2009 Subject: [GHC] #3228: please make it easier to remove a file from the GHC sources Message-ID: <041.5dbccaa2009317c73dad3a60d2601df8@localhost> #3228: please make it easier to remove a file from the GHC sources ----------------------------+----------------------------------------------- Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------------+----------------------------------------------- I'm trying to remove some obsolete code from GHC's back end. (It will live forever in darcs). The only workflow I can find that works is {{{ cd $TOP ./configure (cd compiler; make -k -j 5) }}} This workflow is really expensive; on a 4-processor machine it is costing me 48 seconds every time I remove a file... Norman -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 14 16:45:31 2009 From: trac at galois.com (GHC) Date: Thu May 14 16:30:39 2009 Subject: [GHC] #2945: add command :mergetrace In-Reply-To: <046.a1eed06b62edc58c92c0397ae05d5c35@localhost> References: <046.a1eed06b62edc58c92c0397ae05d5c35@localhost> Message-ID: <055.2c10a5e86dcd42ef8149e815481268bc@localhost> #2945: add command :mergetrace ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by phercek): * summary: trace history should be global or add command :mergetrace => add command :mergetrace Comment: {{{:mergetrace}}} is better than a global trace history. Being able to investigate something separately in a nested context is useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 14 17:47:55 2009 From: trac at galois.com (GHC) Date: Thu May 14 17:32:55 2009 Subject: [GHC] #3229: queued GHCi commands are not resume context specific Message-ID: <046.c79a02c73014f0a1866970c1d8f5c8e9@localhost> #3229: queued GHCi commands are not resume context specific -----------------------------+---------------------------------------------- Reporter: phercek | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: normal Keywords: debugger | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I think it is a bug that the second part ({{{:continue}}}) of the command {{{:cmd return "rv\n:continue"}}} is executed in a different context than the first part (rv (request for the value of rv variable)). Notice that we did not stop at breakpoint 1 (line 7). Well, the stop happened but it continued immediately because of queued {{{:continue}}} command. But the command was queued in the context of breakpoint 0 and not breakpoint 1. {{{ status:0 peter@metod [716] ~/tmp % grep -n '^' b.hs 1:fn :: Int -> Int 2:fn x = 3: let rv = add x 1 in 4: rv 5: 6:add :: Int -> Int -> Int 7:add a b = a + b status:0 peter@metod [717] ~/tmp % ghci b.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( b.hs, interpreted ) Ok, modules loaded: Main. *Main> :set stop :list *Main> :break 4 Breakpoint 0 activated at b.hs:4:2-3 *Main> :break 7 Breakpoint 1 activated at b.hs:7:0-14 *Main> fn 100 Stopped at b.hs:4:2-3 _result :: Int = _ rv :: Int = _ 3 let rv = add x 1 in 4 rv 5 [b.hs:4:2-3] *Main> :cmd return "rv\n:continue" Stopped at b.hs:7:0-14 _result :: Int = _ 6 add :: Int -> Int -> Int 7 add a b = a + b 8 101 [b.hs:4:2-3] *Main> :continue 101 *Main> :q Leaving GHCi. status:0 peter@metod [718] ~/tmp % }}} The log was done with 6.10.1 but it is the same with 6.10.3.[[BR]] I posted about this to the ghc users list about 2 months ago but nobody responded. My guess is nobody minds either way since nobody scripts breakpoints. At least it would be fine to know whether a patch fixing this has a chance to be accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 14 17:57:33 2009 From: trac at galois.com (GHC) Date: Thu May 14 17:42:32 2009 Subject: [GHC] #3230: Build fails with cabal-bin complaining Message-ID: <044.5ebb87f68ffd93427e47d23d9f5ebb95@localhost> #3230: Build fails with cabal-bin complaining -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- The build of ghc 6.10.3 and 6.10.2 (I haven't tested others) on a Debian Etch (ghc 6.6) system fails like so (I am attaching a complete log as well): {{{ Configuring ghc-6.10.3... cabal-bin: At least the following dependencies are missing: Cabal -any, base <3, filepath >=1 && <1.2, haskell98 -any, hpc -any, template-haskell -any, unix -any make[3]: *** [boot.stage.2] Error 1 }}} I am trying to build using the following Makefile (which ought to work based on my understanding of http://hackage.haskell.org/trac/ghc/wiki/Building/Using): {{{ #!/usr/bin/make -f ghc_version := 6.10.3 ghc_dir := ghc-$(ghc_version) .PHONY: ghc ghc: rm -rf $(ghc_dir)/ tar -xjf ghc-$(ghc_version)-src.tar.bz2 tar -xjf ghc-$(ghc_version)-src-extralibs.tar.bz2 cd $(ghc_dir)/ && ./configure --prefix=/tmp/g sed -e 's@^#BuildFlavour = quickest@BuildFlavour = quickest@' $(ghc_dir)/mk/build.mk.sample \ >$(ghc_dir)/mk/build.mk $(MAKE) -C $(ghc_dir) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 14 21:27:42 2009 From: trac at galois.com (GHC) Date: Thu May 14 21:13:45 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.621d49fb4eee10532a9cc94f992021e0@localhost> #3226: please eliminate error message from Make on every build ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by nr): I just pulled from the darcs head a few days ago, so I presume I'm building 6.11. I don't know where {{{Makefile-stage1}}} comes from---maybe it is a stale version from a while back---but it is very, very useful. Comparing {{{ make -f Makefile dist/stage1/ZipGF.o }}} and {{{ make -f Makefile-stage1 dist/stage1/ZipGF.o }}} the second is considerably faster. I basically am asking for a fast path to attempt to compile a .o file from possibly stale dependencies. I am very, very eager to trade accuracy for speed here. If something strange happens I can always resort to the full Makefile. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 14 21:29:50 2009 From: trac at galois.com (GHC) Date: Thu May 14 21:15:49 2009 Subject: [GHC] #3223: please detect multiple kind errors in one run In-Reply-To: <041.880e4c2c759ec207fd4c53b9f6e72b3d@localhost> References: <041.880e4c2c759ec207fd4c53b9f6e72b3d@localhost> Message-ID: <050.27ce31f10f55c3b76f7e52da2c8e01ee@localhost> #3223: please detect multiple kind errors in one run ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by nr): I have now upgraded to 6.10, and this bug should stay closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 03:23:36 2009 From: trac at galois.com (GHC) Date: Fri May 15 03:08:48 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.0e6b65d9b17cfa17be8a2a39a8b52d50@localhost> #3226: please eliminate error message from Make on every build ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Try {{{ make 1 }}} http://hackage.haskell.org/trac/ghc/wiki/Building/Using#RebuildingtheGHCbinaryaftermakingchanges Does that do it? If the above documentation isn't clear enough, or isn't easy enough to find, could you modify it so that it is? It's a wiki. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 03:24:42 2009 From: trac at galois.com (GHC) Date: Fri May 15 03:09:38 2009 Subject: [GHC] #3223: please detect multiple kind errors in one run In-Reply-To: <041.880e4c2c759ec207fd4c53b9f6e72b3d@localhost> References: <041.880e4c2c759ec207fd4c53b9f6e72b3d@localhost> Message-ID: <050.ee09bc61d021f8484657cd03e36e9d04@localhost> #3223: please detect multiple kind errors in one run ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): But the first comment (as opposed to the initial report) confirmed that the bug is present in 6.10.1. That's what's puzzling me. I don't want to lose a good bug! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 05:48:12 2009 From: trac at galois.com (GHC) Date: Fri May 15 05:33:07 2009 Subject: [GHC] #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets In-Reply-To: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> References: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> Message-ID: <056.242fb0ff7183af966495f7e7107a828b@localhost> #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets ----------------------------------+----------------------------------------- Reporter: tphyahoo | Owner: bos Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: ipv6 | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by tibbe): * status: assigned => closed * resolution: => invalid Comment: Moved to http://trac.haskell.org/network/ticket/11 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 05:50:29 2009 From: trac at galois.com (GHC) Date: Fri May 15 05:35:51 2009 Subject: [GHC] #2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6 In-Reply-To: <042.cebcc11cc6f8e024f65fef292f8041c0@localhost> References: <042.cebcc11cc6f8e024f65fef292f8041c0@localhost> Message-ID: <051.a0c906ac12cbdd8a15fa58f4e25e5042@localhost> #2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6 ----------------------------------+----------------------------------------- Reporter: cjs | Owner: bos Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by tibbe): * status: assigned => closed * resolution: => invalid Comment: Moved to http://trac.haskell.org/network/ticket/11 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 05:54:53 2009 From: trac at galois.com (GHC) Date: Fri May 15 05:39:48 2009 Subject: [GHC] #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets In-Reply-To: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> References: <047.773dd46e6700c0ac7f0c440c515fe3d9@localhost> Message-ID: <056.d0c43e6efae1c8f7e35ef4eeeec99382@localhost> #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets ----------------------------------+----------------------------------------- Reporter: tphyahoo | Owner: bos Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: ipv6 | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by tibbe): Correction, moved to http://trac.haskell.org/network/ticket/12 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 06:04:34 2009 From: trac at galois.com (GHC) Date: Fri May 15 05:49:33 2009 Subject: [GHC] #2924: createDirectory: permission denied In-Reply-To: <047.7f5e4787e0730bc3878fcff588107d39@localhost> References: <047.7f5e4787e0730bc3878fcff588107d39@localhost> Message-ID: <056.0c62dd13a5bf718bd8e70af90bc6084a@localhost> #2924: createDirectory: permission denied ------------------------------------+--------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ------------------------------------+--------------------------------------- Comment (by NeilMitchell): I'm as sure as I can be that I'm not leaking handles. I've gone through their bug reports, and I think their issue was their fault (not releasing resources), but mine is the fault of some combination of Cygwin/Mingw/GHC/Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 06:07:39 2009 From: trac at galois.com (GHC) Date: Fri May 15 05:52:35 2009 Subject: [GHC] #2924: createDirectory: permission denied In-Reply-To: <047.7f5e4787e0730bc3878fcff588107d39@localhost> References: <047.7f5e4787e0730bc3878fcff588107d39@localhost> Message-ID: <056.55f26a86ac010cb324c71082691219a1@localhost> #2924: createDirectory: permission denied ------------------------------------+--------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ------------------------------------+--------------------------------------- Comment (by NeilMitchell): I've also seen problems similar to this on Linux, so it's possible the bug is actually cross platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 06:07:55 2009 From: trac at galois.com (GHC) Date: Fri May 15 05:52:51 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile Message-ID: <051.9654be8110cd7a09257c98a211221fb3@localhost> #3231: Permission denied error with runProcess/openFile -------------------------+-------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple -------------------------+-------------------------------------------------- Given this program: {{{ module Main() where import Control.Concurrent import System.IO import System.Process main = do hSetBuffering stdout NoBuffering forkIO $ f "foo1.txt" forkIO $ f "foo2.txt" threadDelay $ 100*1000000 putStrLn "Finished successfully" f file = do h <- openFile file AppendMode hPutStrLn h "fakdjsklj" putChar '.' pid <- runProcess "sh" ["-c","sleep 0.1s"] Nothing Nothing Nothing (Just h) (Just h) waitForProcess pid f file }}} Running under Cygwin, in GHC 6.10.2, I get: {{{ $ runhaskell Test.hs ..Test.hs: foo1.txt: openFile: permission denied (Permission denied) }}} It shouldn't - the {{{openFile}}} calls should always succeed. This bug is a reduced test case from a real system, which I papered over with: {{{ retryIO :: IO a -> IO a retryIO act = catchIO act $ \x -> do threadDelay $ 1 * 1000000 -- 1 second performGC act }}} Now calling {{{retryIO $ openFile ...}}} works reliably. These problems are occurring sufficiently often that {{{retryIO}}} is about to go in to our standard library :-) This may be related to #2924, but has the advantage of replicating easily. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 06:08:22 2009 From: trac at galois.com (GHC) Date: Fri May 15 05:53:19 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.c7163587dd4fb3973b2e320f9c20e467@localhost> #3231: Permission denied error with runProcess/openFile --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 06:22:13 2009 From: trac at galois.com (GHC) Date: Fri May 15 06:07:08 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.565657abfe960d5f8b4a216557f9b16e@localhost> #3231: Permission denied error with runProcess/openFile --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by NeilMitchell): I have just tested, and this bug does not occur under Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 06:44:54 2009 From: trac at galois.com (GHC) Date: Fri May 15 06:29:50 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.283db1edbb5efe0083fb5aa6bc7eaccd@localhost> #3231: Permission denied error with runProcess/openFile --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by NeilMitchell): Another version, this time not tying the process to a handle: {{{ module Main() where import Control.Concurrent import System.IO import System.Cmd import System.Directory main = do hSetBuffering stdout NoBuffering forkIO $ f "foo1.txt" forkIO $ f "foo2.txt" threadDelay $ 100*1000000 putStrLn "Finished successfully" f file = do h <- openFile file WriteMode hPutStrLn h "fjkladsf" system "sleep 1s" putChar '.' hClose h removeFile file f file }}} This version fails under both Cygwin and from the Windows command prompt with: {{{ $ runhaskell Test.hs .Test.hs: DeleteFile: permission denied (The process cannot access the file beca use it is being used by another process.) }}} This version works fine if the {{{system}}} call is removed. That call shouldn't have any difference to the usage of any handles. It seems that system calls mess with handles and resources in painful ways. This is now almost certainly the same underlying cause as the problems I reported in bug #2924. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 06:46:22 2009 From: trac at galois.com (GHC) Date: Fri May 15 06:31:18 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.cee4b89c36e3a6e9a42a1d1a2182a2b7@localhost> #3231: Permission denied error with runProcess/openFile --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by NeilMitchell): The {{{removeFile}}} call is actually redundant. Without it I get: {{{ $ runhaskell Test.hs .Test.hs: foo1.txt: openFile: permission denied (Permission denied) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 06:47:18 2009 From: trac at galois.com (GHC) Date: Fri May 15 06:32:14 2009 Subject: [GHC] #2924: createDirectory: permission denied In-Reply-To: <047.7f5e4787e0730bc3878fcff588107d39@localhost> References: <047.7f5e4787e0730bc3878fcff588107d39@localhost> Message-ID: <056.0ee5a96c55d69ca012957dce3a9f2733@localhost> #2924: createDirectory: permission denied ------------------------------------+--------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ------------------------------------+--------------------------------------- Comment (by NeilMitchell): See also #3231. Most likely my reports relate to that bug, and there is a separate issue with the {{{createDirectory}}} call, as replicated above. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 09:00:54 2009 From: trac at galois.com (GHC) Date: Fri May 15 08:45:50 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.02c9a107c00c7902a406b9cbcb4bbba5@localhost> #3231: Permission denied error with runProcess/openFile --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by duncan): Replying to [comment:3 NeilMitchell]: > This version works fine if the {{{system}}} call is removed. That call shouldn't have any difference to the usage of any handles. It seems that system calls mess with handles and resources in painful ways. This is now almost certainly the same underlying cause as the problems I reported in bug #2924. Presumably it is the system call that is crucial. Delaying by one second in Haskell code presumably works ok? If so, my guess is that it's related to the open file handles being inherited by the child process and then the use of the handle in the child conflicts with attempts to remove or re-open the same file in the parent. Of course we wait for the child process to terminate so in principle this should not be a problem, the handles used in the child process should now be closed. However I have a strong suspicion that Windows is using delayed deallocation/unlocking of handles when a process terminates. I've seen behaviour in cabal-install where we wait for a program to terminate, which had an open file in the directory we're about to delete, and when we try to remove the file we often get a permission error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 09:12:13 2009 From: trac at galois.com (GHC) Date: Fri May 15 08:57:08 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.e2775bc751ccd5471eddc15b43bb17ee@localhost> #3231: Permission denied error with runProcess/openFile --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by NeilMitchell): Yes, the system call is crucial - a similar threadDelay has no problems. I only used sleep because it's a simple process that was available, I have no reason to think it's the delay causing a problem. In the sleep example, the child process isn't actually using the open file handle - it was in the original example but that turned out to be irrelevant. BTW, this error is pretty severe for certain users - threads+windows+files+system is a combination that crops up everywhere when using Haskell as a powerful scripting language. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 10:09:25 2009 From: trac at galois.com (GHC) Date: Fri May 15 09:54:20 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.54b767edceb6a9983e170dab7bef1445@localhost> #3231: Permission denied error with runProcess/openFile --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by duncan): Replying to [comment:6 NeilMitchell]: > In the sleep example, the child process isn't actually using the open file handle - it was in the original example but that turned out to be irrelevant. It doesn't matter if it uses it or not. If the handle is set to be inheritable then all child processes will get it and hold it open. So there are apparently two problems: * waiting for a process to terminate does not appear to be enough to ensure that handles it had open are now closed. * `openFile` appears to create handles that are inheritable. The default should almost certainly be non-inheritable (we have similar issues on unix but they're less severe because unix lacks strong file locking). I suggest that both of these need confirming or refuting. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 10:57:08 2009 From: trac at galois.com (GHC) Date: Fri May 15 10:42:03 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.63bc38fc16418fd7ef87d8387e824bd5@localhost> #3231: Permission denied error with runProcess/openFile --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by claus): Thanks for bringing this from rumour to concrete code. Sounded like a good example to try out ProcessExplorer on!-) I tried the following variation, to give me some control and time to see the open handles: {{{ module Main() where import Control.Concurrent import System.IO import System.Directory import System.Process import Control.Exception(bracket) my_system str = do (_,_,_,p) <- createProcess c waitForProcess p where c = CreateProcess { cmdspec = ShellCommand str, cwd = Nothing, env = Nothing, std_in = Inherit, std_out = Inherit, std_err = Inherit, close_fds = True } main = do v <- newEmptyMVar hSetBuffering stdout NoBuffering forkIO $ f v "foo1.txt" forkIO $ f v "foo2.txt" threadDelay $ 100*1000000 putStrLn "Finished successfully" f v file = do bracket (openFile file WriteMode) (hClose) (\h->do hPutStrLn h file hPutStr stderr (">"++file++"< ") my_system "sleep 5s" ) -- takeMVar v hPutStr stderr ("<"++file++"> ") my_system "sleep 5s" removeFile file f v file }}} It seems that no matter what I set `close_fds` to (default `False`?), both GHC and one of its two children sometimes hang on to both files, while the other child hangs on to `foo1` only?? Also, there is occasionally a new pair of children, before the old pair is gone (this tends to preceed the access error). Are these just ProcessExplorer sampling artifacts, am I misreading the data, or is there something else going on (ghc 6.11.20090320)? Btw, after Duncan's remark, I looked up [http://msdn.microsoft.com/en- us/library/aa363915(VS.85).aspx DeleteFile] and found these two -seemingly contradictory- remarks: The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file. The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. Could anyone please explain what that second remark means, given the first? What is the non-normal I/O it seems to apply to? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:00:41 2009 From: trac at galois.com (GHC) Date: Fri May 15 10:45:38 2009 Subject: [GHC] #3207: readMutVar# is inlined/duplicated In-Reply-To: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> References: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> Message-ID: <056.7cb84bfc422f15aa144741d862a4dd21@localhost> #3207: readMutVar# is inlined/duplicated ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:01:19 2009 From: trac at galois.com (GHC) Date: Fri May 15 10:46:15 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.21535415f06d0ba963f3f96ebade5f52@localhost> #3231: Permission denied error with runProcess/openFile --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by NeilMitchell): Claus: Remove the {{{removeFile}}} call, it's not needed, and the error still occurs without it. I thought that {{{DeleteFile}}} could delete a file that was being executed, but not one that is just normally open - that may be where the confusion in MSDN lies. Either way, by removing the {{{removeFile}}} that point becomes less important. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:05:24 2009 From: trac at galois.com (GHC) Date: Fri May 15 10:50:21 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.f572e66d52457f06f3d0732687440cfa@localhost> #3231: Permission denied error with runProcess/openFile --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by NeilMitchell): FWIW, I just had a failure occur where {{{retryIO}}} (a one second wait and GC) wasn't sufficient to solve the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:05:44 2009 From: trac at galois.com (GHC) Date: Fri May 15 10:50:40 2009 Subject: [GHC] #3215: Valgrind support In-Reply-To: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> References: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> Message-ID: <052.7174bf77e5f6f88381569b0c18dab3c2@localhost> #3215: Valgrind support -----------------------------+---------------------------------------------- Reporter: cmcq | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Runtime System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: valgrind | Testcase: yes Os: Linux | Architecture: x86 -----------------------------+---------------------------------------------- Changes (by cmcq): * status: closed => reopened * severity: normal => trivial * type: bug => feature request * summary: Calling freeHaskellFunPtr on the current function => Valgrind support * testcase: => yes * keywords: => valgrind * resolution: invalid => Comment: This is now a feature request. Valgrind is a useful tool when working with the FFI. However, it needs a bit of help to work efficiently. Trac 3215 has a test case where Valgrind's instruction cache causes a RTS crash. One solution is for users to pass --smc-check=all but this is slow. The RTS could use the "Client Request mechanism" to tell Valgrind to update its instruction cache. These normally have no effect. http://valgrind.org/docs/manual/manual-core-adv.html Note "You are encouraged to copy the valgrind/*.h headers into your project's include directory, so your program doesn't have a compile-time dependency on Valgrind being installed. The Valgrind headers, unlike most of the rest of the code, are under a BSD-style license so you may include them without worrying about license incompatibility." Should these headers just go in the "includes" directory? {{{ diff -rN -u old-ghc/rts/Adjustor.c new-ghc/rts/Adjustor.c --- old-ghc/rts/Adjustor.c 2009-05-11 11:30:09.000000000 +0100 +++ new-ghc/rts/Adjustor.c 2009-05-11 11:30:09.000000000 +0100 @@ -143,6 +143,8 @@ #define UNDERSCORE "" #endif #if defined(i386_HOST_ARCH) && !defined(darwin_HOST_OS) +#include + /* Now here's something obscure for you: @@ -411,6 +413,8 @@ adj_code[0x0f] = (unsigned char)0xff; /* jmp *%eax */ adj_code[0x10] = (unsigned char)0xe0; + + VALGRIND_DISCARD_TRANSLATIONS(code,0x11); } #elif defined(i386_HOST_ARCH) && defined(darwin_HOST_OS) { }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:29:49 2009 From: trac at galois.com (GHC) Date: Fri May 15 11:14:45 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.4b7a1d241fd26d08c960910a3e086873@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:7 claus]: > Thanks. I think I could live with only one `*`-ed module, if that was necessary to get this consistency, but there's no telling what wonderful uses other GHCi users have come up with, or what their preferences are.. So permitting multiple `*`-ed modules sounds safer - just adding the requirement that they have to be compatible. Can you precisely define "compatibility"? Can you imagine implementing (or even describing) it in a simple way? (I can't) I have to admit, this sounds way overkill to me. If this is really a necessary feature, can you describe a compelling use case? One that doesn't have an easy workaround? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:36:53 2009 From: trac at galois.com (GHC) Date: Fri May 15 11:21:47 2009 Subject: [GHC] #3232: Remove registerised -fvia-C Message-ID: <044.8ef2aabc1c214894ed9094970ca92d33@localhost> #3232: Remove registerised -fvia-C -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Remove registerised `-fvia-C`. The following should be looked at before doing so: * x86 floating point performance is bad with `-fasm` -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:43:36 2009 From: trac at galois.com (GHC) Date: Fri May 15 11:28:32 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.51187e8f0580bd2bd23a8ec5c0d8e21b@localhost> #3231: Permission denied error with runProcess/openFile --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by Deewiant): This appears to be a duplicate of #2650? I have some partial fixes for the issue there. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:51:46 2009 From: trac at galois.com (GHC) Date: Fri May 15 11:36:41 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.67ebf90754e13641ccdac51f2221b38e@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: Replying to [comment:11 Deewiant]: > This appears to be a duplicate of #2650? I have some partial fixes for the issue there. So the fix to add `_O_NOINHERIT` when opening files could be applied, but I'm not sure whether it will have any undesirable consequences. Anyone? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:51:58 2009 From: trac at galois.com (GHC) Date: Fri May 15 11:36:53 2009 Subject: [GHC] #2650: Child processes always unwantedly inherit Handles on Windows In-Reply-To: <047.1449ef20e3242d7624bded23f58b28e1@localhost> References: <047.1449ef20e3242d7624bded23f58b28e1@localhost> Message-ID: <056.5949f98fdc7cf2f8e4eab5701e0f9c0b@localhost> #2650: Child processes always unwantedly inherit Handles on Windows ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries (other) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:57:02 2009 From: trac at galois.com (GHC) Date: Fri May 15 11:41:59 2009 Subject: [GHC] #3128: hClose leaves file descriptor open if it fails In-Reply-To: <045.f474a379b598a39e20f417ce0f4de22b@localhost> References: <045.f474a379b598a39e20f417ce0f4de22b@localhost> Message-ID: <054.a4f3e496857bab4eb8c55490d1b87d42@localhost> #3128: hClose leaves file descriptor open if it fails ---------------------------------+------------------------------------------ Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:4 Baughn]: > I would like to add that Handles *should* contain an MVar (Maybe FD) or some such instead of just an FD. Or, rather, after a handle is hClosed - and the socket goes away - it ought to be impossible to use that handle for anything whatsoever. > > As it is now, it's possible for the FD to be reused, and for code that reuses the closed Handle to touch someone else's FD. > > This may not violate the haskell spec, but neither would code where you can't do that, and the cost would be trivial. I don't think I understand what problem you're referring to. The `Handle` has a status, which is set to `ClosedHandle` when it is closed. When a `Handle` is marked as closed in this way, nothing should be using the `FD`. (this is all different in the rewrite of the IO library anyway). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:58:51 2009 From: trac at galois.com (GHC) Date: Fri May 15 11:43:48 2009 Subject: [GHC] #2058: Ghci tab-completion cannot handle Unicode In-Reply-To: <047.a8886855c87afec46dd99ad6a799741e@localhost> References: <047.a8886855c87afec46dd99ad6a799741e@localhost> Message-ID: <056.c9cc77cfd86f5893caa7b6c13eb3dd5d@localhost> #2058: Ghci tab-completion cannot handle Unicode ---------------------------------+------------------------------------------ Reporter: desegnis | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by cmcq): * status: new => closed * resolution: => duplicate Comment: See #2812. Those Unicode examples work for me in 6.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:58:57 2009 From: trac at galois.com (GHC) Date: Fri May 15 11:43:52 2009 Subject: [GHC] #3026: GHCi segfault In-Reply-To: <045.32dfa38b320a92e3252f23b24d4bdbec@localhost> References: <045.32dfa38b320a92e3252f23b24d4bdbec@localhost> Message-ID: <054.241ad521a7146e42c29dc4d89b48512e@localhost> #3026: GHCi segfault -----------------------+---------------------------------------------------- Reporter: porges | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.1 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by cmcq): * status: new => closed * resolution: => duplicate Comment: See #2812. I don't get a segfault in 6.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:58:30 2009 From: trac at galois.com (GHC) Date: Fri May 15 11:43:59 2009 Subject: [GHC] #2812: For ghci, drop editline in favour of haskeline In-Reply-To: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> References: <044.83b1cb097467eb96264cb87a3cc1f7c9@localhost> Message-ID: <053.ad7b252fbc3d4f7a11198cc4b820feaa@localhost> #2812: For ghci, drop editline in favour of haskeline ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: closed Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by cmcq): * status: new => closed * resolution: => fixed Comment: According to the release notes, 6.10.3 uses haskeline. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 11:59:02 2009 From: trac at galois.com (GHC) Date: Fri May 15 11:44:03 2009 Subject: [GHC] #3157: ghci segmentation fault when computation is interrupted In-Reply-To: <046.b92aff660639d37518d804b70f95cb9e@localhost> References: <046.b92aff660639d37518d804b70f95cb9e@localhost> Message-ID: <055.06f59abc7f3ce53f7416c445f949bcd7@localhost> #3157: ghci segmentation fault when computation is interrupted -------------------------------+-------------------------------------------- Reporter: fft1976 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.10.2 Severity: critical | Resolution: duplicate Keywords: ghci | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by cmcq): * status: new => closed * resolution: => duplicate Comment: See #2812. I don't get a segfault in 6.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 12:50:06 2009 From: trac at galois.com (GHC) Date: Fri May 15 12:35:00 2009 Subject: [GHC] #3233: Cleaning on Windows currently fails Message-ID: <044.13351ae8e3ff95098ed8a98f6711048d@localhost> #3233: Cleaning on Windows currently fails -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Cleaning on Windows currently fails, due to this: {{{ $ cat Makefile bar/baz/%.hc : bar/baz/%.hs echo wibble foo: rm -rf bar $ mkdir -p bar/baz $ make foo rm -rf bar rm: cannot remove directory `bar': Directory not empty make: *** [foo] Error 1 $ }}} To work around the problem, we can not load all of the make rules when the target is `clean` (or `maintainer-clean` or `distclean`). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 13:17:26 2009 From: trac at galois.com (GHC) Date: Fri May 15 13:02:20 2009 Subject: [GHC] #3230: Build fails with cabal-bin complaining In-Reply-To: <044.5ebb87f68ffd93427e47d23d9f5ebb95@localhost> References: <044.5ebb87f68ffd93427e47d23d9f5ebb95@localhost> Message-ID: <053.2de0ad7d12c0d20dbbfdf8f239dea8b0@localhost> #3230: Build fails with cabal-bin complaining --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) --------------------------+------------------------------------------------- Comment (by guest): ghc-6.8.3 builds fine, and 6.10.3 builds from it, so maybe this is just a matter of changing the comments at http://www.haskell.org/ghc/download_ghc_6_10_3.html (and related pages) to say it requires version 6.8 instead of 6.6 to compile? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 14:22:19 2009 From: trac at galois.com (GHC) Date: Fri May 15 14:07:15 2009 Subject: [GHC] #3128: hClose leaves file descriptor open if it fails In-Reply-To: <045.f474a379b598a39e20f417ce0f4de22b@localhost> References: <045.f474a379b598a39e20f417ce0f4de22b@localhost> Message-ID: <054.c92ba48bfb70045adad7879801edb09f@localhost> #3128: hClose leaves file descriptor open if it fails ---------------------------------+------------------------------------------ Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by Baughn): Ah. Of course; my invocations of hClose were failing anyway, so it probably just never got that far, and I didn't see the code. Say, about that rewrite - is the API going to be the same as the current one? If not, is there any way I could have a look? I really need a functional network library for my thesis, but at the moment I was resigning myself to writing my own based on the C functions when I get started, in a few weeks' time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 14:39:46 2009 From: trac at galois.com (GHC) Date: Fri May 15 14:24:53 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.c5e84ffb29b424aabc4c5c9fdf62fd3e@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by claus): > > This appears to be a duplicate of #2650? I have some partial fixes for the issue there. > > So the fix to add `_O_NOINHERIT` when opening files could be applied, but I'm not sure whether it will have any undesirable consequences. Anyone? If there is no way to implement the `close_fds` parameter to `createProcess` properly on Windows, that should at least be mentioned in the documentation! Since the parameter is there, I'd prefer to have it implemented, rather than ignored, though. Anyway, that means we can simplify the example, right? {{{ module Main() where import Control.Concurrent import System.IO import System.Process my_system str = do (_,_,_,p) <- createProcess c waitForProcess p where c = CreateProcess { cmdspec = ShellCommand str, cwd = Nothing, env = Nothing, std_in = Inherit, std_out = Inherit, std_err = Inherit, close_fds = True } -- close_fds is ignored on windows!-( main = do va <- newEmptyMVar vb <- newEmptyMVar forkIO $ p va vb "foo1.txt" takeMVar va forkIO $ my_system "sleep 60s" >> return () putMVar vb () putStrLn "Finished" p va vb file = do h <- openFile file WriteMode putMVar va () takeMVar vb hClose h h <- openFile file WriteMode putStrLn "Success?" hClose h }}} Seems to fail quite reliably here, while it works when the system call is commented out. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 15:08:29 2009 From: trac at galois.com (GHC) Date: Fri May 15 14:53:23 2009 Subject: [GHC] #3230: Build fails with cabal-bin complaining In-Reply-To: <044.5ebb87f68ffd93427e47d23d9f5ebb95@localhost> References: <044.5ebb87f68ffd93427e47d23d9f5ebb95@localhost> Message-ID: <053.25829df208fce051ffefb3d5634f272a@localhost> #3230: Build fails with cabal-bin complaining -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. There are actually earlier failures than that, e.g.: {{{ /usr/bin/ghc -package-conf /tmp/zi/ghc/ghc-6.10.3/libraries/bootstrapping.conf --make Setup -package Cabal-1.6.0.3 -o Setup Setup.hs:16:7: Could not find module `System.FilePath': it was found in multiple packages: filepath-1.1.0.2 FilePath-0.11 }}} GHC 6.6 doesn't come with `FilePath`, so it looks like you have installed it, and that has confused the build system. The build should work with a vanilla GHC 6.6 installation. The real bug here is that the build should have stopped after the first failure. However, given this is all done differently in the new build system in the HEAD, I'm going to close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 16:15:38 2009 From: trac at galois.com (GHC) Date: Fri May 15 16:00:36 2009 Subject: [GHC] #2650: Child processes always unwantedly inherit Handles on Windows In-Reply-To: <047.1449ef20e3242d7624bded23f58b28e1@localhost> References: <047.1449ef20e3242d7624bded23f58b28e1@localhost> Message-ID: <056.b7f11c7959f82adc80f5bd9d107bb88d@localhost> #2650: Child processes always unwantedly inherit Handles on Windows ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries (other) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by duncan): So according to the [http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6428742 JVM bug report] we can make `CreateProcess.close_fds` work except when also trying to redirect stdin/out. Currently we do not attempt to make it work at all. And on Vista we can make it work even when redirect stdin/out. So it seems like we both need to make new handles (eg from opening files and sockets) non-inheritable and implement the above tricks. This all looks quite doable but will need some careful testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 16:20:21 2009 From: trac at galois.com (GHC) Date: Fri May 15 16:05:26 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.a4fc520ef72a97d68290446387957f44@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): I originally thought I saw two problems in Neil's example, but looking at it again I see that he's doing the same thing in two threads separately, so each child process is holding the file from both threads open. At some point as the two threads get out of sync then one will have it open while the parent tries to open it again. So perhaps there's nothing happening here more than #2650. Which is good because we pretty much understand that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 16:24:41 2009 From: trac at galois.com (GHC) Date: Fri May 15 16:09:43 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.b436af00179994884d8c1e26a4b64c1b@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:14 claus]: > If there is no way to implement the `close_fds` parameter to `createProcess` properly on Windows, that should at least be mentioned in the documentation! Since the parameter is there, I'd prefer to have it implemented, rather than ignored, though. There is a way on XP at least for the case where you're not setting stdin/out. On Vista it looks like it can be made to work in all cases. See #2650. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 16:56:57 2009 From: trac at galois.com (GHC) Date: Fri May 15 16:41:53 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.163a86f7fe31c6c744123bf4c4828490@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by claus): > Can you precisely define "compatibility"? Can you imagine implementing (or even describing) it in a simple way? Sure - the same way it is defined currently, in a single file!-) Actually, defining and implementing this would be good in any case, as there currently are a few oddities..: - no multiple `default` permitted (as in a single file; this could be relaxed to permitting *identical* `default`s) - no `{-# LANGUAGE X, NoX #-}` (actually, that is currently permitted, but I consider it an oversight/bug..) - no `{-# OPTIONS_GHC -fthis, -fno-this #-}` (again, that is currently permitted..) If there are any non-obvious cases, simply require that all modules must have the same, identical options for those. In general, proceed as if all `*`-ed modules were in a single file, with allowances for identical duplicates. My intention here is that explicit settings have priority over implicit ones (if one module doesn't have an explicit `default`, another does, then the combination has the explicitly given `default`). This merging of explicit settings might lead to a module not being loadable with the merged settings, but this isn't different from that module depending on specific settings, which should be made explicit. An alternative would be to require identical settings in all modules to be loaded in a `*` combination. This would be easier to check, but almost as cumbersome as permitting only a single `*`-ed module. > If this is really a necessary feature, can you describe a compelling use case? One that doesn't have an easy workaround? As I mentioned, a single `*`-ed module would seem to work for me. It is just that I've often been annoyed if people who couldn't imagine a use case decided that there were no use cases, so I didn't want to fall into the same trap. I don't know how many folks still read ghc-bugs, or the trac RSS feeds, so perhaps raise the issue on ghc-users, and point to this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 15 17:23:44 2009 From: trac at galois.com (GHC) Date: Fri May 15 17:08:43 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.f842510fa424f5fb29d75dc57cb235c0@localhost> #3226: please eliminate error message from Make on every build ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by nr): I'm afraid {{{ make 1 }}} suffers from the same problem: {{{ : nr@labrador 3648 [branch=norman] ; make 1 make -C .. stage=1 all_ghc_stage1 compiler_stage1_NO_BUILD_DEPS=YES make[1]: Entering directory `/usr/local/nr/git/ghc/experimental' ===--- updating makefiles phase 0 make -r --no-print-directory -f ghc.mk phase=0 just-makefiles ===--- updating makefiles phase 1 make -r --no-print-directory -f ghc.mk phase=1 just-makefiles ===--- updating makefiles phase 2 make -r --no-print-directory -f ghc.mk phase=2 just-makefiles ===--- updating makefiles phase 3 make -r --no-print-directory -f ghc.mk phase=3 just-makefiles ghc/ghc.mk:90: ghc/stage1/build/.depend: No such file or directory /usr/bin/ghc -H64m -O0 -fasm -package-conf libraries/bootstrapping.conf -package-name ghc-6.11.20090513 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.7.0 -package array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.0 -package unix-2.3.1.0 -#include cutils.h -DSTAGE=1 -O -fasm -Wall -fno-warn-name-shadowing -fno-warn- orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc -c compiler/codeGen/StgCmmProf.hs -o compiler/stage1/build/StgCmmProf.o compiler/codeGen/StgCmmProf.hs:350:41: `CmmAGraph' is not applied to enough type arguments Expected kind `*', but `CmmAGraph' has kind `* -> * -> *' In the type `FCode CmmAGraph' In the type `CollectedCCs -> FCode CmmAGraph' In the type signature for `initCostCentres': initCostCentres :: CollectedCCs -> FCode CmmAGraph compiler/codeGen/StgCmmProf.hs:417:30: `CmmAGraph' is not applied to enough type arguments Expected kind `?', but `CmmAGraph' has kind `* -> * -> *' In the type `CostCentre -> CmmAGraph' In the type signature for `mkRegisterCC': mkRegisterCC :: CostCentre -> CmmAGraph compiler/codeGen/StgCmmProf.hs:435:36: `CmmAGraph' is not applied to enough type arguments Expected kind `?', but `CmmAGraph' has kind `* -> * -> *' In the type `CostCentreStack -> CmmAGraph' In the type signature for `mkRegisterCCS': mkRegisterCCS :: CostCentreStack -> CmmAGraph compiler/codeGen/StgCmmProf.hs:479:27: `CmmAGraph' is not applied to enough type arguments Expected kind `?', but `CmmAGraph' has kind `* -> * -> *' In the type `CmmExpr -> CmmAGraph' In the type signature for `bumpSccCount': bumpSccCount :: CmmExpr -> CmmAGraph make[2]: *** [compiler/stage1/build/StgCmmProf.o] Error 1 make[1]: *** [all_ghc_stage1] Error 2 make[1]: Leaving directory `/usr/local/nr/git/ghc/experimental' make: *** [1] Error 2 }}} I may have a go at the doco once I understand a little better what's going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 01:47:58 2009 From: trac at galois.com (GHC) Date: Sat May 16 01:32:53 2009 Subject: [GHC] #3234: foldr/single no longer firing in GHC 6.10 Message-ID: <041.6f78ca9107f6c0f52fc046199711a2f3@localhost> #3234: foldr/single no longer firing in GHC 6.10 -----------------------------+---------------------------------------------- Reporter: r6 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- consider the following module {{{module Foo where x = ['x']++"haskell"}}} when {{{ghc --make -O2 Foo.hs -ddump-simpl-stats}}} is run using GHC 6.8.2, the output show that the foldr/single rule is fired {{{ 5 RuleFired 1 ++ 1 augment/build 1 foldr/single 1 unpack 1 unpack-list }}} However, I am told that this does not happen in GHC 6.10.2 nor GHC 6.10.3 where foldr/app is fired instead {{{ 6 RuleFired 1 ++ 1 augment/build 1 fold/build 1 foldr/app 1 unpack 1 unpack-list }}} Thus it appears that the above module is no longer properly optimized in GHC 6.10 (thanks to dons and Jedai for helping with this) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 07:17:57 2009 From: trac at galois.com (GHC) Date: Sat May 16 07:02:53 2009 Subject: [GHC] #3215: Valgrind support In-Reply-To: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> References: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> Message-ID: <052.fd70df05a5088eec830032e131dc0800@localhost> #3215: Valgrind support -----------------------------+---------------------------------------------- Reporter: cmcq | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Runtime System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: valgrind | Testcase: yes Os: Linux | Architecture: x86 -----------------------------+---------------------------------------------- Comment (by duncan): Is rts/Adjustor.c still used? I thought it was all libffi now. Does libffi have valgrind support? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 09:07:52 2009 From: trac at galois.com (GHC) Date: Sat May 16 08:52:45 2009 Subject: [GHC] #3235: ghci-6.10.3 can't be built with readline support Message-ID: <044.a6ba63b94ae8bd7f8acc72d9aa9a1eda@localhost> #3235: ghci-6.10.3 can't be built with readline support -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- ghci before version 6.10 used readline for user input. This was nice because readline actually works, other programs use it (so ~/.inputrc lets me customize the behavior of many applications at once), and it is fairly powerful. 6.10.1 moved to editline, which was plain broken (busy hang during startup), had no features, etc. But changing the code back to use readline was easy. Now 6.10.3 is using haskeline, with an entirely new set of bugs (combining characters aren't handled right) and missing features (see `info readline Command Bindable`; none of that is available in haskeline). As a ghci user these changes don't do anything for me except remove existing functionality and introduce bugs. Why can't you let me optionally build ghci with readline instead of haskeline? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 09:44:05 2009 From: trac at galois.com (GHC) Date: Sat May 16 09:28:56 2009 Subject: [GHC] #3235: ghci-6.10.3 can't be built with readline support In-Reply-To: <044.a6ba63b94ae8bd7f8acc72d9aa9a1eda@localhost> References: <044.a6ba63b94ae8bd7f8acc72d9aa9a1eda@localhost> Message-ID: <053.4447666e9a7bf9a4d2d8e74b5da1b1eb@localhost> #3235: ghci-6.10.3 can't be built with readline support ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by duncan): I'd tend to agree, however there are at least these issues: * Maintenance and testing burden of keeping several line editing systems working * Distributing binaries and problems with depending on system shared libs. * Licensing complications If the patch is not invasive and GHC HQ are not asked to maintain the readline branch then perhaps the first point is ok. It's annoying when building binaries that sometimes the .so number of readline changes and then we need to build different binaries for different systems. Using haskeline has fewer problems in this area. When one builds ghc (BSD licensed) against readline (GPL) then if you distribute the combined work it must be under the terms of the GPL. That's not something that GHC HQ want to do and some users would prefer to receive binaries under the BSD or distribute their own binaries under the terms of the BSD license. On the other hand it's perfectly OK for distros to build it that way, as long as they clearly label the licensing terms of the result (which has not always been done clearly). So if readline is to be used it has to be optional and not the default. That's fine. So the only remaining issue is the maintenance burden. I cannot speak for the GHC maintainers but if someone volunteers to properly maintain the readline support then perhaps that might be enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 10:53:19 2009 From: trac at galois.com (GHC) Date: Sat May 16 10:38:11 2009 Subject: [GHC] #3236: Would be nice if rts_lock (or similar) would fail when the RTS is not started Message-ID: <045.8ca5bdda229b63ae1e0185fe4d14f519@localhost> #3236: Would be nice if rts_lock (or similar) would fail when the RTS is not started -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 6.11 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- If you export a Haskell function and then call it from C code you have got to remember to start up the RTS before calling the exported C function, otherwise it segfaults. As a slightly nicer way of reminding people to initialise the RTS, perhaps one of the functions on the code path for calling exported functions (ie the calls in the _stub.c files) could check if the RTS is started and if not do something a little nicer than segfault. The code typically looks like {{{ cap=rts_lock(); cap=rts_evalIO(cap, rts_apply(cap,(HaskellObj)runIO_closure, rts_apply(cap,&Foo_zdffoozuads_closure, rts_mkInt(cap,a1))) ,&ret); rts_checkSchedStatus("foo",cap); cret=rts_getInt(ret); }}} The first bit to segfault is `allocateLocal`, probably inside `rts_mkInt`. Note that `rts_lock` succeeds and returns a non-null capability. On similar lines, we might want to think about the use case of building Haskell libs that export C functions to be used by other projects and ways to make initialising that library either nicer or automatic. We all complain when we use C libs that require a global initialiser (implying some global state) and yet that's exactly what we impose on callers. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 12:33:01 2009 From: trac at galois.com (GHC) Date: Sat May 16 12:17:54 2009 Subject: [GHC] #3235: ghci-6.10.3 can't be built with readline support In-Reply-To: <044.a6ba63b94ae8bd7f8acc72d9aa9a1eda@localhost> References: <044.a6ba63b94ae8bd7f8acc72d9aa9a1eda@localhost> Message-ID: <053.45e6ae91e908d7fa34ff1121eb26e2b8@localhost> #3235: ghci-6.10.3 can't be built with readline support ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by judah): Note that Haskeline does have bindable commands, as documented at: http://trac.haskell.org/haskeline/wiki/WikiDocumentation Also keep in mind that the readline backend also came with problems. For example, the following didn't work: - tab-completion of Unicode identifiers (#2058) - tab completion of quoted filenames in expressions - cancel the current input line with ctrl-c I don't really object to a forked GHC/readline. But I wonder whether the effort required to maintain a separate branch of GHC would be better used to fix Haskeline's remaining issues. (I plan to tackle many of them myself in time for the ghc-6.12 release.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 13:26:40 2009 From: trac at galois.com (GHC) Date: Sat May 16 13:11:31 2009 Subject: [GHC] #3233: Cleaning on Windows currently fails In-Reply-To: <044.13351ae8e3ff95098ed8a98f6711048d@localhost> References: <044.13351ae8e3ff95098ed8a98f6711048d@localhost> Message-ID: <053.8bd06d622a8a84df217cd08da4177b5e@localhost> #3233: Cleaning on Windows currently fails ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Sat May 16 00:19:47 BST 2009 Ian Lynagh * Disable suffix rules when cleaning Sat May 16 12:45:11 BST 2009 Ian Lynagh * Hide more make rules when cleaning }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 13:54:47 2009 From: trac at galois.com (GHC) Date: Sat May 16 13:39:41 2009 Subject: [GHC] #2689: make maintainer-clean leaves generated files and directories In-Reply-To: <044.d82e9d076aeb3a76dac009bdaa86249d@localhost> References: <044.d82e9d076aeb3a76dac009bdaa86249d@localhost> Message-ID: <053.ca3b269a7967c4820e136fce715cce44@localhost> #2689: make maintainer-clean leaves generated files and directories ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Done; I've left #1693 open to remind us to try to do something to check that cleaning actually cleans everything it should. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 16:00:35 2009 From: trac at galois.com (GHC) Date: Sat May 16 15:45:28 2009 Subject: [GHC] #3237: Target binary-dist fails when building GHC with DPH Message-ID: <046.150053a88502d656bac976c7eb79864d@localhost> #3237: Target binary-dist fails when building GHC with DPH -----------------------------+---------------------------------------------- Reporter: scsibug | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- running "make binary-dist" for GHC with data parallel haskell fails due to missing LICENSE files in dph-seq and dph-par packages. BINDIST_EXTRAS in rules/build-package.mk assumes that all packages have a file LICENSE at the root, but dph-seq and dph-par assume their license files are in the parent directory (dph). Tested with latest GHC and dph packages from darcs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 16:13:13 2009 From: trac at galois.com (GHC) Date: Sat May 16 15:58:03 2009 Subject: [GHC] #3238: CInt FFI exports do not use C int in _stub.h header file Message-ID: <045.5781f68e770b8bad07184615b4897cd3@localhost> #3238: CInt FFI exports do not use C int in _stub.h header file -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Ideally if I have a FFI export like this: {{{ foreign export ccall foo :: CInt -> CInt }}} Then the `_stub.h` file should look like: {{{ #ifdef __cplusplus extern "C" { #endif extern int foo(int a1); #ifdef __cplusplus } #endif }}} But it actually looks like: {{{ #include "HsFFI.h" #ifdef __cplusplus extern "C" { #endif extern HsInt32 foo(HsInt32 a1); #ifdef __cplusplus } #endif }}} So what am I complaining about? Well, I specified an FFI export mentioning only C types but the header file uses `HsInt32`. I'd prefer an actual C `int`. I also do not want to `#include "HsFFI.h"` because then when using gcc to compile C code that uses this C function I have to know the full path to ghc's include dir so that gcc can find `HsFFI.h`. The point here is about exporting C functions and trying to integrate into some bigger build system that will be using gcc not ghc to compile C code and link the system together. I realise this isn't trivial to fix, because GHC defines things like CInt as newtypes for primitive types of known widths (like Int32). However, perhaps there should be a known mapping, even though within the Haskell world CInt is just a newtype. The set of FFI types is already hard-wired into the compiler (with some rules to allow newtype unwrapping etc) so why not extend that hard-wired knowledge to include the real C type (not just the ABI width). This only needs to be used when generating the export header files. An extra bit in the mapping can indicate if it's a C primitive type or if the export header file has to `#include "HsFFI.h"`. This ticket is related to #2926 and the solution is almost certainly the same, but the motivation for this problem is slightly different. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 16:50:03 2009 From: trac at galois.com (GHC) Date: Sat May 16 16:35:00 2009 Subject: [GHC] #3157: ghci segmentation fault when computation is interrupted In-Reply-To: <046.b92aff660639d37518d804b70f95cb9e@localhost> References: <046.b92aff660639d37518d804b70f95cb9e@localhost> Message-ID: <055.b23afbc42808b4d16f7cb61f2ccb83b2@localhost> #3157: ghci segmentation fault when computation is interrupted -------------------------------+-------------------------------------------- Reporter: fft1976 | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.10.2 Severity: critical | Resolution: Keywords: ghci | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: duplicate => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 16:50:37 2009 From: trac at galois.com (GHC) Date: Sat May 16 16:35:32 2009 Subject: [GHC] #3157: ghci segmentation fault when computation is interrupted In-Reply-To: <046.b92aff660639d37518d804b70f95cb9e@localhost> References: <046.b92aff660639d37518d804b70f95cb9e@localhost> Message-ID: <055.c3e7a7a7e38221fb62e11221b5afad3e@localhost> #3157: ghci segmentation fault when computation is interrupted ----------------------------------+----------------------------------------- Reporter: fft1976 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: libraries (other) | Version: 6.10.2 Severity: critical | Resolution: wontfix Keywords: ghci | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: reopened => closed * component: Runtime System => libraries (other) * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 16 16:52:16 2009 From: trac at galois.com (GHC) Date: Sat May 16 16:37:09 2009 Subject: [GHC] #3026: GHCi segfault In-Reply-To: <045.32dfa38b320a92e3252f23b24d4bdbec@localhost> References: <045.32dfa38b320a92e3252f23b24d4bdbec@localhost> Message-ID: <054.e21b1b09de3e2cbbee87bafc8afdf637@localhost> #3026: GHCi segfault -----------------------+---------------------------------------------------- Reporter: porges | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.1 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------+---------------------------------------------------- Comment (by simonmar): See also #3157 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 17 11:58:43 2009 From: trac at galois.com (GHC) Date: Sun May 17 11:43:34 2009 Subject: [GHC] #3215: Valgrind support In-Reply-To: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> References: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> Message-ID: <052.dcdac51c87b2d37c84f96591337b5474@localhost> #3215: Valgrind support -----------------------------+---------------------------------------------- Reporter: cmcq | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Runtime System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: valgrind | Testcase: yes Os: Linux | Architecture: x86 -----------------------------+---------------------------------------------- Comment (by cmcq): On x86 Linux, libffi is only used for allocating code. From "darcs changes rts/Adjustor.c": {{{ Tue Apr 8 19:34:34 BST 2008 Simon Marlow * Import libffi-3.0.4, and use it to provide FFI support in GHCi ... There is also code in the RTS to use libffi in place of rts/Adjustor.c, but it is currently not enabled if we already have support in Adjustor.c for the current platform. We need to assess the performance impact before using libffi here too (in GHCi we don't care too much about performance). }}} The libffi source doesn't mention Valgrind so there's no explicit support. I couldn't get a test that fails. From a quick look at its source, a libffi trampoline's code is based on its address. Hence the only way Valgrind's code cache could become incoherent is if ffi_closure_alloc returns addresses such that a trampoline overlaps previous trampolines. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 17 12:39:43 2009 From: trac at galois.com (GHC) Date: Sun May 17 12:24:32 2009 Subject: [GHC] #3215: Valgrind support In-Reply-To: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> References: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> Message-ID: <052.27866c23470f179347ca4e4093e664cf@localhost> #3215: Valgrind support -----------------------------+---------------------------------------------- Reporter: cmcq | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Runtime System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: valgrind | Testcase: yes Os: Linux | Architecture: x86 -----------------------------+---------------------------------------------- Comment (by cmcq): Also see #793 regarding use of libffi. I get this unrelated problem using UseLibFFIForAdjustors=YES on GHC from darcs: {{{ $ gdb -q ./finalizer_queue (gdb) break MallocFailHook Breakpoint 1 at 0x8194826: file rts/hooks/MallocFail.c, line 14. (gdb) r Starting program: /home/colin/FinalizerQueue/finalizer_queue [Thread debugging using libthread_db enabled] [New Thread 0xb7ce86d0 (LWP 13368)] [New Thread 0xb7affb90 (LWP 13371)] [New Thread 0xb72feb90 (LWP 13372)] [Switching to Thread 0xb72feb90 (LWP 13372)] Breakpoint 1, MallocFailHook (request_size=4294967292, msg=0x81d3870 "createAdjustor") at rts/hooks/MallocFail.c:14 14 fprintf(stderr, "malloc: failed on request for %lu bytes; message: %s\n", request_size, msg); (gdb) where #0 MallocFailHook (request_size=4294967292, msg=0x81d3870 "createAdjustor") at rts/hooks/MallocFail.c:14 #1 0x08187b87 in stgMallocBytes (n=-4, msg=0x81d3870 "createAdjustor") at rts/RtsUtils.c:201 #2 0x08182800 in createAdjustor (cconv=1, hptr=0xc, wptr=0x804b9c0 , typeString=0x81c0008 "") at rts/Adjustor.c:97 #3 0x0804ac7f in sG9_info () #4 0x00000001 in ?? () #5 0x080750bc in base_GHCziIOBase_a23_info () #6 0xb7b8004a in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 17 16:46:47 2009 From: trac at galois.com (GHC) Date: Sun May 17 16:31:36 2009 Subject: [GHC] #3239: Bad jump on PowerPC Message-ID: <044.6398c5ce1c1a365bdb1a25c900ccade4@localhost> #3239: Bad jump on PowerPC -----------------------------+---------------------------------------------- Reporter: duane | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- ghc: internal error: unconditional relative branch out of range: jump island out of range (GHC version 6.10.1 for powerpc_apple_darwin) That's it. NOTE: I was compiling LHC when this happened. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 17 16:46:56 2009 From: trac at galois.com (GHC) Date: Sun May 17 16:31:43 2009 Subject: [GHC] #3240: Bad jump on PowerPC Message-ID: <044.c9404de701510cb572754e15b36dca29@localhost> #3240: Bad jump on PowerPC --------------------+------------------------------------------------------- Reporter: duane | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: powerpc --------------------+------------------------------------------------------- ghc: internal error: unconditional relative branch out of range: jump island out of range (GHC version 6.10.1 for powerpc_apple_darwin) That's it. NOTE: I was compiling LHC when this happened. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 18 04:31:37 2009 From: trac at galois.com (GHC) Date: Mon May 18 04:16:36 2009 Subject: [GHC] #3207: readMutVar# is inlined/duplicated In-Reply-To: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> References: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> Message-ID: <056.e37a12e750ce84d56281bef3c67cf311@localhost> #3207: readMutVar# is inlined/duplicated ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * milestone: 6.12.1 => 6.10 branch Comment: Fixed: {{{ Fri May 15 15:36:08 BST 2009 Simon Marlow * Fix #3207: add has_side_effects = True for lots of primops and document primOpHasSideEffects }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 18 05:32:15 2009 From: trac at galois.com (GHC) Date: Mon May 18 05:17:03 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.e51151eff07fb966143497d6672b39e5@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:9 claus]: > > Can you precisely define "compatibility"? Can you imagine implementing (or even describing) it in a simple way? > > Sure - the same way it is defined currently, in a single file!-) Actually, defining and implementing this would be good in any case, as there currently are a few oddities..: > > - no multiple `default` permitted (as in a single file; this could be relaxed to permitting *identical* `default`s) > > - no `{-# LANGUAGE X, NoX #-}` (actually, that is currently permitted, but I consider it an oversight/bug..) > > - no `{-# OPTIONS_GHC -fthis, -fno-this #-}` (again, that is currently permitted..) > > If there are any non-obvious cases, simply require that all modules must have the same, identical options for those. In general, proceed as if all `*`-ed modules were in a single file, with allowances for identical duplicates. > > My intention here is that explicit settings have priority over implicit ones (if one module doesn't have an explicit `default`, another does, then the combination has the explicitly given `default`). This merging of explicit settings might lead to a module not being loadable with the merged settings, but this isn't different from that module depending on specific settings, which should be made explicit. > > An alternative would be to require identical settings in all modules to be loaded in a `*` combination. This would be easier to check, but almost as cumbersome as permitting only a single `*`-ed module. I think you've illustrated my point quite clearly! There's no sensible way to do this that both (a) is obviously the right thing, and (b) doesn't require writing a ton of tedious and error-prone comparison code to implement. > > If this is really a necessary feature, can you describe a compelling use case? One that doesn't have an easy workaround? > > As I mentioned, a single `*`-ed module would seem to work for me. It is just that I've often been annoyed if people who couldn't imagine a use case decided that there were no use cases, so I didn't want to fall into the same trap. I don't know how many folks still read ghc-bugs, or the trac RSS feeds, so perhaps raise the issue on ghc-users, and point to this ticket? It's more a matter of taste. A feature is much more likely to be implemented if * it is obviously the right design. A proxy we often use for this is "can be described simply in the documentation". The best UI designs require zero documentation. * it doesn't stretch the internal architecture, e.g. by adding new global invariants * it has a high effort-to-benefit ratio (subjective of course, and not so applicable if someone else does the coding; hint :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 18 05:48:42 2009 From: trac at galois.com (GHC) Date: Mon May 18 05:33:30 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.df237695e55f1de4c2d1bcc071a3395b@localhost> #3226: please eliminate error message from Make on every build ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Norman - welcome to the world of non-recursive make :-) Even when you say `make` in `compiler/`, the build system is bringing every dependency of GHC up to date in order to start building GHC itself. Of course this might well be overkill, but the design principle was "safety first": we want to ensure that the tree never ends up in an inconsistent state, at least unless the user explicitly says they want to play fast and loose. What we should do now, having established the safe but slow path, is to identify exactly the places where we want to omit dependencies in order to make development a little less painful. So thanks for starting the discussion. `make 1` is an example of one such target: it prevents the dependencies of GHC being rebuilt. I think what you're additionally worried about is the "updating makefiles..." stages, which are also about consistency. If you want, you can cheat and omit these too; e.g. at the top level {{{ $ make -f ghc.mk all_ghc_stage1 compiler_stage1_NO_BUILD_DEPS=YES }}} this should be the fastest way to rebuild stage1. Perhaps this is something we should enshrine as a rule, or perhaps this should be what happens when you say `make 1`? I have some concerns about what could happen if you have touched something else in the tree - weird and wacky failures could ensue because we're not bringing the included makefiles up to date in the right order, but hopefully this wouldn't permanently kill your tree, and a top-level `make` should be able to recover. Let me know your experiences anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 18 06:43:08 2009 From: trac at galois.com (GHC) Date: Mon May 18 06:27:57 2009 Subject: [GHC] #3236: Would be nice if rts_lock (or similar) would fail when the RTS is not started In-Reply-To: <045.8ca5bdda229b63ae1e0185fe4d14f519@localhost> References: <045.8ca5bdda229b63ae1e0185fe4d14f519@localhost> Message-ID: <054.e4a869b4f0234f929fb6c6b1b1e923f4@localhost> #3236: Would be nice if rts_lock (or similar) would fail when the RTS is not started ---------------------------------+------------------------------------------ Reporter: duncan | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 18 06:49:57 2009 From: trac at galois.com (GHC) Date: Mon May 18 06:34:43 2009 Subject: [GHC] #3239: Bad jump on PowerPC In-Reply-To: <044.6398c5ce1c1a365bdb1a25c900ccade4@localhost> References: <044.6398c5ce1c1a365bdb1a25c900ccade4@localhost> Message-ID: <053.a40c639934e6bc24fe9bda51994f72cc@localhost> #3239: Bad jump on PowerPC ---------------------------------+------------------------------------------ Reporter: duane | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: see #3240 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 18 11:34:23 2009 From: trac at galois.com (GHC) Date: Mon May 18 11:19:10 2009 Subject: [GHC] #3241: System.Win32.Registry - incorrect length calculation in regSetStringValue Message-ID: <046.5e05961aa036dbf948d62b849e5dd19f@localhost> #3241: System.Win32.Registry - incorrect length calculation in regSetStringValue --------------------+------------------------------------------------------- Reporter: binarin | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- regSetStringValue calls regSetValueEx with length of value in characters, not in bytes. Due to this only first half of value is written to registry. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 18 15:46:03 2009 From: trac at galois.com (GHC) Date: Mon May 18 15:30:50 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.785328a38e76bfecea518bee48218e32@localhost> #3226: please eliminate error message from Make on every build ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by nr): * severity: trivial => minor Comment: Two comments: * Regarding the speed of the build, I think it is really worth exploring Glenn Fowler's nmake. nmake is engineered by real engineers to be portable and to work at scale. It is entirely possible that it might make the safe path also fast. It could even make it possible (although time- consuming and tedious) to eliminate the separate 'configure' step. What do you think of this as a possible student project? * Having established the safe but slow path, is there a way to make it less noisy? In particular, is there a way to change ghc/ghc.mk so that it does ''not'' bleat if the dependency file is missing? I have upgraded severity to 'minor' (from 'trivial') because this error message interrupts my workflow in emacs ({{{C-x `}}} now has to stop at an extra error message... sometimes). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 18 15:51:49 2009 From: trac at galois.com (GHC) Date: Mon May 18 15:36:37 2009 Subject: [GHC] #3153: Panic on syntactically wrong LANGUAGE pragma In-Reply-To: <046.e46bd4755ec7800cf1cf91fcd229221c@localhost> References: <046.e46bd4755ec7800cf1cf91fcd229221c@localhost> Message-ID: <055.520e1246d8d5f00fc47cffe813550b3c@localhost> #3153: Panic on syntactically wrong LANGUAGE pragma -------------------------------+-------------------------------------------- Reporter: b_jonas | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by jff): Reading the history, it seems that the bug is now fixed. However, I can still replicate it with ghc 6.10.3 Thanks, Joao -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 18 23:30:26 2009 From: trac at galois.com (GHC) Date: Mon May 18 23:15:10 2009 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) Message-ID: <045.426dc6319f98492c5b511466045bc0b5@localhost> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) --------------------+------------------------------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- On Windows, when attempting to use Hipmunk from ghci, it produces the error: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) To reproduce: cabal install Hipmunk ghci :m + Physics.Hipmunk initChipmunk Presumably this has something to do with there being no libm on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 04:10:34 2009 From: trac at galois.com (GHC) Date: Tue May 19 03:55:29 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.8ff5c42e39553d0ddfb0c954f95fa789@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): It's pretty clear we need to get this resolved. Here's my proposed plan, please tell me if any of this will have untoward consequences: * we use `O_NOHINHERIT` when opening files with `System.IO.openFile`. * when `close_fds` is `True`, and we are not redirecting any standard `HANDLE`s, we set `bInheritHandles` to `FALSE` when calling `CreateProcess` * we document the fact that `close_fds` only works on Windows when no `Handles` are being redirected. * we audit the libraries for other places that might need to create non- inheritable `HANDLE`s. We can aim to get these fixes into 6.10.4, but since 6.10.4 is supposed to be the last stable release on the 6.10 branch (like 6.10.3 was :-) we'll need a lot of testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 04:11:25 2009 From: trac at galois.com (GHC) Date: Tue May 19 03:56:16 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.b7b7946f65d6b8f7af263fbf3041e36e@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: => 6.10.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 04:27:45 2009 From: trac at galois.com (GHC) Date: Tue May 19 04:12:36 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.c71f57e1b2e61162dadb61b3de7438fb@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:17 simonmar]: > It's pretty clear we need to get this resolved. Here's my proposed plan, please tell me if any of this will have untoward consequences: All looks fine to me. > * when `close_fds` is `True`, and we are not redirecting any standard `HANDLE`s, we set `bInheritHandles` to `FALSE` when calling `CreateProcess` We should also keep a ticket open on this one to fix it fully in Vista using new APIs. In Vista we can pass `CreateProcess` a list of handles that will be inherited, ie the stdin/out pipe handles. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 04:42:07 2009 From: trac at galois.com (GHC) Date: Tue May 19 04:26:54 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.c3a7bde371000e96c4e01cac90b48fed@localhost> #3226: please eliminate error message from Make on every build ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:7 nr]: > Two comments: > > * Regarding the speed of the build, I think it is really worth exploring Glenn Fowler's nmake. nmake is engineered by real engineers to be portable and to work at scale. It is entirely possible that it might make the safe path also fast. It could even make it possible (although time-consuming and tedious) to eliminate the separate 'configure' step. What do you think of this as a possible student project? The speed of `make` is not the limiting factor. IIRC, at the end of a complete GHC build the single `make` process has used only a couple of seconds of CPU time. nmake may well be better than GNU make (though it's not clear that it does everything we need). Anyway I don't have the energy to rewrite the build system again right now - maybe in a few years! The real problem we would like to solve is the way GNU make handles rebuilding included makefiles, which leads to the need for the [wiki:Building/Architecture/Idiom/PhaseOrdering phase ordering]. This adds 4 seconds or so to each rebuild, not to mention complexity and fragility in the build system. Now, two of those phases are only needed because GHCs before 6.11 didn't generate makefile dependencies between packages in the way the new build system needs, so in the future when bootstrapping with 6.11+ we can drop the two slowest phases, which should help a lot. For now I've made `make 1` and `make 2` omit phases 1-3. It's much quicker for me now. > * Having established the safe but slow path, is there a way to make it less noisy? In particular, is there a way to change ghc/ghc.mk so that it does ''not'' bleat if the dependency file is missing? I have upgraded severity to 'minor' (from 'trivial') because this error message interrupts my workflow in emacs ({{{C-x `}}} now has to stop at an extra error message... sometimes). I agree the message is annoying, but I can't see an easy way to quiet it short of filtering the output of make (which is possible, but exceedingly ugly). Surely most of the time the dependency file will be there anyway? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 04:44:26 2009 From: trac at galois.com (GHC) Date: Tue May 19 04:29:11 2009 Subject: [GHC] #3153: Panic on syntactically wrong LANGUAGE pragma In-Reply-To: <046.e46bd4755ec7800cf1cf91fcd229221c@localhost> References: <046.e46bd4755ec7800cf1cf91fcd229221c@localhost> Message-ID: <055.f105dd0e352d0890a7db440db5f3955a@localhost> #3153: Panic on syntactically wrong LANGUAGE pragma -------------------------------+-------------------------------------------- Reporter: b_jonas | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonmar): Replying to [comment:6 jff]: > Reading the history, it seems that the bug is now fixed. However, I can still replicate it with ghc 6.10.3 The fix wasn't merged. It's not a high-priority fix because it's not breaking any essential functionality, and the further down the stable branch we get, the more cautious we are about merging fixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 06:27:05 2009 From: trac at galois.com (GHC) Date: Tue May 19 06:11:50 2009 Subject: [GHC] #3236: Would be nice if rts_lock (or similar) would fail when the RTS is not started In-Reply-To: <045.8ca5bdda229b63ae1e0185fe4d14f519@localhost> References: <045.8ca5bdda229b63ae1e0185fe4d14f519@localhost> Message-ID: <054.0aa66545b6b83c99bf0d46f1abcf5c40@localhost> #3236: Would be nice if rts_lock (or similar) would fail when the RTS is not started ---------------------------------+------------------------------------------ Reporter: duncan | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed * milestone: => 6.12.1 Comment: Done: {{{ Mon May 18 03:41:08 PDT 2009 Simon Marlow * Fix #3236: emit a helpful error message when the RTS has not been initialised }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 06:29:55 2009 From: trac at galois.com (GHC) Date: Tue May 19 06:14:42 2009 Subject: [GHC] #3228: please make it easier to remove a file from the GHC sources In-Reply-To: <041.5dbccaa2009317c73dad3a60d2601df8@localhost> References: <041.5dbccaa2009317c73dad3a60d2601df8@localhost> Message-ID: <050.b88cf528a94916222a96bccacfe9244b@localhost> #3228: please make it easier to remove a file from the GHC sources --------------------------------+------------------------------------------- Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | --------------------------------+------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Slightly faster: {{{ cd $TOP sh config.status make all_compiler_stage1 }}} or `all_compiler_stage2` if you prefer. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 06:31:38 2009 From: trac at galois.com (GHC) Date: Tue May 19 06:16:23 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.8690ef57e96a79490819e93bdc06e6d5@localhost> #3226: please eliminate error message from Make on every build ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): {{{ Tue May 19 01:33:50 PDT 2009 Simon Marlow * allow phases to be omitted by setting OMIT_PHASE_[123]=YES Tue May 19 01:34:19 PDT 2009 Simon Marlow * make [123] omits phases 1,2, and 3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 07:11:12 2009 From: trac at galois.com (GHC) Date: Tue May 19 06:56:08 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.8dab831a97e97bbd8c5e6553381149ea@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by NeilMitchell): So, to clarify: * What is the effect of {{{close_fds}}} on Windows? * If I redirect stdout and stdin to handles, will this bug still occur? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 07:23:23 2009 From: trac at galois.com (GHC) Date: Tue May 19 07:08:05 2009 Subject: [GHC] #3243: Forked gcc dies everytimes on Mac OS X 10.4.11 Message-ID: <042.b5fc3124e2d2545d38e0d3e9549dbed7@localhost> #3243: Forked gcc dies everytimes on Mac OS X 10.4.11 --------------------+------------------------------------------------------- Reporter: nwn | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- Forked gcc dies everytimes on Mac OS X 10.4.11, I saw this bug and reproduce it when building documents with haddock. Details are described at http://www.haskell.org/pipermail/libraries/2009-May/011732.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 08:18:50 2009 From: trac at galois.com (GHC) Date: Tue May 19 08:03:43 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.bf057d14ffef52ae4383c8f3bde43b28@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:20 NeilMitchell]: > So, to clarify: > > * What is the effect of {{{close_fds}}} on Windows? If you use `close_fds` and do not redirect stdin, stdout or stderr, then the child will not inherit any `HANDLE`s from the child. If you do redirect one or more standard handles, then `HANDLE`s created other than by `System.IO` and `System.Process` functions might be inherited, depending on how they were created. > * If I redirect stdout and stdin to handles, will this bug still occur? Not with respect to `HANDLE`s created by `System.IO` and `System.Process`, but it might occur if you manage to create `HANDLE`s using some other library. In that case you'll have to talk to the maintainer of said library and ask them to create their `HANDLE`s non-inheritable, or otherwise use Vista and wait until we implement the Vista-specific support for `close_fds`. Ok, everybody clear now? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 09:38:11 2009 From: trac at galois.com (GHC) Date: Tue May 19 09:23:05 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.a7ce2028361edcee2603cfce8dcd24e3@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:21 simonmar]: > Replying to [comment:20 NeilMitchell]: > > So, to clarify: > > > > * What is the effect of {{{close_fds}}} on Windows? > > If you use `close_fds` and do not redirect stdin, stdout or stderr, then the child will not inherit any `HANDLE`s from the child. If you do redirect one or more standard handles, then `HANDLE`s created other than by `System.IO` and `System.Process` functions might be inherited, depending on how they were created. This is the future intended behaviour. The current behaviour of course is that all file handles are opened in the inheritable state and all inheritable handles are always inherited by child processes, irrespective of the value of `close_fds`. > > * If I redirect stdout and stdin to handles, will this bug still occur? > > Not with respect to `HANDLE`s created by `System.IO` and `System.Process`, but it might occur if you manage to create `HANDLE`s using some other library. In that case you'll have to talk to the maintainer of said library and ask them to create their `HANDLE`s non- inheritable, or otherwise use Vista and wait until we implement the Vista- specific support for `close_fds`. It will also be the case that the pipes created to talk to one child process may be inherited by another child process started at a similar time. This is a problem if you are spawning processes in different security contexts. Sithin the same security context it should be benign because pipes have no equivalent to exclusive file locking which is what causes the permission denied errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 12:00:17 2009 From: trac at galois.com (GHC) Date: Tue May 19 11:45:03 2009 Subject: [GHC] #3243: Forked gcc dies everytimes on Mac OS X 10.4.11 In-Reply-To: <042.b5fc3124e2d2545d38e0d3e9549dbed7@localhost> References: <042.b5fc3124e2d2545d38e0d3e9549dbed7@localhost> Message-ID: <051.10b9ee94533f735e23ce8d2dff8cb932@localhost> #3243: Forked gcc dies everytimes on Mac OS X 10.4.11 ----------------------------------+----------------------------------------- Reporter: nwn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown Comment: We used to disable timers in the child of fork, but somehow that got lost between the version of process shipped with 6.8 and the one shipped with 6.10. I will look into what happened, there might be something else going on. It might be that we haven't seen any problems because on Linux we're not using itimers any more, we're using timer_create(). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 18:47:33 2009 From: trac at galois.com (GHC) Date: Tue May 19 18:32:15 2009 Subject: [GHC] #3244: Associated type panic Message-ID: <047.3ded0f46419be64adb8bf31f8672d4b1@localhost> #3244: Associated type panic ------------------------+--------------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: type family | Testcase: Os: Linux | Architecture: x86_64 (amd64) ------------------------+--------------------------------------------------- GHC panics with the attached use of associated types. Curiously, if I flatten the nested let-clauses in 'foo', the error goes away. {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-linux): initC: srt_lbl }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 22:28:24 2009 From: trac at galois.com (GHC) Date: Tue May 19 22:13:10 2009 Subject: [GHC] #3244: Associated type panic In-Reply-To: <047.3ded0f46419be64adb8bf31f8672d4b1@localhost> References: <047.3ded0f46419be64adb8bf31f8672d4b1@localhost> Message-ID: <056.015a7044d90b5e73dd6f32c45d6e7c9f@localhost> #3244: Associated type panic -------------------------------------+-------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: type family | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => duplicate Comment: Seems like a duplicate of #2799 to me (which has already been fixed in the development version). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 23:14:58 2009 From: trac at galois.com (GHC) Date: Tue May 19 22:59:39 2009 Subject: [GHC] #3245: Quadratic slowdown in Data.Typeable Message-ID: <044.8f6ad688a6e54aadf1867244399f152a@localhost> #3245: Quadratic slowdown in Data.Typeable -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.1 | Severity: major Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- Data.Typeable has a significant asymptotic performance problem. In the attached code, sum2 runs much slower than either sum1 or sum3. It should be linear but it seems to slow down quadratically (i.e. doubling "len" quadruples the time for sum2). Here is an example run: {{{ $ ghc --make -O3 CastSpeed.hs $ ./CastSpeed 20000 gsum1 Result: 200010000 Time(sec): 7.999e-3 Result: 200010000 Time(sec): 0.0 Result: 200010000 Time(sec): 1.0e-3 gsum2 Result: 200010000 Time(sec): 1.483774 Result: 200010000 Time(sec): 1.477776 Result: 200010000 Time(sec): 1.523768 gsum3 Result: 200010000 Time(sec): 5.999e-3 Result: 200010000 Time(sec): 0.0 Result: 200010000 Time(sec): 0.0 }}} The only difference between sum1 and sum2 is that sum2 wraps a singleton list around each element (i.e. the cast is to [Int] instead of Int). The only difference between sum2 and sum3 is that sum3 uses an unchecked cast (unsafeCoerce) instead of a checked cast. This problem seems to crop up only for those types which are made up of a type constructor applied to an argument (e.g. "[]" applied to "Int"). Because of sum3 runs fast, I suspect that something is going wrong with the "typeOf" call in a checked cast, and because sum1 runs fast I suspect that what is going wrong is the call to appKey that is called from mkAppTy that is called from typeOfDefault that is called from the Typeable instance for [Int] (i.e. instance (Typeable1 s, Typeable a) => Typeable (s a)). This is a bit of speculation and I don't have hard evidence for that being the source of the problems, but tests that I have run (not listed here) are strongly suggestive of appKey being the culprit. - Michael D. Adams -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 19 23:18:56 2009 From: trac at galois.com (GHC) Date: Tue May 19 23:03:37 2009 Subject: [GHC] #3245: Quadratic slowdown in Data.Typeable In-Reply-To: <044.8f6ad688a6e54aadf1867244399f152a@localhost> References: <044.8f6ad688a6e54aadf1867244399f152a@localhost> Message-ID: <053.5c2b6b2e1eceab126a8fa0d1b17c05b3@localhost> #3245: Quadratic slowdown in Data.Typeable --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------------------------+------------------------------------- Changes (by guest): * type: bug => run-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 20 04:53:51 2009 From: trac at galois.com (GHC) Date: Wed May 20 04:38:43 2009 Subject: [GHC] #3246: network accept returns server port number rather than client in some environments Message-ID: <050.bb60739a259c816d59ad9e58fc20337b@localhost> #3246: network accept returns server port number rather than client in some environments ------------------------+--------------------------------------------------- Reporter: Bart Massey | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ------------------------+--------------------------------------------------- I have a number of machines running Debian Linux. Most of them are running it in 32-bit mode. I also have a work machine that is an AMD64. On the AMD64 machine, Network.accept returns the server port number rather than the client port number. This seems to be true with ghc-6.8.3 and ghc-6.10.1, and with network-2.2.0.1 and network-2.2.1.2. It does not seem to happen on my 32-bit machines. Even when the wrong port number is returned, the handle seems to be perfectly good. Reproduce by running the attached test code and then telnetting to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 20 04:57:05 2009 From: trac at galois.com (GHC) Date: Wed May 20 04:41:45 2009 Subject: [GHC] #3247: GHCI segfaults when per-thread stack size is larger than max stack size Message-ID: <045.8f92b0bc876144cec71a99de4ec5ff73@localhost> #3247: GHCI segfaults when per-thread stack size is larger than max stack size --------------------+------------------------------------------------------- Reporter: earthy | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- This happened to me this morning; n142233:thesparse arthurvl$ ghci +RTS -H1024M -k128M -RTS Segmentation fault n142233:thesparse arthurvl$ ghci +RTS -H1024M -k8M -RTS Bus error Obviously this is a typo, but the response is somewhat unexpected. And yes, the heap-hint is needed, as without the heap hint it turns into: n142233:thesparse arthurvl$ ghci +RTS -k8M -RTS Too late for parseStaticFlags: call it before newSession n142233:thesparse arthurvl$ ghci +RTS -k128M -RTS Too late for parseStaticFlags: call it before newSession -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 20 04:58:48 2009 From: trac at galois.com (GHC) Date: Wed May 20 04:43:38 2009 Subject: [GHC] #3246: network accept returns server port number rather than client in some environments In-Reply-To: <050.bb60739a259c816d59ad9e58fc20337b@localhost> References: <050.bb60739a259c816d59ad9e58fc20337b@localhost> Message-ID: <059.a6d439ad23a9c4a5a8e093e1f703feac@localhost> #3246: network accept returns server port number rather than client in some environments -------------------------------+-------------------------------------------- Reporter: Bart Massey | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by tibbe): * status: new => closed * resolution: => invalid Comment: The network trac recently moved to http://trac.haskell.org/network . Please file a bug there. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 20 06:05:57 2009 From: trac at galois.com (GHC) Date: Wed May 20 05:50:39 2009 Subject: [GHC] #3247: GHCI segfaults when per-thread stack size is larger than max stack size In-Reply-To: <045.8f92b0bc876144cec71a99de4ec5ff73@localhost> References: <045.8f92b0bc876144cec71a99de4ec5ff73@localhost> Message-ID: <054.bf3143c9bf79015b094349f92789baae@localhost> #3247: GHCI segfaults when per-thread stack size is larger than max stack size -------------------------------+-------------------------------------------- Reporter: earthy | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Easy (1 hr) * component: GHCi => Runtime System * milestone: => 6.12.1 Old description: > This happened to me this morning; > > n142233:thesparse arthurvl$ ghci +RTS -H1024M -k128M -RTS > Segmentation fault > n142233:thesparse arthurvl$ ghci +RTS -H1024M -k8M -RTS > Bus error > > Obviously this is a typo, but the response is somewhat unexpected. > And yes, the heap-hint is needed, as without the heap hint it turns into: > > n142233:thesparse arthurvl$ ghci +RTS -k8M -RTS > Too late for parseStaticFlags: call it before newSession > n142233:thesparse arthurvl$ ghci +RTS -k128M -RTS > Too late for parseStaticFlags: call it before newSession New description: This happened to me this morning; {{{ n142233:thesparse arthurvl$ ghci +RTS -H1024M -k128M -RTS Segmentation fault n142233:thesparse arthurvl$ ghci +RTS -H1024M -k8M -RTS Bus error }}} Obviously this is a typo, but the response is somewhat unexpected. And yes, the heap-hint is needed, as without the heap hint it turns into: {{{ n142233:thesparse arthurvl$ ghci +RTS -k8M -RTS Too late for parseStaticFlags: call it before newSession n142233:thesparse arthurvl$ ghci +RTS -k128M -RTS Too late for parseStaticFlags: call it before newSession }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 20 07:45:56 2009 From: trac at galois.com (GHC) Date: Wed May 20 07:30:36 2009 Subject: [GHC] #3243: Forked gcc dies everytimes on Mac OS X 10.4.11 In-Reply-To: <042.b5fc3124e2d2545d38e0d3e9549dbed7@localhost> References: <042.b5fc3124e2d2545d38e0d3e9549dbed7@localhost> Message-ID: <051.ea6ea9898b4ab065c0267877608e2c8a@localhost> #3243: Forked gcc dies everytimes on Mac OS X 10.4.11 ----------------------------------+----------------------------------------- Reporter: nwn | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.4 Component: libraries/process | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * milestone: => 6.10.4 Comment: Fixed: {{{ Wed May 20 03:31:39 PDT 2009 Simon Marlow * Reinstate disableItimers() (#3243) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 20 08:26:58 2009 From: trac at galois.com (GHC) Date: Wed May 20 08:11:54 2009 Subject: [GHC] #3244: Associated type panic In-Reply-To: <047.3ded0f46419be64adb8bf31f8672d4b1@localhost> References: <047.3ded0f46419be64adb8bf31f8672d4b1@localhost> Message-ID: <056.5579844400745f58968ca07b275409ec@localhost> #3244: Associated type panic ----------------------------------------+----------------------------------- Reporter: heatsink | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: type family | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ----------------------------------------+----------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: I've checked and it's fine in HEAD, and even in 6.10.2 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 20 09:03:48 2009 From: trac at galois.com (GHC) Date: Wed May 20 08:48:29 2009 Subject: [GHC] #2966: build system does not respect --with-gcc= In-Reply-To: <045.38910ced362f70db06ad52953362394b@localhost> References: <045.38910ced362f70db06ad52953362394b@localhost> Message-ID: <054.88fad422514cdfe4c6721c11686b036e@localhost> #2966: build system does not respect --with-gcc= ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: The new build system does respect `--with-gcc` properly. I just did a complete build on Cygwin, with the gcc in my `PATH` pointing to a shell script that fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 20 13:00:54 2009 From: trac at galois.com (GHC) Date: Wed May 20 12:45:37 2009 Subject: [GHC] #3248: internal error: splitLargeBlog Message-ID: <042.a16a9634521cae64d42a8b147c2dc965@localhost> #3248: internal error: splitLargeBlog -----------------------------+---------------------------------------------- Reporter: odr | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- When I tried to run my program with options '''+RTS -k4M -K16M''' I got an error message: {{{ MyProgram.exe: internal error: splitLargeBlock: not a multiple of a megablock (GHC version 6.10.2 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} '' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 20 14:55:59 2009 From: trac at galois.com (GHC) Date: Wed May 20 14:40:48 2009 Subject: [GHC] #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) In-Reply-To: <044.a125e44de5957e50d259dfbe1a2d51e0@localhost> References: <044.a125e44de5957e50d259dfbe1a2d51e0@localhost> Message-ID: <053.aac8790ef2af485465a181b39366f0e9@localhost> #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by batterseapower): * cc: batterseapower@hotmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 20 16:15:39 2009 From: trac at galois.com (GHC) Date: Wed May 20 16:00:23 2009 Subject: [GHC] #3249: Unable to install Ghc packages by MacPorts Message-ID: <044.dc0b6710a1fe4a87afffd49eca65e4ab@localhost> #3249: Unable to install Ghc packages by MacPorts --------------------------+------------------------------------------------- Reporter: soopo | Owner: Type: bug | Status: new Priority: normal | Component: Package system Version: 6.10.1 | Severity: minor Keywords: mac, macports | Testcase: Os: MacOS X | Architecture: x86 --------------------------+------------------------------------------------- I was asked to send the following error here. I am not sure where the bug is. sudo port install hs-cabal hs-Crypto hs-libcabal ~ Password: ---> Fetching hs-HTTP ---> Attempting to fetch HTTP-3001.1.4.tar.gz from http://trd.no.distfiles.macports.org/hs-HTTP ---> Verifying checksum(s) for hs-HTTP ---> Extracting hs-HTTP ---> Configuring hs-HTTP ---> Building hs-HTTP ---> Staging hs-HTTP into destroot ---> Installing hs-HTTP @3001.1.4_0 ---> Activating hs-HTTP @3001.1.4_0 ---> Cleaning hs-HTTP ---> Fetching hs-libcabal ---> Attempting to fetch Cabal-1.6.0.1.tar.gz from http://trd.no.distfiles.macports.org/hs-libcabal ---> Verifying checksum(s) for hs-libcabal ---> Extracting hs-libcabal ---> Configuring hs-libcabal ---> Building hs-libcabal ---> Staging hs-libcabal into destroot ---> Installing hs-libcabal @1.6.0.1_0 ---> Activating hs-libcabal @1.6.0.1_0 ---> Cleaning hs-libcabal ---> Fetching hs-zlib ---> Attempting to fetch zlib-0.5.0.0.tar.gz from http://trd.no.distfiles.macports.org/hs-zlib ---> Verifying checksum(s) for hs-zlib ---> Extracting hs-zlib ---> Configuring hs-zlib ---> Building hs-zlib ---> Staging hs-zlib into destroot ---> Installing hs-zlib @0.5.0.0_0 ---> Activating hs-zlib @0.5.0.0_0 ---> Cleaning hs-zlib ---> Fetching hs-cabal ---> Attempting to fetch cabal-install-0.6.0.tar.gz from http://trd.no.distfiles.macports.org/hs-cabal ---> Verifying checksum(s) for hs-cabal ---> Extracting hs-cabal ---> Configuring hs-cabal ---> Building hs-cabal ---> Staging hs-cabal into destroot ---> Installing hs-cabal @0.6.0_0 ---> Activating hs-cabal @0.6.0_0 ---> Cleaning hs-cabal ---> Fetching hs-Crypto ---> Attempting to fetch Crypto-4.1.0.tar.gz from http://trd.no.distfiles.macports.org/hs-Crypto ---> Verifying checksum(s) for hs-Crypto ---> Extracting hs-Crypto ---> Configuring hs-Crypto ---> Building hs-Crypto Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports .org_release_ports_devel_hs-Crypto/work/Crypto-4.1.0 && runhaskell Setup build -v" returned error 1 Command output: In the instance declaration for `Integral (LargeKey a b)' Data/LargeWord.hs:137:9: Warning: No explicit method nor default method for `toRational' In the instance declaration for `Real (LargeKey a b)' Data/LargeWord.hs:140:9: Warning: No explicit method nor default method for `toEnum' In the instance declaration for `Enum (LargeKey a b)' Data/LargeWord.hs:140:9: Warning: No explicit method nor default method for `fromEnum' In the instance declaration for `Enum (LargeKey a b)' [10 of 11] Compiling Codec.Encryption.AES ( Codec/Encryption/AES.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Codec/Encryption/AES.o ) [11 of 11] Compiling Main ( SymmetricTest.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Main.o ) Linking dist/build/SymmetricTest/SymmetricTest ... Building executable: SHA1Test... Creating dist/build/SHA1Test (and its parents) Creating dist/build/SHA1Test/SHA1Test-tmp (and its parents) /opt/local/bin/ghc -o dist/build/SHA1Test/SHA1Test --make -hide-all- packages -no-user-package-conf -i -idist/build/SHA1Test/SHA1Test-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/SHA1Test/SHA1Test- tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/SHA1Test/SHA1Test-tmp -hidir dist/build/SHA1Test/SHA1Test-tmp -stubdir dist/build/SHA1Test/SHA1Test-tmp -package HUnit-1.2.0.3 -package QuickCheck-1.2.0.0 -package array-0.2.0.0 -package base-4.0.0.0 -package pretty-1.0.1.0 -package random-1.0.0.1 -O ./SHA1Test.hs [1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test /SHA1Test-tmp/Codec/Utils.o ) [2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o ) [3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o ) [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test /SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Error: Status 1 encountered during processing. [ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 20 17:23:23 2009 From: trac at galois.com (GHC) Date: Wed May 20 17:08:08 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.80eda390261b940dd310290cd9a1c918@localhost> #3226: please eliminate error message from Make on every build ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by nr): Replying to [comment:9 simonmar]: I certainly didn't mean to suggest that you even ''consider'' another attack on the build system! I really was thinking about a student ''here'' :-) I'm interested in nmake exactly because relative to gmake or standard make, nmake definitely requires fewer phase distinctions, and it may eliminate phase distinctions altogether. No phase distinctions -> no phase ordering -> speed. But it sounds like the hacks you've put in will help a lot. Surely most of the time the dependency file will be there anyway? Actually no. The problem is that I'm propagating a change in the representation of low-level intermediate code, and it will be a very long time before all the modules in the compiler are once again mutually consistent. And apparently as long as any module does not compile, GHC cannot generate the dependency file. I hope I am wrong about this and am just doing something stupid. Please say I am? If I'm not doing something stupid, can you suggest where I might go to filter the output of make in my own private world? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 21 00:13:59 2009 From: trac at galois.com (GHC) Date: Wed May 20 23:58:37 2009 Subject: [GHC] #3245: Quadratic slowdown in Data.Typeable In-Reply-To: <044.8f6ad688a6e54aadf1867244399f152a@localhost> References: <044.8f6ad688a6e54aadf1867244399f152a@localhost> Message-ID: <053.23412ece571e536c623ed3b5026ac3c1@localhost> #3245: Quadratic slowdown in Data.Typeable --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.1 Severity: major | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------------------------+------------------------------------- Comment (by guest): As demonstration that the slowness in the cast is from the typeOf call see the attached {{{TypeOfSpeed.hs}}}. Example run: {{{ $ ghc --make -O3 TypeOfSpeed.hs [1 of 1] Compiling Main ( TypeOfSpeed.hs, TypeOfSpeed.o ) Linking TypeOfSpeed ... $ ./TypeOfSpeed 20000 count1 Result: 20000 Time(sec): 9.998e-3 Result: 20000 Time(sec): 2.0e-3 Result: 20000 Time(sec): 2.0e-3 count2 Result: 20000 Time(sec): 1.455779 Result: 20000 Time(sec): 1.414784 Result: 20000 Time(sec): 1.415785 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 21 00:39:35 2009 From: trac at galois.com (GHC) Date: Thu May 21 00:24:12 2009 Subject: [GHC] #3250: Failed to load interface for `GHC' Message-ID: <050.2f9fde01f035f222ff003b67944178a9@localhost> #3250: Failed to load interface for `GHC' ------------------------+--------------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ------------------------+--------------------------------------------------- I was trying to build ghc-6.11.20090520 on Fedora 10 x86_64 with ghc-6.10.2 and got to: utils/runghc/ghc.mk:26: utils/runghc/dist/build/.depend: No such file or directory ghc/ghc.mk:95: ghc/stage2/build/.depend: No such file or directory /usr/bin/ghc -H32m -O -package-conf libraries/bootstrapping.conf -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen -Ighc/stage1/build -Ighc/stage1/build/autogen -package ghc-6.11 -XCPP -XPatternGuards -XForeignFunctionInterface -XUnboxedTuples -XFlexibleInstances -XMagicHash -fforce-recomp -optc-O0 -odir ghc/stage1/build -hidir ghc/stage1/build -stubdir ghc/stage1/build -hisuf hi -osuf o -hcsuf hc -c ghc/./Main.hs -o ghc/stage1/build/Main.o ghc/Main.hs:14:0: Failed to load interface for `GHC': There are files missing in the `ghc-6.11' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[2]: *** [ghc/stage1/build/Main.o] Error 1 make[1]: *** [all] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 21 00:42:28 2009 From: trac at galois.com (GHC) Date: Thu May 21 00:27:06 2009 Subject: [GHC] #3250: Failed to load interface for `GHC' In-Reply-To: <050.2f9fde01f035f222ff003b67944178a9@localhost> References: <050.2f9fde01f035f222ff003b67944178a9@localhost> Message-ID: <059.85b80236f585c7bca01a0a5f6ce8d38d@localhost> #3250: Failed to load interface for `GHC' -------------------------+-------------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------------+-------------------------------------------------- Comment (by juhpetersen): Bah, I keep forgetting to use markup here for output... Here again: {{{ utils/hpc/ghc.mk:19: utils/hpc/dist/build/.depend: No such file or directory utils/runghc/ghc.mk:26: utils/runghc/dist/build/.depend: No such file or directory ghc/ghc.mk:95: ghc/stage2/build/.depend: No such file or directory /usr/bin/ghc -H32m -O -package-conf libraries/bootstrapping.conf -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen -Ighc/stage1/build -Ighc/stage1/build/autogen -package ghc-6.11 -XCPP -XPatternGuards -XForeignFunctionInterface -XUnboxedTuples -XFlexibleInstances -XMagicHash -fforce-recomp -optc-O0 -odir ghc/stage1/build -hidir ghc/stage1/build -stubdir ghc/stage1/build -hisuf hi -osuf o -hcsuf hc -c ghc/./Main.hs -o ghc/stage1/build/Main.o ghc/Main.hs:14:0: Failed to load interface for `GHC': There are files missing in the `ghc-6.11' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[2]: *** [ghc/stage1/build/Main.o] Error 1 make[1]: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From marlowsd at gmail.com Thu May 21 04:18:11 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu May 21 04:02:52 2009 Subject: Linking hsc2hs .c output on Windows w/ build system: is it just me..? In-Reply-To: <49F79E17.4010103@galois.com> References: <49F2375E.4080608@galois.com> <49F59DFD.3070402@gmail.com> <49F79E17.4010103@galois.com> Message-ID: <4A150E43.3040200@gmail.com> On 29/04/2009 01:23, Sigbjorn Finne wrote: > Thanks Simon, > > sorry for not noticing your reply amidst the flow of g-h-b ticket reports > before now. As there is no need to sail that close to the wind of > playing with the delicate linking & loading orders of the CRT and > base DLLs like kernel32, my suggestion would be simply to avoid > it. You don't do any explicit "-lgcc -lc" trickery when invoking gcc/ld > on other platforms, so why be different? > > Apart from the changes to Win32.cabal and base.cabal mentioned > in the original e-mail, injecting addDLL() calls for kernel32 and > msvcrt in initLinker() ought to do it. I've now done exactly that. This seems like a good fix to try to get into 6.10.4 - can you think of any unexpected consequences? Cheers, Simon > --sigbjorn > > On 4/27/2009 04:58, Simon Marlow wrote: >> On 24/04/2009 23:04, Sigbjorn Finne wrote: >>> I've been experiencing repeated woes over the past 4-5 months >>> when trying to spin up build trees on Windows with the new build >>> system. This is happening on the 3-4 boxes that I regularly develop on, >>> which leads me to believe that this may not be limited to just me.. >>> >>> The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when >>> compiled and linked via the 'ghc' that's configured against, will >>> produce >>> .exe's that crashes right out of the gates. gdb'ing the generated >>> binaries, >>> the crash is happening in the CRT startup code & with some further >>> poking >>> around I've been able to determine that it is the explicit presence >>> of "-l" >>> options for 'kernel32' and 'msvcrt' when linking that's the cause. >>> This is >>> with a variety of versions of 'ld' and binutils snapshots (2.17.x -- >>> 2.19). >>> Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is >>> well-behaved, but ghc is still using gcc-3.4.5. >> >> We have seen this problem here on Satnam Singh's machine, but we >> eventually put it down to a conflict between versions of certain MSYS >> bits. There may indeed be a real problem here, I don't know. >> >> On Satnam's machine we established that the problem was provoked by >> updating binutils, and the solution was "don't do that" (Satnam had >> originally done this because the windres that comes with MSYS was >> incompatible with GHC, but that can be worked around by just copying >> in a suitable windres). >> >> We also tracked it down as far as compiling a trivial C program with >> -lmsvcrt. >> >> Incedentally if you follow the instructions on the wiki exactly, you >> won't run into this problem: >> http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. >> >>> There's a couple of things that are odd here: >>> >>> * base.cabal files have kernel32 and msvcrt as extra-libraries. This is >>> clearly >>> not required when doing invocations via ld(1), and causes considerable >>> mischief, >>> so it'd be good if there was a way in .cabal files to distinguish >>> between stuff that >>> goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's >>> InstalledPackageInfos. (Is there? Couldn't locate anything appropriate >>> while >>> working with the Cabal sources..) >>> >>> * 'base' needing to include these two dependencies even for GHCi >>> usage. A >>> running RTS will have these loaded already, so it really ought to have >>> primed >>> the list of opened DLLs by explicitly loading them upon initialization >>> of the linker. >>> [I've got a trivial patch against rts/Linker.c that does this; can >>> forward/commit if >>> of interest..] >> >> I've no idea why these library dependencies are there. It might well >> be historical. I'm happy to defer to Windows experts such as yourself >> on whether we should have them or not (I guess not?). >> >>> * In addition to the patch referred to above, to solve these problems, I >>> had to scrub >>> libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the >>> package.conf's for the >>> versions of ghc I'm building against had to be edited, limiting the use >>> of 'kernel32' >>> and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' >>> packages. >>> >>> Long and rambling..hope you made it this far ;-) Is anyone else running >>> into this issue & >>> should we do something about it? If not, details of compilation >>> environment that >>> you've got that avoids running into this issue would be most welcome. >>> It's a bit of a >>> chore spinning up new builds, as is. >> >> One open question is whether we should expect "gcc foo.c -lmsvcrt" to >> work. It works with older versions of MSYS/mingw, but apparently not >> with more recent versions. On the face of it this seems like it ought >> to be harmless, since msvcrt will eventually be linked in anyway. >> >> Cheers, >> Simon > From trac at galois.com Thu May 21 04:35:22 2009 From: trac at galois.com (GHC) Date: Thu May 21 04:20:00 2009 Subject: [GHC] #3241: System.Win32.Registry - incorrect length calculation in regSetStringValue In-Reply-To: <046.5e05961aa036dbf948d62b849e5dd19f@localhost> References: <046.5e05961aa036dbf948d62b849e5dd19f@localhost> Message-ID: <055.121c966f6a5e93e1eddebec834a11106@localhost> #3241: System.Win32.Registry - incorrect length calculation in regSetStringValue ----------------------------------+----------------------------------------- Reporter: binarin | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 21 04:52:31 2009 From: trac at galois.com (GHC) Date: Thu May 21 04:37:11 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.9105cd003e6adc5aefb98386c57d6417@localhost> #3226: please eliminate error message from Make on every build ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:10 nr]: > Replying to [comment:9 simonmar]: > > Surely most of the time the dependency file will be there anyway? > > Actually no. The problem is that I'm propagating a change in the representation of low-level intermediate code, and it will be a very long time before all the modules in the compiler are once again mutually consistent. And apparently as long as any module does not compile, GHC cannot generate the dependency file. I hope I am wrong about this and am just doing something stupid. Please say I am? If I touch a source file in the compiler and then say `make 1` (in `compiler/`), I don't see the error message. Even if I just say `make` in `compiler`, which rebuilds the dependencies if anything is out of date, I still don't see the error message. If you start from a position where you don't have the dependency file, then you do need to get to a state where all the imports exist in order to build the dependencies (the dependency-generator parses each source file up the end of the imports, so errors further down won't affect it). > If I'm not doing something stupid, can you suggest where I might go to filter the output of make in my own private world? In the top-level `Makefile`, something like this: {{{ @echo "===--- finished updating makefiles" $(MAKE) -r --no-print-directory -f ghc.mk $@ | sed 'd/.depend: No such file or directory/' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 21 05:22:34 2009 From: trac at galois.com (GHC) Date: Thu May 21 05:07:14 2009 Subject: [GHC] #3201: ar: Bad file number In-Reply-To: <047.ca53a7792b62a7186d0a18c99b7dae36@localhost> References: <047.ca53a7792b62a7186d0a18c99b7dae36@localhost> Message-ID: <056.57c24ae55fc91d7535c7bdc79dcff616@localhost> #3201: ar: Bad file number -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 21 07:57:32 2009 From: trac at galois.com (GHC) Date: Thu May 21 07:42:11 2009 Subject: [GHC] #3201: ar: Bad file number In-Reply-To: <047.ca53a7792b62a7186d0a18c99b7dae36@localhost> References: <047.ca53a7792b62a7186d0a18c99b7dae36@localhost> Message-ID: <056.791af8bf4b248026f741cab225c3ac46@localhost> #3201: ar: Bad file number -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: {{{ Thu May 21 03:31:31 PDT 2009 Simon Marlow * Fix #3201: "ar: Bad file number" build error with MSYS and SplitObjs=YES }}} Incedentally: 32767 didn't work for me, but 30000 did. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 21 08:07:10 2009 From: trac at galois.com (GHC) Date: Thu May 21 07:51:49 2009 Subject: [GHC] #2650: Child processes always unwantedly inherit Handles on Windows In-Reply-To: <047.1449ef20e3242d7624bded23f58b28e1@localhost> References: <047.1449ef20e3242d7624bded23f58b28e1@localhost> Message-ID: <056.f62ebac2c0951632df9f79c34fa9f885@localhost> #2650: Child processes always unwantedly inherit Handles on Windows ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries (other) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by simonmar): See also #3231 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 21 08:08:32 2009 From: trac at galois.com (GHC) Date: Thu May 21 07:53:19 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.ecf1c104f05a909115cb5ae1ae55efc1@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Done. In base: {{{ Wed May 20 06:09:26 PDT 2009 Simon Marlow * add _O_NOINHERIT when opening files on Windows (see #2650) }}} In process (this also fixes the documentation for close_fds): {{{ Wed May 20 07:07:26 PDT 2009 Simon Marlow * partially implement close_fds on Windows (#3231) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 21 08:29:24 2009 From: trac at galois.com (GHC) Date: Thu May 21 08:14:01 2009 Subject: [GHC] #3251: split rts headers into public and private Message-ID: <045.c36f62f5a06285c15ad56ab2ce446706@localhost> #3251: split rts headers into public and private -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- C code calling into the rts, eg to initialise it, uses header files like `HsFFI.h` or `RtsAPI.h`. However these header files that describe the public API of the rts are installed in `$libdir/ghc-x.y/include` where as the standard location for public header files should be `$prefix/include/ghc-x.y`. The private header files that are only used by `.hc` files when compiling `-fvia-C` should remain where they are. So this would involve identifying which headers are public and which are private. Once we have a set of public header files it might be nice to provide a `pkg-config` .pc file to make it easy for C programs to locate the header files and libraries. Eg it should be possible to compile and link a C program that uses the RTS public API with just: {{{ gcc -o main main.c `pkg-config --cflags --libs ghc-rts-6.12.1` }}} and this would supply the flags like {{{ -I/usr/include/ghc-6.12.1 -lHSrts -L/usr/lib/ghc-6.12.1 }}} Note that `pkg-config` supports both shared and static libs (ie allows specifying the extra private deps of a static lib, eg `-lm -ldl` etc). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 21 10:02:36 2009 From: trac at galois.com (GHC) Date: Thu May 21 09:47:12 2009 Subject: [GHC] #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain Message-ID: <045.7911c27a1a92708be5cdea967d156927@localhost> #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- For C code calling C functions exported from Haskell code, it has to jump through a couple hoops first. The call to `hs_init()` is fair enough and is specified by the FFI, however GHC also makes us call: {{{ hs_add_root(__stginit_Foo); }}} for the top level Haskell module that exports the function we're interested in. If there are multiple such modules and they don't depend on each other then presumably we have to call them all. Doing this is a bit annoying. It's not just that we have to call it, but we have to work out which symbols we need exactly. Are there any ways we could automate it? If the `__stginit_*` functions are really cheap then can we just have them called as constructor functions using gcc's `__attribute__ ((constructor))` system. If they're slightly more expensive then perhaps they could be registered in a constructor and called by `hs_init()`. Or can we have them run lazily, eg have the exported C functions check that the module they're in has been initialised. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 21 18:30:34 2009 From: trac at galois.com (GHC) Date: Thu May 21 18:15:09 2009 Subject: [GHC] #3253: validate failure (GCC warning) Message-ID: <050.ebb2294c3e42762e8bd80739a4e081c3@localhost> #3253: validate failure (GCC warning) ------------------------+--------------------------------------------------- Reporter: isaacdupree | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 ------------------------+--------------------------------------------------- compiling on Ubuntu "Jaunty" 9.04, bootstrapping HEAD using its packages with `env CPUS=2 ./validate`: packages: {{{ gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3 The Glorious Glasgow Haskell Compilation System, version 6.8.2 Happy Version 1.17 Alex version 2.2 }}} error: {{{ inplace/bin/ghc-stage1 -optc-Werror -optc-Ilibraries/process/include -optc-Dbase4 -optc-I/Users/me/gsoc2009/builds/1/libraries/directory/include -optc-I/Users/me/gsoc2009/builds/1/libraries/unix/include -optc-I/Users/me/gsoc2009/builds/1/libraries/old-time/include -optc-I/Users/me/gsoc2009/builds/1/libraries/base/include -optc-I/Users/me/gsoc2009/builds/1/includes -optc-I/Users/me/gsoc2009/builds/1/libffi/build/include -Werror -H64m -O0 -fasm -package-name process-1.0.1.1 -hide-all-packages -i -ilibraries/process/. -ilibraries/process/dist-install/build -ilibraries/process/dist-install/build/autogen -Ilibraries/process/dist- install/build -Ilibraries/process/dist-install/build/autogen -Ilibraries/process/include -optP-Dbase4 -optP-include -optPlibraries/process/dist-install/build/autogen/cabal_macros.h -package base-4.0.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package unix-2.3.1.0 -XCPP -O -fasm -dcore-lint -fno-warn-deprecated-flags -c libraries/process/cbits/runProcess.c -o libraries/process/dist- install/build/cbits/runProcess.o #[I deleted unrelated stuff here from parallel make / CPUS=2] cc1: warnings being treated as errors libraries/process/cbits/runProcess.c: In function ?runInteractiveProcess?: libraries/process/cbits/runProcess.c:51:0: error: ignoring return value of ?pipe?, declared with attribute warn_unused_result libraries/process/cbits/runProcess.c:54:0: error: ignoring return value of ?pipe?, declared with attribute warn_unused_result libraries/process/cbits/runProcess.c:57:0: error: ignoring return value of ?pipe?, declared with attribute warn_unused_result }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From sof at galois.com Thu May 21 18:39:11 2009 From: sof at galois.com (Sigbjorn Finne) Date: Thu May 21 18:23:49 2009 Subject: Linking hsc2hs .c output on Windows w/ build system: is it just me..? In-Reply-To: <4A150E43.3040200@gmail.com> References: <49F2375E.4080608@galois.com> <49F59DFD.3070402@gmail.com> <49F79E17.4010103@galois.com> <4A150E43.3040200@gmail.com> Message-ID: <4A15D80F.2010001@galois.com> Simon Marlow wrote: > On 29/04/2009 01:23, Sigbjorn Finne wrote: >> Thanks Simon, >> >> sorry for not noticing your reply amidst the flow of g-h-b ticket >> reports >> before now. As there is no need to sail that close to the wind of >> playing with the delicate linking & loading orders of the CRT and >> base DLLs like kernel32, my suggestion would be simply to avoid >> it. You don't do any explicit "-lgcc -lc" trickery when invoking gcc/ld >> on other platforms, so why be different? >> >> Apart from the changes to Win32.cabal and base.cabal mentioned >> in the original e-mail, injecting addDLL() calls for kernel32 and >> msvcrt in initLinker() ought to do it. > > I've now done exactly that. This seems like a good fix to try to get > into 6.10.4 - can you think of any unexpected consequences? > Cool, given that the RTS already has those two DLLs loaded & repeated addDLL()s is fine (i.e., if other packages contain e.g., "kernel32" uses), I can't think of any...other than possibly more contribs from people building on Windows ;-) If you feel the risk is not worth taking for 6.10.4, I'm totally fine with pushing it out. thanks, --sigbjorn From trac at galois.com Fri May 22 00:18:55 2009 From: trac at galois.com (GHC) Date: Fri May 22 00:03:30 2009 Subject: [GHC] #3254: add a configure option to turn off profiling Message-ID: <050.9d9a599d02ae49f1bbe8ca17c16117c7@localhost> #3254: add a configure option to turn off profiling -----------------------------+---------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It is a bit tedious right now have to track GhcLibWays, etc by hand to turn off building of prof libs, etc. It would be nice to have a simple configure option just to turn off profiling (eg --without-profiling) to do this. Things might be slightly better with 6.11 but I think it probably applies there too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 00:23:20 2009 From: trac at galois.com (GHC) Date: Fri May 22 00:07:56 2009 Subject: [GHC] #3255: libHSrts_thr_p.a created even when profiling disabled Message-ID: <050.c854079b768a4d9131926f41c4970c00@localhost> #3255: libHSrts_thr_p.a created even when profiling disabled -----------------------------+---------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- When I build ghc-6.10.3 with: {{{ GhcLibWays= }}} to disable prof libraries, libHSrts_thr_p.a is still made. Is that intentional? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 05:34:45 2009 From: trac at galois.com (GHC) Date: Fri May 22 05:19:20 2009 Subject: [GHC] #3253: validate failure (GCC warning) In-Reply-To: <050.ebb2294c3e42762e8bd80739a4e081c3@localhost> References: <050.ebb2294c3e42762e8bd80739a4e081c3@localhost> Message-ID: <059.426eb3b7a3952c1a5e977d8d286717ad@localhost> #3253: validate failure (GCC warning) ----------------------------------+----------------------------------------- Reporter: isaacdupree | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/process | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * component: Compiler => libraries/process * milestone: => 6.12.1 Comment: Yes, I have a fix for this on my laptop. Will push shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 05:39:14 2009 From: trac at galois.com (GHC) Date: Fri May 22 05:23:49 2009 Subject: [GHC] #3254: add a configure option to turn off profiling In-Reply-To: <050.9d9a599d02ae49f1bbe8ca17c16117c7@localhost> References: <050.9d9a599d02ae49f1bbe8ca17c16117c7@localhost> Message-ID: <059.ec6abcbc53862cd0460a8babab7f8aee@localhost> #3254: add a configure option to turn off profiling ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: We have to strike a balance between how much to make into configure options, and how much to leave as `build.mk` settings. Currently we leave most things in `build.mk`, because the danger is that when we start putting things into `configure` it's hard to know when to stop, and then we have two ways to configure lots of things, and a lot of extra m4 code to go wrong. Also, `build.mk` is persistent, whereas configure options have to be specified every time you run configure. So I tend the to view that we shouldn't do this. What do others think? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 05:40:33 2009 From: trac at galois.com (GHC) Date: Fri May 22 05:25:08 2009 Subject: [GHC] #3255: libHSrts_thr_p.a created even when profiling disabled In-Reply-To: <050.c854079b768a4d9131926f41c4970c00@localhost> References: <050.c854079b768a4d9131926f41c4970c00@localhost> Message-ID: <059.86ee07f22fd2605cc5c626b7a67cae9b@localhost> #3255: libHSrts_thr_p.a created even when profiling disabled ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed * milestone: => 6.12.1 Comment: Fixed in the new build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 05:47:39 2009 From: trac at galois.com (GHC) Date: Fri May 22 05:32:13 2009 Subject: [GHC] #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain In-Reply-To: <045.7911c27a1a92708be5cdea967d156927@localhost> References: <045.7911c27a1a92708be5cdea967d156927@localhost> Message-ID: <054.8c37f504207a8f23c9845e086076f564@localhost> #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: Generating constructor functions in Haskell modules would be a bit tricky, because we'd have to generate code that has the C calling convention, and neither the NCG nor the mangler knows how to do that. Something along the lines of the last method (have the exported C functions check that the module they're in has been initialised) might be possible. But we have to be careful not to add too much overhead to the call-in path. I'll think some more about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 07:28:38 2009 From: trac at galois.com (GHC) Date: Fri May 22 07:13:14 2009 Subject: [GHC] #3207: readMutVar# is inlined/duplicated In-Reply-To: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> References: <047.8a8413861ff44b299752f57fbbb1dfd5@localhost> Message-ID: <056.5b2ce024096378740bde40852277e81d@localhost> #3207: readMutVar# is inlined/duplicated ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 07:40:37 2009 From: trac at galois.com (GHC) Date: Fri May 22 07:25:12 2009 Subject: [GHC] #3253: validate failure (GCC warning) In-Reply-To: <050.ebb2294c3e42762e8bd80739a4e081c3@localhost> References: <050.ebb2294c3e42762e8bd80739a4e081c3@localhost> Message-ID: <059.f3d54ba32aa66b3175586e5e5f979f99@localhost> #3253: validate failure (GCC warning) ----------------------------------+----------------------------------------- Reporter: isaacdupree | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/process | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed. In GHC: {{{ Sat Mar 28 12:13:55 PDT 2009 Simon Marlow * export sysErrorBelch }} and process: {{{ Fri Mar 27 14:24:16 PDT 2009 Simon Marlow * check return value from pipe() (quiets gcc) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 10:15:17 2009 From: trac at galois.com (GHC) Date: Fri May 22 10:00:09 2009 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.0e23eca3ccf5d5a28e3fabbc43a881e5@localhost> #1969: enormous compile times ---------------------------------------------+------------------------------ Reporter: duncan | Owner: igloo Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: performance | Difficulty: Difficult (1 week) Testcase: T1969 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * type: merge => compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 11:09:42 2009 From: trac at galois.com (GHC) Date: Fri May 22 10:54:18 2009 Subject: [GHC] #3243: Forked gcc dies everytimes on Mac OS X 10.4.11 In-Reply-To: <042.b5fc3124e2d2545d38e0d3e9549dbed7@localhost> References: <042.b5fc3124e2d2545d38e0d3e9549dbed7@localhost> Message-ID: <051.3f250dcbb1ea7a4905f02cc51f156da7@localhost> #3243: Forked gcc dies everytimes on Mac OS X 10.4.11 ----------------------------------+----------------------------------------- Reporter: nwn | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.4 Component: libraries/process | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 11:10:22 2009 From: trac at galois.com (GHC) Date: Fri May 22 10:55:06 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.ad2add4eec8a21fb5e52ba52466d378b@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 11:47:06 2009 From: trac at galois.com (GHC) Date: Fri May 22 11:31:40 2009 Subject: [GHC] #3256: Extra EOT from NoBuffering mode in emacs Message-ID: <044.f071539e68c72dff76745c9af1d974f7@localhost> #3256: Extra EOT from NoBuffering mode in emacs -------------------+-------------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- Compile the following program: {{{ import System.IO main = hSetBuffering stdin NoBuffering >> getLine >>= print }}} Then start emacs, run M-x shell, and start the above program. Paste the output of {{{replicate 252 'x'}}} as input and press return. An extra EOT character is added to the end of the input: {{{ $ ./foo "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" "\"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\"\\ EOT" }}} I can make this happen consistently using Ubuntu 8.04.2 and emacs-22.1.1. I can't reproduce it on OS X or outside of emacs's shell. This was originally reported on the Haskeline bug tracker, as it affects ghci/haskeline: http://trac.haskell.org/haskeline/ticket/79 . From that ticket: > The problem seems to be that Emacs does not send all of the input at > once: > If STRING is more than 500 characters long, it is sent in several > bunches. This may happen even for shorter strings. > (From the documentation of process-send-string in GNU Emacs 23.0.93.1.) See also the following message: http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/15591/focus=15632. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 12:35:39 2009 From: trac at galois.com (GHC) Date: Fri May 22 12:20:13 2009 Subject: [GHC] #3256: Extra EOT from NoBuffering mode in emacs In-Reply-To: <044.f071539e68c72dff76745c9af1d974f7@localhost> References: <044.f071539e68c72dff76745c9af1d974f7@localhost> Message-ID: <053.a6ee0e6d766c033be86d24d46f23024d@localhost> #3256: Extra EOT from NoBuffering mode in emacs ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.4 Comment: This may be related to the {{{ : hLookAhead: invalid argument (Bad file descriptor) }}} failures that we get for some GHCi tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 22 13:54:26 2009 From: trac at galois.com (GHC) Date: Fri May 22 13:39:02 2009 Subject: [GHC] #3253: validate failure (GCC warning) In-Reply-To: <050.ebb2294c3e42762e8bd80739a4e081c3@localhost> References: <050.ebb2294c3e42762e8bd80739a4e081c3@localhost> Message-ID: <059.ae5d545555fdf03ce1dd63423fc8c5c4@localhost> #3253: validate failure (GCC warning) ----------------------------------+----------------------------------------- Reporter: isaacdupree | Owner: simonmar Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: libraries/process | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by isaacdupree): * status: closed => reopened * resolution: fixed => Comment: :-( I pulled those changes, and now I'm getting another validate-fail-due- to-GCC-warning {{{ depbase=`echo src/closures.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I./include -Iinclude -I./src -Wall -g -fexceptions -O -g -O2 -Werror -MT src/closures.lo -MD -MP -MF $depbase.Tpo -c -o src/closures.lo src/closures.c &&\ mv -f $depbase.Tpo $depbase.Plo gcc -DHAVE_CONFIG_H -I. -I. -I./include -Iinclude -I./src -Wall -g -fexceptions -O -g -O2 -Werror -MT src/closures.lo -MD -MP -MF src/.deps/closures.Tpo -c src/closures.c -o src/closures.o cc1: warnings being treated as errors src/closures.c: In function ?dlmmap_locked?: src/closures.c:383: error: ignoring return value of ?ftruncate?, declared with attribute warn_unused_result src/closures.c:395: error: ignoring return value of ?ftruncate?, declared with attribute warn_unused_result make[4]: *** [src/closures.lo] Error 1 make[4]: Leaving directory `/Users/me/gsoc2009/builds/2/libffi/build' }}} is there any way I can be more helpful in case there are more of these? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 09:34:08 2009 From: trac at galois.com (GHC) Date: Sat May 23 09:18:43 2009 Subject: [GHC] #1717: ghc-6.8 configure does not recognise 32bit userland on ppc64 In-Reply-To: <059.9ba98474c2b63eccc55349ae913ba846@localhost> References: <059.9ba98474c2b63eccc55349ae913ba846@localhost> Message-ID: <068.e8b7e2451e94765cde25b4d20b36a71b@localhost> #1717: ghc-6.8 configure does not recognise 32bit userland on ppc64 -------------------------------------+-------------------------------------- Reporter: kahl@cas.mcmaster.ca | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Build System | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: normal build | Os: Linux Architecture: powerpc64 | -------------------------------------+-------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: We now get the platform from the bootstrapping compiler's `ghc +RTS --info` output. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 14:11:59 2009 From: trac at galois.com (GHC) Date: Sat May 23 13:56:30 2009 Subject: [GHC] #3235: ghci-6.10.3 can't be built with readline support In-Reply-To: <044.a6ba63b94ae8bd7f8acc72d9aa9a1eda@localhost> References: <044.a6ba63b94ae8bd7f8acc72d9aa9a1eda@localhost> Message-ID: <053.95dec734785512a0fa01f1e58345074a@localhost> #3235: ghci-6.10.3 can't be built with readline support ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: minor | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: I agree that time would be better spent improving haskeline than trying to maintain, and test, a readline alternative. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 14:23:30 2009 From: trac at galois.com (GHC) Date: Sat May 23 14:08:00 2009 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@localhost> References: <045.426dc6319f98492c5b511466045bc0b5@localhost> Message-ID: <054.c53383b4dd43f5d88873eb60ccb53a83@localhost> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) -----------------------+---------------------------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks for the report. The hipmunk cabal file unconditionally says {{{ Extra-Libraries: m }}} so this is a bug in hipmunk, not GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 14:32:22 2009 From: trac at galois.com (GHC) Date: Sat May 23 14:16:54 2009 Subject: [GHC] #3249: Unable to install Ghc packages by MacPorts In-Reply-To: <044.dc0b6710a1fe4a87afffd49eca65e4ab@localhost> References: <044.dc0b6710a1fe4a87afffd49eca65e4ab@localhost> Message-ID: <053.4e5354333ab9b23467fc9c79fa92a38f@localhost> #3249: Unable to install Ghc packages by MacPorts -------------------------------+-------------------------------------------- Reporter: soopo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 6.10.1 Severity: minor | Resolution: Keywords: mac, macports | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > I was asked to send the following error here. > I am not sure where the bug is. > > sudo port install hs-cabal hs-Crypto hs-libcabal > ~ > Password: > ---> Fetching hs-HTTP > ---> Attempting to fetch HTTP-3001.1.4.tar.gz from > http://trd.no.distfiles.macports.org/hs-HTTP > ---> Verifying checksum(s) for hs-HTTP > ---> Extracting hs-HTTP > ---> Configuring hs-HTTP > ---> Building hs-HTTP > ---> Staging hs-HTTP into destroot > ---> Installing hs-HTTP @3001.1.4_0 > ---> Activating hs-HTTP @3001.1.4_0 > ---> Cleaning hs-HTTP > ---> Fetching hs-libcabal > ---> Attempting to fetch Cabal-1.6.0.1.tar.gz from > http://trd.no.distfiles.macports.org/hs-libcabal > ---> Verifying checksum(s) for hs-libcabal > ---> Extracting hs-libcabal > ---> Configuring hs-libcabal > ---> Building hs-libcabal > ---> Staging hs-libcabal into destroot > ---> Installing hs-libcabal @1.6.0.1_0 > ---> Activating hs-libcabal @1.6.0.1_0 > ---> Cleaning hs-libcabal > ---> Fetching hs-zlib > ---> Attempting to fetch zlib-0.5.0.0.tar.gz from > http://trd.no.distfiles.macports.org/hs-zlib > ---> Verifying checksum(s) for hs-zlib > ---> Extracting hs-zlib > ---> Configuring hs-zlib > ---> Building hs-zlib > ---> Staging hs-zlib into destroot > ---> Installing hs-zlib @0.5.0.0_0 > ---> Activating hs-zlib @0.5.0.0_0 > ---> Cleaning hs-zlib > ---> Fetching hs-cabal > ---> Attempting to fetch cabal-install-0.6.0.tar.gz from > http://trd.no.distfiles.macports.org/hs-cabal > ---> Verifying checksum(s) for hs-cabal > ---> Extracting hs-cabal > ---> Configuring hs-cabal > ---> Building hs-cabal > ---> Staging hs-cabal into destroot > ---> Installing hs-cabal @0.6.0_0 > ---> Activating hs-cabal @0.6.0_0 > ---> Cleaning hs-cabal > ---> Fetching hs-Crypto > ---> Attempting to fetch Crypto-4.1.0.tar.gz from > http://trd.no.distfiles.macports.org/hs-Crypto > ---> Verifying checksum(s) for hs-Crypto > ---> Extracting hs-Crypto > ---> Configuring hs-Crypto > ---> Building hs-Crypto > Error: Target org.macports.build returned: shell command "cd > /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports > .org_release_ports_devel_hs-Crypto/work/Crypto-4.1.0 && runhaskell Setup > build -v" returned error 1 > Command output: In the instance declaration for `Integral (LargeKey a > b)' > > Data/LargeWord.hs:137:9: > Warning: No explicit method nor default method for `toRational' > In the instance declaration for `Real (LargeKey a b)' > > Data/LargeWord.hs:140:9: > Warning: No explicit method nor default method for `toEnum' > In the instance declaration for `Enum (LargeKey a b)' > > Data/LargeWord.hs:140:9: > Warning: No explicit method nor default method for `fromEnum' > In the instance declaration for `Enum (LargeKey a b)' > [10 of 11] Compiling Codec.Encryption.AES ( Codec/Encryption/AES.hs, > dist/build/SymmetricTest/SymmetricTest-tmp/Codec/Encryption/AES.o ) > [11 of 11] Compiling Main ( SymmetricTest.hs, > dist/build/SymmetricTest/SymmetricTest-tmp/Main.o ) > Linking dist/build/SymmetricTest/SymmetricTest ... > Building executable: SHA1Test... > Creating dist/build/SHA1Test (and its parents) > Creating dist/build/SHA1Test/SHA1Test-tmp (and its parents) > /opt/local/bin/ghc -o dist/build/SHA1Test/SHA1Test --make -hide-all- > packages -no-user-package-conf -i -idist/build/SHA1Test/SHA1Test-tmp -i. > -idist/build/autogen -Idist/build/autogen -Idist/build/SHA1Test/SHA1Test- > tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir > dist/build/SHA1Test/SHA1Test-tmp -hidir dist/build/SHA1Test/SHA1Test-tmp > -stubdir dist/build/SHA1Test/SHA1Test-tmp -package HUnit-1.2.0.3 -package > QuickCheck-1.2.0.0 -package array-0.2.0.0 -package base-4.0.0.0 -package > pretty-1.0.1.0 -package random-1.0.0.1 -O ./SHA1Test.hs > [1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test > /SHA1Test-tmp/Codec/Utils.o ) > [2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, > dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o ) > [3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, > dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o ) > [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test > /SHA1Test-tmp/Main.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.1 for i386-apple-darwin): > RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Error: Status 1 encountered during processing. > [ New description: I was asked to send the following error here. I am not sure where the bug is. {{{ sudo port install hs-cabal hs-Crypto hs-libcabal ~ Password: ---> Fetching hs-HTTP ---> Attempting to fetch HTTP-3001.1.4.tar.gz from http://trd.no.distfiles.macports.org/hs-HTTP ---> Verifying checksum(s) for hs-HTTP ---> Extracting hs-HTTP ---> Configuring hs-HTTP ---> Building hs-HTTP ---> Staging hs-HTTP into destroot ---> Installing hs-HTTP @3001.1.4_0 ---> Activating hs-HTTP @3001.1.4_0 ---> Cleaning hs-HTTP ---> Fetching hs-libcabal ---> Attempting to fetch Cabal-1.6.0.1.tar.gz from http://trd.no.distfiles.macports.org/hs-libcabal ---> Verifying checksum(s) for hs-libcabal ---> Extracting hs-libcabal ---> Configuring hs-libcabal ---> Building hs-libcabal ---> Staging hs-libcabal into destroot ---> Installing hs-libcabal @1.6.0.1_0 ---> Activating hs-libcabal @1.6.0.1_0 ---> Cleaning hs-libcabal ---> Fetching hs-zlib ---> Attempting to fetch zlib-0.5.0.0.tar.gz from http://trd.no.distfiles.macports.org/hs-zlib ---> Verifying checksum(s) for hs-zlib ---> Extracting hs-zlib ---> Configuring hs-zlib ---> Building hs-zlib ---> Staging hs-zlib into destroot ---> Installing hs-zlib @0.5.0.0_0 ---> Activating hs-zlib @0.5.0.0_0 ---> Cleaning hs-zlib ---> Fetching hs-cabal ---> Attempting to fetch cabal-install-0.6.0.tar.gz from http://trd.no.distfiles.macports.org/hs-cabal ---> Verifying checksum(s) for hs-cabal ---> Extracting hs-cabal ---> Configuring hs-cabal ---> Building hs-cabal ---> Staging hs-cabal into destroot ---> Installing hs-cabal @0.6.0_0 ---> Activating hs-cabal @0.6.0_0 ---> Cleaning hs-cabal ---> Fetching hs-Crypto ---> Attempting to fetch Crypto-4.1.0.tar.gz from http://trd.no.distfiles.macports.org/hs-Crypto ---> Verifying checksum(s) for hs-Crypto ---> Extracting hs-Crypto ---> Configuring hs-Crypto ---> Building hs-Crypto Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports .org_release_ports_devel_hs-Crypto/work/Crypto-4.1.0 && runhaskell Setup build -v" returned error 1 Command output: In the instance declaration for `Integral (LargeKey a b)' Data/LargeWord.hs:137:9: Warning: No explicit method nor default method for `toRational' In the instance declaration for `Real (LargeKey a b)' Data/LargeWord.hs:140:9: Warning: No explicit method nor default method for `toEnum' In the instance declaration for `Enum (LargeKey a b)' Data/LargeWord.hs:140:9: Warning: No explicit method nor default method for `fromEnum' In the instance declaration for `Enum (LargeKey a b)' [10 of 11] Compiling Codec.Encryption.AES ( Codec/Encryption/AES.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Codec/Encryption/AES.o ) [11 of 11] Compiling Main ( SymmetricTest.hs, dist/build/SymmetricTest/SymmetricTest-tmp/Main.o ) Linking dist/build/SymmetricTest/SymmetricTest ... Building executable: SHA1Test... Creating dist/build/SHA1Test (and its parents) Creating dist/build/SHA1Test/SHA1Test-tmp (and its parents) /opt/local/bin/ghc -o dist/build/SHA1Test/SHA1Test --make -hide-all- packages -no-user-package-conf -i -idist/build/SHA1Test/SHA1Test-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/SHA1Test/SHA1Test- tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/SHA1Test/SHA1Test-tmp -hidir dist/build/SHA1Test/SHA1Test-tmp -stubdir dist/build/SHA1Test/SHA1Test-tmp -package HUnit-1.2.0.3 -package QuickCheck-1.2.0.0 -package array-0.2.0.0 -package base-4.0.0.0 -package pretty-1.0.1.0 -package random-1.0.0.1 -O ./SHA1Test.hs [1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test /SHA1Test-tmp/Codec/Utils.o ) [2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o ) [3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o ) [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test /SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Error: Status 1 encountered during processing. [ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 14:33:19 2009 From: trac at galois.com (GHC) Date: Sat May 23 14:17:48 2009 Subject: [GHC] #3249: Unable to install Ghc packages by MacPorts In-Reply-To: <044.dc0b6710a1fe4a87afffd49eca65e4ab@localhost> References: <044.dc0b6710a1fe4a87afffd49eca65e4ab@localhost> Message-ID: <053.299c9f313346c0482bc4b611ea68a958@localhost> #3249: Unable to install Ghc packages by MacPorts -------------------------------+-------------------------------------------- Reporter: soopo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 6.10.1 Severity: minor | Resolution: duplicate Keywords: mac, macports | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This is a duplicate of #2753, and will be fixed as part of #2790. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 15:32:49 2009 From: trac at galois.com (GHC) Date: Sat May 23 15:17:36 2009 Subject: [GHC] #3137: ghc 6.10.2 fails to compile on Mac OS X Leopard In-Reply-To: <046.6f633fd5a4e98213439c39f0a29d0f1a@localhost> References: <046.6f633fd5a4e98213439c39f0a29d0f1a@localhost> Message-ID: <055.6f9cc214424897dc5dd7448e13cd4518@localhost> #3137: ghc 6.10.2 fails to compile on Mac OS X Leopard ---------------------------------+------------------------------------------ Reporter: mvanier | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 15:36:05 2009 From: trac at galois.com (GHC) Date: Sat May 23 15:20:34 2009 Subject: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad In-Reply-To: <046.ecd79a44a24e66ebe8454442595b165e@localhost> References: <046.ecd79a44a24e66ebe8454442595b165e@localhost> Message-ID: <055.07ee52612e269049ed33e3b071389c17@localhost> #3138: Returning a known constructor: GHC generates terrible code for cmonad -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 15:44:10 2009 From: trac at galois.com (GHC) Date: Sat May 23 15:28:39 2009 Subject: [GHC] #3140: (Windows?) GHCi doesn't load hierachical modules In-Reply-To: <044.2eb3a00ae65a21d331fc8637974706c7@localhost> References: <044.2eb3a00ae65a21d331fc8637974706c7@localhost> Message-ID: <053.1bf4f8b9bdd14f3583ed86b17dd6e818@localhost> #3140: (Windows?) GHCi doesn't load hierachical modules -----------------------+---------------------------------------------------- Reporter: Orphi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > On Windows, if you double-click a `*.hs` file, GHCi starts up and loads > the corresponding module. Usually this works fine, however... it seems to > trip over on hierachical module names. Specifically: > > * Create file `Foo\Bar.hs` containing a module `Foo.Bar` that imports > `Foo.Baz`. > * Create file `Foo\Baz.hs` containing a module `Foo.Baz`. > * Double-click on `Foo\Bar.hs`; GHCi whines that it can't find `Foo.Baz` > in the search path. > > This happens regardless of whether either of the modules is compiled or > not. An easy work-around is to invoke GHCi from the command prompt with > the CWD below the `Foo` folder. But it's kind of tedious to have to do > that. > > Note that if `Foo.Bar` doesn't import anything (or only modules from > packages) then it works just fine. GHCi just doesn't seem to be able to > find source files in the current folder if they have hierachical names. New description: On Windows, if you double-click a `*.hs` file, GHCi starts up and loads the corresponding module. Usually this works fine, however... it seems to trip over on hierachical module names. Specifically: * Create file `Foo\Bar.hs` containing a module `Foo.Bar` that imports `Foo.Baz`. * Create file `Foo\Baz.hs` containing a module `Foo.Baz`. * Double-click on `Foo\Bar.hs`; GHCi whines that it can't find `Foo.Baz` in the search path. This happens regardless of whether either of the modules is compiled or not. An easy work-around is to invoke GHCi from the command prompt with the CWD below the `Foo` folder. But it's kind of tedious to have to do that. Note that if `Foo.Bar` doesn't import anything (or only modules from packages) then it works just fine. GHCi just doesn't seem to be able to find source files in the current folder if they have hierachical names. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 15:44:56 2009 From: trac at galois.com (GHC) Date: Sat May 23 15:29:25 2009 Subject: [GHC] #3140: (Windows?) GHCi doesn't load hierachical modules In-Reply-To: <044.2eb3a00ae65a21d331fc8637974706c7@localhost> References: <044.2eb3a00ae65a21d331fc8637974706c7@localhost> Message-ID: <053.a4af9a4184919fc0afccc41026090e80@localhost> #3140: (Windows?) GHCi doesn't load hierachical modules --------------------------------+------------------------------------------- Reporter: Orphi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | --------------------------------+------------------------------------------- Changes (by igloo): * type: bug => feature request * milestone: => 6.12 branch Comment: Thanks for the suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 15:53:58 2009 From: trac at galois.com (GHC) Date: Sat May 23 15:38:28 2009 Subject: [GHC] #3141: directory-1.0.0.3 needs base == 4.* in .cabal file. In-Reply-To: <044.bc080c0fa89ce0447b3f3aa55ae6717a@localhost> References: <044.bc080c0fa89ce0447b3f3aa55ae6717a@localhost> Message-ID: <053.c69a84303d70ed1f6c60387ae8c1dbb0@localhost> #3141: directory-1.0.0.3 needs base == 4.* in .cabal file. ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: I'm afraid we don't support using bootlibs with older versions of GHC, sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 15:57:38 2009 From: trac at galois.com (GHC) Date: Sat May 23 15:42:09 2009 Subject: [GHC] #3156: Error on +RTS kHugeNumber In-Reply-To: <044.bcb7c7bbf404d4091f28f0c21eab873f@localhost> References: <044.bcb7c7bbf404d4091f28f0c21eab873f@localhost> Message-ID: <053.22d7a4d1ad6d1ba13fae4d043a0e82da@localhost> #3156: Error on +RTS kHugeNumber -------------------------------------+-------------------------------------- Reporter: zachk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: minor | Resolution: Keywords: 6.10.1||6.10.2 Stack | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > It is in either 6.10.2 or 6.10.1 I forget which > ./p 1 -> works > ./p 2 -> works > ./p 3 -> error > ./p 4 -> error > > p is a shell script > I am passing a huge number in for stack size, ghc did say report it, so I > am. > > ghc -O3 --make poly > > FILES ARE ATTACHED:: New description: It is in either 6.10.2 or 6.10.1 I forget which {{{ ./p 1 -> works ./p 2 -> works ./p 3 -> error ./p 4 -> error }}} p is a shell script I am passing a huge number in for stack size, ghc did say report it, so I am. ghc -O3 --make poly FILES ARE ATTACHED:: -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 16:11:46 2009 From: trac at galois.com (GHC) Date: Sat May 23 15:56:15 2009 Subject: [GHC] #3161: non-blocking read operations in Chan, Sem, QSem, SampleVar In-Reply-To: <053.85efed2401b79008b99b978e2ea1b3fc@localhost> References: <053.85efed2401b79008b99b978e2ea1b3fc@localhost> Message-ID: <062.eb6199a6a8a0be2958405a4622acf86e@localhost> #3161: non-blocking read operations in Chan, Sem, QSem, SampleVar ---------------------------------+------------------------------------------ Reporter: ChrisKuklewicz | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 16:12:53 2009 From: trac at galois.com (GHC) Date: Sat May 23 15:57:21 2009 Subject: [GHC] #3163: GADTs should not allow polymorphism in return type In-Reply-To: <051.9e183310fa287b7470565c1ecdf33535@localhost> References: <051.9e183310fa287b7470565c1ecdf33535@localhost> Message-ID: <060.9f5dd182d8cd3d4d5043534ea35e3d54@localhost> #3163: GADTs should not allow polymorphism in return type ----------------------------------------+----------------------------------- Reporter: Scott Turner | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 16:10:57 2009 From: trac at galois.com (GHC) Date: Sat May 23 15:58:33 2009 Subject: [GHC] #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar In-Reply-To: <053.70a1854543dd01f0108efd70a01e67de@localhost> References: <053.70a1854543dd01f0108efd70a01e67de@localhost> Message-ID: <062.030946b03b03f855ccbe351ed8640e19@localhost> #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar ---------------------------------+------------------------------------------ Reporter: ChrisKuklewicz | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 16:14:35 2009 From: trac at galois.com (GHC) Date: Sat May 23 15:59:04 2009 Subject: [GHC] #3164: ghc: panic! (the 'impossible' happened) while building pandoc on a macbook In-Reply-To: <047.8f4ef7af6b65a5b6ceb9ebc515772ad1@localhost> References: <047.8f4ef7af6b65a5b6ceb9ebc515772ad1@localhost> Message-ID: <056.58bd04b8ff9520afda4590670317f2b6@localhost> #3164: ghc: panic! (the 'impossible' happened) while building pandoc on a macbook ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Old description: > ~/src/pandoc$ ghci -isrc src/pandoc.hs > GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help > ... > Loading package digest-0.0.0.5 ... linking ... done. > Loading package zip-archive-0.1.1.3 ... linking ... done. > [ 8 of 29] Compiling Text.Pandoc.LaTeXMathML ( > src/Text/Pandoc/LaTeXMathML.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.2 for i386-apple-darwin): > linkBCO: >= 64k insns in BCO > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > New description: {{{ ~/src/pandoc$ ghci -isrc src/pandoc.hs GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help ... Loading package digest-0.0.0.5 ... linking ... done. Loading package zip-archive-0.1.1.3 ... linking ... done. [ 8 of 29] Compiling Text.Pandoc.LaTeXMathML ( src/Text/Pandoc/LaTeXMathML.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.2 for i386-apple-darwin): linkBCO: >= 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 16:19:37 2009 From: trac at galois.com (GHC) Date: Sat May 23 16:04:07 2009 Subject: [GHC] #3165: :history throws "Irrefutable pattern failed" exception In-Reply-To: <046.98732e4c9934d7000eb5550f93cd4a26@localhost> References: <046.98732e4c9934d7000eb5550f93cd4a26@localhost> Message-ID: <055.e1b9e1d455baba8c7a9d5f11baf549eb@localhost> #3165: :history throws "Irrefutable pattern failed" exception ------------------------+--------------------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------+--------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 16:21:27 2009 From: trac at galois.com (GHC) Date: Sat May 23 16:05:57 2009 Subject: [GHC] #3164: ghc: panic! (the 'impossible' happened) while building pandoc on a macbook In-Reply-To: <047.8f4ef7af6b65a5b6ceb9ebc515772ad1@localhost> References: <047.8f4ef7af6b65a5b6ceb9ebc515772ad1@localhost> Message-ID: <056.1c7e1b5fd17ca744f20a152ff8f6f2f1@localhost> #3164: ghc: panic! (the 'impossible' happened) while building pandoc on a macbook ---------------------------------+------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: Closing this as a duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 16:29:29 2009 From: trac at galois.com (GHC) Date: Sat May 23 16:14:01 2009 Subject: [GHC] #3159: QSem fails with negative quantities In-Reply-To: <051.bc01acc1b08688c0c5eca9a74350c075@localhost> References: <051.bc01acc1b08688c0c5eca9a74350c075@localhost> Message-ID: <060.04f85264991216b0c2918e321e009c8e@localhost> #3159: QSem fails with negative quantities ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.10.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: I've documented the 0 minimum quantity. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 16:38:26 2009 From: trac at galois.com (GHC) Date: Sat May 23 16:22:55 2009 Subject: [GHC] #3197: disambiguating type family instances with qualified names not possible In-Reply-To: <044.4e0198f3effcd8f1d87eec80ef8d0a9e@localhost> References: <044.4e0198f3effcd8f1d87eec80ef8d0a9e@localhost> Message-ID: <053.bd9c22772e779ba8f4312fd049b4ebe9@localhost> #3197: disambiguating type family instances with qualified names not possible ----------------------------------------+----------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 16:39:50 2009 From: trac at galois.com (GHC) Date: Sat May 23 16:24:19 2009 Subject: [GHC] #3196: libHSffi_p.a should not be created when profiled libs are disabled In-Reply-To: <050.da94d4ed5f69888e6c5b90827b1c849d@localhost> References: <050.da94d4ed5f69888e6c5b90827b1c849d@localhost> Message-ID: <059.94573438173f926ac4d09fb6b672cd68@localhost> #3196: libHSffi_p.a should not be created when profiled libs are disabled ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the patch; however, this is handled differently in the new build system, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 16:40:37 2009 From: trac at galois.com (GHC) Date: Sat May 23 16:25:08 2009 Subject: [GHC] #3193: line number for GADT type error is very inaccurate In-Reply-To: <041.70394cb40bad7490a7814d559b0c8397@localhost> References: <041.70394cb40bad7490a7814d559b0c8397@localhost> Message-ID: <050.8348c92ea089aa9418c74248adfd85b0@localhost> #3193: line number for GADT type error is very inaccurate -------------------------+-------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: GADTs | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 16:41:49 2009 From: trac at galois.com (GHC) Date: Sat May 23 16:26:19 2009 Subject: [GHC] #3174: decodeFloat (0.0/0.0) = undefined In-Reply-To: <047.c5b67ad8f72a278cd5c15b987f7f1fb5@localhost> References: <047.c5b67ad8f72a278cd5c15b987f7f1fb5@localhost> Message-ID: <056.f7846b35f6725709b6f34fff03e52159@localhost> #3174: decodeFloat (0.0/0.0) = undefined ---------------------------------+------------------------------------------ Reporter: crutcher | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 18:51:38 2009 From: trac at galois.com (GHC) Date: Sat May 23 18:36:07 2009 Subject: [GHC] #3141: directory-1.0.0.3 needs base == 4.* in .cabal file. In-Reply-To: <044.bc080c0fa89ce0447b3f3aa55ae6717a@localhost> References: <044.bc080c0fa89ce0447b3f3aa55ae6717a@localhost> Message-ID: <053.a5cea7b148d22aa54401ecc06a4cd702@localhost> #3141: directory-1.0.0.3 needs base == 4.* in .cabal file. ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by duncan): * status: closed => reopened * resolution: invalid => Comment: Replying to [comment:1 igloo]: > I'm afraid we don't support using bootlibs with older versions of GHC, sorry. That's exactly why the .cabal files should specify the right constraints on the version of base. We do upload the core libs to hackage, so they should have the right constraints. The .cabal file for directory-1.0.0.3 and indeed for the current darcs version still only say `build-depends: base` when they should probably say `build-depends: base >= 4 && < 4.2`. At some point I'm going to make hackage reject packages that do not specify and lower and maybe even upper bound on the version of base. The core libs should be setting the right example. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 18:58:30 2009 From: trac at galois.com (GHC) Date: Sat May 23 18:43:00 2009 Subject: [GHC] #3141: directory-1.0.0.3 needs base == 4.* in .cabal file. In-Reply-To: <044.bc080c0fa89ce0447b3f3aa55ae6717a@localhost> References: <044.bc080c0fa89ce0447b3f3aa55ae6717a@localhost> Message-ID: <053.13ec10a5b3ee8e4f2f676c2f0653d01b@localhost> #3141: directory-1.0.0.3 needs base == 4.* in .cabal file. ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * milestone: => 6.12.1 Comment: Ah, yes, you are right. I read the bug as being about directory not working with older versions of GHC, rather than about it not declaring that it doesn't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 23 21:18:33 2009 From: trac at galois.com (GHC) Date: Sat May 23 21:03:01 2009 Subject: [GHC] #3250: can't build ghc-6.11: "Failed to load interface for `GHC'" In-Reply-To: <050.2f9fde01f035f222ff003b67944178a9@localhost> References: <050.2f9fde01f035f222ff003b67944178a9@localhost> Message-ID: <059.9d26cad4fa05f3cf5a9bef4a14b709d6@localhost> #3250: can't build ghc-6.11: "Failed to load interface for `GHC'" --------------------------+------------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by juhpetersen): Also tried with ghc-6.10.3 and just ./configure ; make and got the same result. Are the nightly builds off the nightly src tarball now? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 01:09:12 2009 From: trac at galois.com (GHC) Date: Sun May 24 00:53:54 2009 Subject: [GHC] #3257: System.Exit.exitWith exits current thread, not program Message-ID: <050.495fc286d66dcfea7ccac05a6bd8fa06@localhost> #3257: System.Exit.exitWith exits current thread, not program -----------------------------+---------------------------------------------- Reporter: Bart Massey | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The documentation for System.Exit is a bit ambiguous about what the exitWith function exits from, but IMHO the most natural inference is that it exits the process from within which it is called. However, it currently does not necessarily do so; if called from a forkIO'ed thread, it will raise the exit exception in that thread rather than the "main thread" of the process. IMHO it would be best to change this behavior, but failing that it ought to at least be better documented. For now, I am manually throwing an !ExitCode to the main thread as a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 02:38:39 2009 From: trac at galois.com (GHC) Date: Sun May 24 02:23:07 2009 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@localhost> References: <045.426dc6319f98492c5b511466045bc0b5@localhost> Message-ID: <054.b9ad6699721065569f37579546a92f2a@localhost> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) -----------------------+---------------------------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Comment (by jeffz1): Ah, if it's a bug in hipmunk, do you have any idea of the correct approach? I tried modifying Hipmunk's .cabal to instead be: if !os(windows) { Extra-Libraries: m } cabal configure, cabal build, cabal install in ghci, if I try initChipmunk again, I get: Loading package syb ... linking ... : C:\Program Files\Haskell\Hipm unk-0.2.2\ghc-6.10.2\HSHipmunk-0.2.2.o: unknown symbol `_fmodf' : unable to load package `syb' So I guess that isn't correct either. GHC works fine with m or without m, it's just ghci that has the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 06:49:40 2009 From: trac at galois.com (GHC) Date: Sun May 24 06:34:09 2009 Subject: [GHC] #3250: can't build ghc-6.11: "Failed to load interface for `GHC'" In-Reply-To: <050.2f9fde01f035f222ff003b67944178a9@localhost> References: <050.2f9fde01f035f222ff003b67944178a9@localhost> Message-ID: <059.d5d3230f502ba3e364ab466e86e47ccc@localhost> #3250: can't build ghc-6.11: "Failed to load interface for `GHC'" ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > I was trying to build ghc-6.11.20090520 on Fedora 10 x86_64 with > ghc-6.10.2 and got to: > > utils/runghc/ghc.mk:26: utils/runghc/dist/build/.depend: No such file or > directory > ghc/ghc.mk:95: ghc/stage2/build/.depend: No such file or directory > /usr/bin/ghc -H32m -O -package-conf libraries/bootstrapping.conf -i > -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen -Ighc/stage1/build > -Ighc/stage1/build/autogen -package ghc-6.11 -XCPP -XPatternGuards > -XForeignFunctionInterface -XUnboxedTuples -XFlexibleInstances > -XMagicHash -fforce-recomp -optc-O0 -odir ghc/stage1/build -hidir > ghc/stage1/build -stubdir ghc/stage1/build -hisuf hi -osuf o -hcsuf hc > -c ghc/./Main.hs -o ghc/stage1/build/Main.o > > ghc/Main.hs:14:0: > Failed to load interface for `GHC': > There are files missing in the `ghc-6.11' package, > try running 'ghc-pkg check'. > Use -v to see a list of the files searched for. > make[2]: *** [ghc/stage1/build/Main.o] Error 1 > make[1]: *** [all] Error 2 New description: I was trying to build ghc-6.11.20090520 on Fedora 10 x86_64 with ghc-6.10.2 and got to: {{{ utils/runghc/ghc.mk:26: utils/runghc/dist/build/.depend: No such file or directory ghc/ghc.mk:95: ghc/stage2/build/.depend: No such file or directory /usr/bin/ghc -H32m -O -package-conf libraries/bootstrapping.conf -i -ighc/. -ighc/stage1/build -ighc/stage1/build/autogen -Ighc/stage1/build -Ighc/stage1/build/autogen -package ghc-6.11 -XCPP -XPatternGuards -XForeignFunctionInterface -XUnboxedTuples -XFlexibleInstances -XMagicHash -fforce-recomp -optc-O0 -odir ghc/stage1/build -hidir ghc/stage1/build -stubdir ghc/stage1/build -hisuf hi -osuf o -hcsuf hc -c ghc/./Main.hs -o ghc/stage1/build/Main.o ghc/Main.hs:14:0: Failed to load interface for `GHC': There are files missing in the `ghc-6.11' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. make[2]: *** [ghc/stage1/build/Main.o] Error 1 make[1]: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 07:13:26 2009 From: trac at galois.com (GHC) Date: Sun May 24 06:57:54 2009 Subject: [GHC] #3250: can't build ghc-6.11: "Failed to load interface for `GHC'" In-Reply-To: <050.2f9fde01f035f222ff003b67944178a9@localhost> References: <050.2f9fde01f035f222ff003b67944178a9@localhost> Message-ID: <059.7500a4905869639a8b33ead8fb1d3656@localhost> #3250: can't build ghc-6.11: "Failed to load interface for `GHC'" ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo Comment: Thanks for the report; I can reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 10:01:12 2009 From: trac at galois.com (GHC) Date: Sun May 24 09:45:41 2009 Subject: [GHC] #3250: can't build ghc-6.11: "Failed to load interface for `GHC'" In-Reply-To: <050.2f9fde01f035f222ff003b67944178a9@localhost> References: <050.2f9fde01f035f222ff003b67944178a9@localhost> Message-ID: <059.aed305783f5fb9bc92b787b642ae7ec7@localhost> #3250: can't build ghc-6.11: "Failed to load interface for `GHC'" ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Replying to [comment:3 juhpetersen]: > Are the nightly builds off the nightly src tarball now? The nightly builds always get the sources from the darcs repos. The source tarball is generated by one of the nightly builders. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 11:18:10 2009 From: trac at galois.com (GHC) Date: Sun May 24 11:02:37 2009 Subject: [GHC] #3139: automate "cabal check" in ghc release process In-Reply-To: <045.7ab42017b14002b12bbbb131a40f00d6@localhost> References: <045.7ab42017b14002b12bbbb131a40f00d6@localhost> Message-ID: <054.cf4059713a11dfb13ba258bf5930e69d@localhost> #3139: automate "cabal check" in ghc release process ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 11:18:10 2009 From: trac at galois.com (GHC) Date: Sun May 24 11:02:40 2009 Subject: [GHC] #3142: unix-2.3.2.0 needs base >= 4.1 in .cabal file In-Reply-To: <044.f13b6bf3093c6ed979ae5427358e84fe@localhost> References: <044.f13b6bf3093c6ed979ae5427358e84fe@localhost> Message-ID: <053.83ee831113e886ff2b6a0cc7ff29a834@localhost> #3142: unix-2.3.2.0 needs base >= 4.1 in .cabal file ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/unix | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 11:18:47 2009 From: trac at galois.com (GHC) Date: Sun May 24 11:03:16 2009 Subject: [GHC] #3156: Error on +RTS kHugeNumber In-Reply-To: <044.bcb7c7bbf404d4091f28f0c21eab873f@localhost> References: <044.bcb7c7bbf404d4091f28f0c21eab873f@localhost> Message-ID: <053.6e6d8175b575c5e50578c48a5ebe2b02@localhost> #3156: Error on +RTS kHugeNumber -------------------------------------+-------------------------------------- Reporter: zachk | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: minor | Resolution: Keywords: 6.10.1||6.10.2 Stack | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------------+-------------------------------------- Changes (by igloo): * milestone: => 6.12.1 Comment: Thanks for the report, we'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 11:38:37 2009 From: trac at galois.com (GHC) Date: Sun May 24 11:23:05 2009 Subject: [GHC] #3250: can't build ghc-6.11: "Failed to load interface for `GHC'" In-Reply-To: <050.2f9fde01f035f222ff003b67944178a9@localhost> References: <050.2f9fde01f035f222ff003b67944178a9@localhost> Message-ID: <059.97255c8d8d66e9c4b4a5bb1662ee40b3@localhost> #3250: can't build ghc-6.11: "Failed to load interface for `GHC'" ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Sun May 24 14:34:39 BST 2009 Ian Lynagh * Be more precise about munging compiler/stage1/inplace-pkg-config We were removing ".$(ProjectPatchLevel)" from anywhere in the file. However, it included absolute paths, so if you untar a source tarball into its default directory name, e.g. "6.11.$(ProjectPatchLevel)", then the sed would break the paths. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 12:10:17 2009 From: trac at galois.com (GHC) Date: Sun May 24 11:54:45 2009 Subject: [GHC] #3189: Exception in canonicalizePath if path has national symbols In-Reply-To: <044.a27e70374e3931f7c0e96425b2a1dbab@localhost> References: <044.a27e70374e3931f7c0e96425b2a1dbab@localhost> Message-ID: <053.4da070bb11e42f0c9a1f08e1d01b2a0b@localhost> #3189: Exception in canonicalizePath if path has national symbols ------------------------------------+--------------------------------------- Reporter: Tonal | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 12:12:55 2009 From: trac at galois.com (GHC) Date: Sun May 24 11:57:21 2009 Subject: [GHC] #3188: instance Random for Data.Word In-Reply-To: <043.22ba6b7be1ff054d66166cbedb3accb5@localhost> References: <043.22ba6b7be1ff054d66166cbedb3accb5@localhost> Message-ID: <052.3573c6998348736e89a78e3036945655@localhost> #3188: instance Random for Data.Word ---------------------------------+------------------------------------------ Reporter: uznx | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Thanks for the suggestion, Can you please make library submission for this?: http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 12:14:20 2009 From: trac at galois.com (GHC) Date: Sun May 24 11:58:50 2009 Subject: [GHC] #3186: findExeutable does not respect order of search path on Windows In-Reply-To: <045.8d432c25f775875a5ebadcd8663d4571@localhost> References: <045.8d432c25f775875a5ebadcd8663d4571@localhost> Message-ID: <054.cad929e36e54066ee9f66349e81ddf1b@localhost> #3186: findExeutable does not respect order of search path on Windows ------------------------------------+--------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 12:15:05 2009 From: trac at galois.com (GHC) Date: Sun May 24 11:59:38 2009 Subject: [GHC] #3256: Extra EOT from NoBuffering mode in emacs In-Reply-To: <044.f071539e68c72dff76745c9af1d974f7@localhost> References: <044.f071539e68c72dff76745c9af1d974f7@localhost> Message-ID: <053.642eebb62b24397555aa1042b40555d4@localhost> #3256: Extra EOT from NoBuffering mode in emacs ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by nad): * cc: nad (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 12:23:50 2009 From: trac at galois.com (GHC) Date: Sun May 24 12:08:17 2009 Subject: [GHC] #3181: Regression in unboxing In-Reply-To: <044.12b8af7c7e17bf83c854d3057fcb12c2@localhost> References: <044.12b8af7c7e17bf83c854d3057fcb12c2@localhost> Message-ID: <053.429fb23494124aee0fe855e614e55829@localhost> #3181: Regression in unboxing -----------------------------------------+---------------------------------- Reporter: dolio | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: unboxing boxing | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 12:24:20 2009 From: trac at galois.com (GHC) Date: Sun May 24 12:08:47 2009 Subject: [GHC] #3181: Regression in unboxing In-Reply-To: <044.12b8af7c7e17bf83c854d3057fcb12c2@localhost> References: <044.12b8af7c7e17bf83c854d3057fcb12c2@localhost> Message-ID: <053.57f9ff87a9b7788b227fb355357587c8@localhost> #3181: Regression in unboxing -----------------------------------------+---------------------------------- Reporter: dolio | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: unboxing boxing | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -----------------------------------------+---------------------------------- Comment (by igloo): Thanks for all your work in boiling down the testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 12:35:00 2009 From: trac at galois.com (GHC) Date: Sun May 24 12:19:38 2009 Subject: [GHC] #3179: Linking unix package fails In-Reply-To: <044.ae8162f5a98c9f4e805028c0bd796c43@localhost> References: <044.ae8162f5a98c9f4e805028c0bd796c43@localhost> Message-ID: <053.2247ff35957bc065c4afe491fc639026@localhost> #3179: Linking unix package fails -------------------------------+-------------------------------------------- Reporter: eelco | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/unix | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 Comment: If anyone has a standalone testcase for this bug, then that would be handy. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 12:45:35 2009 From: trac at galois.com (GHC) Date: Sun May 24 12:30:02 2009 Subject: [GHC] #3141: directory-1.0.0.3 needs base == 4.* in .cabal file. In-Reply-To: <044.bc080c0fa89ce0447b3f3aa55ae6717a@localhost> References: <044.bc080c0fa89ce0447b3f3aa55ae6717a@localhost> Message-ID: <053.ffc7907e5307d4e554c8b8a039b0bb14@localhost> #3141: directory-1.0.0.3 needs base == 4.* in .cabal file. ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: Fixed: {{{ Sun May 24 16:59:51 BST 2009 Ian Lynagh * Give bounds for the dependencies; fixes #3141 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 12:46:30 2009 From: trac at galois.com (GHC) Date: Sun May 24 12:30:59 2009 Subject: [GHC] #3172: syb-0.1.0.1 doesn't require base >= 4 in its .cabal file In-Reply-To: <045.f6c3e150264718800338197e5aa419e6@localhost> References: <045.f6c3e150264718800338197e5aa419e6@localhost> Message-ID: <054.5f752b0979045eaa2354b382f63bcee0@localhost> #3172: syb-0.1.0.1 doesn't require base >= 4 in its .cabal file ----------------------------------+----------------------------------------- Reporter: Saizan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: Severity: normal | Resolution: fixed Keywords: syb cabal | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Fixed: {{{ Sun May 24 16:57:12 BST 2009 Ian Lynagh * Give bounds for the base dependency; fixes #3172 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 12:47:58 2009 From: trac at galois.com (GHC) Date: Sun May 24 12:32:26 2009 Subject: [GHC] #3142: unix-2.3.2.0 needs base >= 4.1 in .cabal file In-Reply-To: <044.f13b6bf3093c6ed979ae5427358e84fe@localhost> References: <044.f13b6bf3093c6ed979ae5427358e84fe@localhost> Message-ID: <053.c1c389833cbb8d750409347a868fad69@localhost> #3142: unix-2.3.2.0 needs base >= 4.1 in .cabal file ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/unix | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Sun May 24 16:55:04 BST 2009 Ian Lynagh * Give bounds for the base dependency; fixes #3142 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 12:58:46 2009 From: trac at galois.com (GHC) Date: Sun May 24 12:43:13 2009 Subject: [GHC] #3177: support quasiquoting for types In-Reply-To: <044.c3a64b2980f70bac4463359d5d880ce5@localhost> References: <044.c3a64b2980f70bac4463359d5d880ce5@localhost> Message-ID: <053.8c3579eab3ec6a7126e1dca95a29ab5b@localhost> #3177: support quasiquoting for types ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Quasi quotes as in the QuasiQuotes extension, not TemplateHaskell (which already has them), I assume. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 13:43:52 2009 From: trac at galois.com (GHC) Date: Sun May 24 13:28:21 2009 Subject: [GHC] #3177: support quasiquoting for types In-Reply-To: <044.c3a64b2980f70bac4463359d5d880ce5@localhost> References: <044.c3a64b2980f70bac4463359d5d880ce5@localhost> Message-ID: <053.6b8235e9006f3a976af5633514eb6823@localhost> #3177: support quasiquoting for types ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by claus): Replying to [comment:1 igloo]: > Quasi quotes as in the QuasiQuotes extension, Yes. The example uses TH-generation of type synonyms as a (partial) workaround - what is needed instead is the ability to say things like {{{ instance HasField () label [$l| TFalse |] label = [$l| myLabel |] :: [$l| myLabel |] }}} > not TemplateHaskell (which already has them), I assume. Whatever makes you think so? See the related ticket I linked to (reported by someone you might know?-). The [http://www.haskell.org/ghc/docs/latest/html/users_guide/template- haskell.html TH documentation] is rather confusing there, as 7.9.1 first describes the syntax for type quotations, and only later states that type splices aren't implemented.. (unless #1476 has been fixed without closing, the documentation should probably point to it) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 13:59:48 2009 From: trac at galois.com (GHC) Date: Sun May 24 13:44:14 2009 Subject: [GHC] #3258: a.out file in ghc 6.10.3 package, under libraries/haskeline Message-ID: <044.97bedf0d77daf2eb39ae59f26c7d9cec@localhost> #3258: a.out file in ghc 6.10.3 package, under libraries/haskeline -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.3 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Summary says it all, it seems to have snuck in there; maybe there's some cleaning step missing in the packaging step (make dist?). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:01:30 2009 From: trac at galois.com (GHC) Date: Sun May 24 13:46:01 2009 Subject: [GHC] #3202: Make XNoMonomorphismRestriction the default in GHCi In-Reply-To: <047.d2e31e41b925b8804676d46611405d7d@localhost> References: <047.d2e31e41b925b8804676d46611405d7d@localhost> Message-ID: <056.bd26875a0e3e574d995e8d5630a33140@localhost> #3202: Make XNoMonomorphismRestriction the default in GHCi ---------------------------------+------------------------------------------ Reporter: YitzGale | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:02:32 2009 From: trac at galois.com (GHC) Date: Sun May 24 13:46:58 2009 Subject: [GHC] #3200: System.Environment.withProgName strips everything before the last slash In-Reply-To: <044.6c7a0324fd6d877811b6a46ca881b0e2@localhost> References: <044.6c7a0324fd6d877811b6a46ca881b0e2@localhost> Message-ID: <053.c18c3f26f7ef8990604b05a90f2f1f6a@localhost> #3200: System.Environment.withProgName strips everything before the last slash ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:02:50 2009 From: trac at galois.com (GHC) Date: Sun May 24 13:47:18 2009 Subject: [GHC] #3199: System.Environment provides no access to argv[0] In-Reply-To: <044.697a3b3acea49077d005dd1587a2b57f@localhost> References: <044.697a3b3acea49077d005dd1587a2b57f@localhost> Message-ID: <053.105769b19a749642c0f5c39d7a85ac85@localhost> #3199: System.Environment provides no access to argv[0] ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:03:04 2009 From: trac at galois.com (GHC) Date: Sun May 24 13:47:30 2009 Subject: [GHC] #3192: Add dynCompileCoreExpr :: GhcMonad m => Bool -> Expr CoreBind -> m Dynamic to ghc-api In-Reply-To: <044.47e968a3a4e753b9c69df3c413672bea@localhost> References: <044.47e968a3a4e753b9c69df3c413672bea@localhost> Message-ID: <053.2f1669ef813afdbf05fc49e9e973c890@localhost> #3192: Add dynCompileCoreExpr :: GhcMonad m => Bool -> Expr CoreBind -> m Dynamic to ghc-api ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHC API | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:09:35 2009 From: trac at galois.com (GHC) Date: Sun May 24 13:54:00 2009 Subject: [GHC] #3177: support quasiquoting for types In-Reply-To: <044.c3a64b2980f70bac4463359d5d880ce5@localhost> References: <044.c3a64b2980f70bac4463359d5d880ce5@localhost> Message-ID: <053.737aba2d55fbb85089865785ee7932b7@localhost> #3177: support quasiquoting for types ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Right, with TH you can quasi-quote types (e.g. `[t| Int |]`), but can't splice them in. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:34:14 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:18:43 2009 Subject: [GHC] #2991: .mix files generation broken with -fhpc and --make flags with lhs modules In-Reply-To: <045.fbdf830be4083dc434ba708ecd719a55@localhost> References: <045.fbdf830be4083dc434ba708ecd719a55@localhost> Message-ID: <054.94f687742f134afa495505f093b0c871@localhost> #2991: .mix files generation broken with -fhpc and --make flags with lhs modules ---------------------------------+------------------------------------------ Reporter: ppavel | Owner: andy@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Code Coverage | Version: 6.10.1 Severity: normal | Resolution: Keywords: hpc make lhs | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => andy@galois.com * component: Compiler => Code Coverage Comment: See also #3191. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:34:22 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:18:50 2009 Subject: [GHC] #3191: hpc reports spurious results with .lhs files even after processing with ghc -E In-Reply-To: <046.d0fa4dbe587b61661696f46161cde9aa@localhost> References: <046.d0fa4dbe587b61661696f46161cde9aa@localhost> Message-ID: <055.99477d207f11b3db6f62ed0fca5a1a7b@localhost> #3191: hpc reports spurious results with .lhs files even after processing with ghc -E ---------------------------------+------------------------------------------ Reporter: dominic | Owner: andy@galois.com Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Comment: See also #2991. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:34:47 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:19:14 2009 Subject: [GHC] #3191: hpc reports spurious results with .lhs files even after processing with ghc -E In-Reply-To: <046.d0fa4dbe587b61661696f46161cde9aa@localhost> References: <046.d0fa4dbe587b61661696f46161cde9aa@localhost> Message-ID: <055.ba3593bf631d6645a4114664625c14a8@localhost> #3191: hpc reports spurious results with .lhs files even after processing with ghc -E ---------------------------------+------------------------------------------ Reporter: dominic | Owner: andy@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Code Coverage | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:41:41 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:26:23 2009 Subject: [GHC] #2442: Heuristics to improve error messages for badly referenced things In-Reply-To: <053.d96b74737451be892238b37815ca44b6@localhost> References: <053.d96b74737451be892238b37815ca44b6@localhost> Message-ID: <062.3f37367919c39467c1cee44dca5936cb@localhost> #2442: Heuristics to improve error messages for badly referenced things ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): See also #3209. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:42:17 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:26:43 2009 Subject: [GHC] #3209: Use Levenshtein distance for unknown identifier errors In-Reply-To: <042.94b65b91b3aa47b37e02df15d7189236@localhost> References: <042.94b65b91b3aa47b37e02df15d7189236@localhost> Message-ID: <051.0eee7e283a19b8263fb1d2edac62767a@localhost> #3209: Use Levenshtein distance for unknown identifier errors ---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the suggestion. I'm closing this ticket as a duplicate of #2442. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:44:04 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:28:32 2009 Subject: [GHC] #3216: Terminal output in GHCi 10.3 on Mac OS X In-Reply-To: <044.015402d518098531d13d84633eabcb1e@localhost> References: <044.015402d518098531d13d84633eabcb1e@localhost> Message-ID: <053.339167943cf80d50730316ac5221b6a3@localhost> #3216: Terminal output in GHCi 10.3 on Mac OS X ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:44:24 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:28:50 2009 Subject: [GHC] #3215: Valgrind support In-Reply-To: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> References: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> Message-ID: <052.c17f0f7de74e5c212ba8994068458c94@localhost> #3215: Valgrind support --------------------------------+------------------------------------------- Reporter: cmcq | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Runtime System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: valgrind | Difficulty: Unknown Testcase: yes | Os: Linux Architecture: x86 | --------------------------------+------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > This is based on code in gtk2hs. > > $ valgrind -q ./finalizer_queue > > finalizer_queue: internal error: stg_ap_v_ret > (GHC version 6.10.3 for i386_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Killed > > Unfortunately this test doesn't crash without Valgrind. > > My guess is that this bit is the problem: > > finalizer <- fixIO $ \dPtr -> mkThunk $ do > freeHaskellFunPtr callback > freeHaskellFunPtr dPtr > > Perhaps the documentation should say not to do this? New description: This is based on code in gtk2hs. {{{ $ valgrind -q ./finalizer_queue finalizer_queue: internal error: stg_ap_v_ret (GHC version 6.10.3 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Killed }}} Unfortunately this test doesn't crash without Valgrind. My guess is that this bit is the problem: {{{ finalizer <- fixIO $ \dPtr -> mkThunk $ do freeHaskellFunPtr callback freeHaskellFunPtr dPtr }}} Perhaps the documentation should say not to do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:54:42 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:39:10 2009 Subject: [GHC] #3210: Allow programs to change the number of capabilities In-Reply-To: <051.bb934f2dd576d96d5354d86a9c82db8c@localhost> References: <051.bb934f2dd576d96d5354d86a9c82db8c@localhost> Message-ID: <060.f8e8deecfd315411a65e9cfdd9a9a845@localhost> #3210: Allow programs to change the number of capabilities ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 14:57:24 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:41:50 2009 Subject: [GHC] #3205: Generalized isomorphic deriving In-Reply-To: <042.5465e02313ec0c86ef0c59c5b9869960@localhost> References: <042.5465e02313ec0c86ef0c59c5b9869960@localhost> Message-ID: <051.de0432e2c0bdc31bc44e3a586dee0d03@localhost> #3205: Generalized isomorphic deriving ---------------------------------+------------------------------------------ Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => _|_ Comment: Thanks for the suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 15:02:33 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:47:01 2009 Subject: [GHC] #3215: Valgrind support In-Reply-To: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> References: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> Message-ID: <052.311844c52d96865c9cc396c1c8ddb787@localhost> #3215: Valgrind support --------------------------------+------------------------------------------- Reporter: cmcq | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: valgrind | Difficulty: Unknown Testcase: yes | Os: Linux Architecture: x86 | --------------------------------+------------------------------------------- Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 15:03:10 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:47:37 2009 Subject: [GHC] #3220: type variables appearing only in type equality constraints are not generalized In-Reply-To: <044.61e1ea4a3856a3ecde009628edb5e8f4@localhost> References: <044.61e1ea4a3856a3ecde009628edb5e8f4@localhost> Message-ID: <053.3d82de12bf2832f7875a799bf15178f3@localhost> #3220: type variables appearing only in type equality constraints are not generalized ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 15:09:46 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:54:14 2009 Subject: [GHC] #3221: Incorrect "defined but not used" warning for data types using deriving In-Reply-To: <051.1c3c57be6f72429406e355f3cf480220@localhost> References: <051.1c3c57be6f72429406e355f3cf480220@localhost> Message-ID: <060.a590bc206a22114ee48ba82bfb60d59f@localhost> #3221: Incorrect "defined but not used" warning for data types using deriving ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 15:10:49 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:55:15 2009 Subject: [GHC] #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 In-Reply-To: <053.190394749e5862e303daca81830a576b@localhost> References: <053.190394749e5862e303daca81830a576b@localhost> Message-ID: <062.85f492033bc333e4f03dd8db1d3ceba5@localhost> #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 -------------------------------+-------------------------------------------- Reporter: GregFrascadore | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Old description: > Using GHC 6.10.3 to build GLFW 0.3 dies with: > > /usr/lib/gcc/i686-apple-darwin9/4.0.1/include/xmmintrin.h:35:3: > error: #error "SSE instruction set not enabled" > > on Mac OSX 10.5.6 (intel) > > By downgrading to 6.10.1 the build works. > I saw some IRC chat logs where others had this problem with 6.10.2. New description: Using GHC 6.10.3 to build GLFW 0.3 dies with: {{{ /usr/lib/gcc/i686-apple-darwin9/4.0.1/include/xmmintrin.h:35:3: error: #error "SSE instruction set not enabled" }}} on Mac OSX 10.5.6 (intel) By downgrading to 6.10.1 the build works. I saw some IRC chat logs where others had this problem with 6.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 15:11:06 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:55:32 2009 Subject: [GHC] #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 In-Reply-To: <053.190394749e5862e303daca81830a576b@localhost> References: <053.190394749e5862e303daca81830a576b@localhost> Message-ID: <062.5eb9cfa301873106075331f07465631c@localhost> #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 -------------------------------+-------------------------------------------- Reporter: GregFrascadore | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 15:12:23 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:56:52 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.69a85bc6c8b473ad1138482c27d5d22e@localhost> #3226: please eliminate error message from Make on every build ---------------------------------+------------------------------------------ Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 15:13:42 2009 From: trac at galois.com (GHC) Date: Sun May 24 14:58:11 2009 Subject: [GHC] #3228: please make it easier to remove a file from the GHC sources In-Reply-To: <041.5dbccaa2009317c73dad3a60d2601df8@localhost> References: <041.5dbccaa2009317c73dad3a60d2601df8@localhost> Message-ID: <050.7d0f85c407f3602bc3cbcd68fd098860@localhost> #3228: please make it easier to remove a file from the GHC sources --------------------------------+------------------------------------------- Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | --------------------------------+------------------------------------------- Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 15:39:36 2009 From: trac at galois.com (GHC) Date: Sun May 24 15:24:02 2009 Subject: [GHC] #3234: foldr/single no longer firing in GHC 6.10 In-Reply-To: <041.6f78ca9107f6c0f52fc046199711a2f3@localhost> References: <041.6f78ca9107f6c0f52fc046199711a2f3@localhost> Message-ID: <050.220959e86e31716172f3815f8ee449d1@localhost> #3234: foldr/single no longer firing in GHC 6.10 ---------------------------------+------------------------------------------ Reporter: r6 | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report, we'll take a look -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 15:51:09 2009 From: trac at galois.com (GHC) Date: Sun May 24 15:35:37 2009 Subject: [GHC] #3229: queued GHCi commands are not resume context specific In-Reply-To: <046.c79a02c73014f0a1866970c1d8f5c8e9@localhost> References: <046.c79a02c73014f0a1866970c1d8f5c8e9@localhost> Message-ID: <055.b1a999ea4914b6ae76bc3a06720e23c9@localhost> #3229: queued GHCi commands are not resume context specific ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: wontfix Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: If I understand correctly, you are saying that in the "rv\n:continue" the continue should apply to the current breakpoint, not a breakpoint that might be hit when evaluating rv? If so, I disagree. The behaviour of ghci commands is (and, I believe, should be) equivalent to entering "rv" then ":continue" at the ghci prompt. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 15:57:43 2009 From: trac at galois.com (GHC) Date: Sun May 24 15:42:09 2009 Subject: [GHC] #3237: Target binary-dist fails when building GHC with DPH In-Reply-To: <046.150053a88502d656bac976c7eb79864d@localhost> References: <046.150053a88502d656bac976c7eb79864d@localhost> Message-ID: <055.31b9d5700923ee681bedd2bfbecb4197@localhost> #3237: Target binary-dist fails when building GHC with DPH ---------------------------------+------------------------------------------ Reporter: scsibug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. The errors were actually only cosmetic, but worth fixing anyway. Now done: {{{ Sun May 24 20:51:37 BST 2009 Ian Lynagh * Make the dph packages more consistent with everything else }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 16:04:48 2009 From: trac at galois.com (GHC) Date: Sun May 24 15:49:15 2009 Subject: [GHC] #3238: CInt FFI exports do not use C int in _stub.h header file In-Reply-To: <045.5781f68e770b8bad07184615b4897cd3@localhost> References: <045.5781f68e770b8bad07184615b4897cd3@localhost> Message-ID: <054.e315dbe72a97b0db681c873ce2a05f6c@localhost> #3238: CInt FFI exports do not use C int in _stub.h header file ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (FFI) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 16:05:12 2009 From: trac at galois.com (GHC) Date: Sun May 24 15:49:39 2009 Subject: [GHC] #3240: Bad jump on PowerPC In-Reply-To: <044.c9404de701510cb572754e15b36dca29@localhost> References: <044.c9404de701510cb572754e15b36dca29@localhost> Message-ID: <053.c99fb6dea3b8863031835dd584750700@localhost> #3240: Bad jump on PowerPC -------------------------+-------------------------------------------------- Reporter: duane | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > ghc: internal error: unconditional relative branch out of range: jump > island out of range > (GHC version 6.10.1 for powerpc_apple_darwin) > > That's it. NOTE: I was compiling LHC when this happened. New description: {{{ ghc: internal error: unconditional relative branch out of range: jump island out of range (GHC version 6.10.1 for powerpc_apple_darwin) }}} That's it. NOTE: I was compiling LHC when this happened. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 16:06:58 2009 From: trac at galois.com (GHC) Date: Sun May 24 15:51:24 2009 Subject: [GHC] #3240: Bad jump on PowerPC In-Reply-To: <044.c9404de701510cb572754e15b36dca29@localhost> References: <044.c9404de701510cb572754e15b36dca29@localhost> Message-ID: <053.c61937975e3620b5cc812c067baddc52@localhost> #3240: Bad jump on PowerPC -------------------------+-------------------------------------------------- Reporter: duane | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.12 branch Comment: PowerPC isn't one of our tier one platforms, so we are unlikely to fix this, I'm afraid. It would be great if someone else was to do so, though! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 16:13:26 2009 From: trac at galois.com (GHC) Date: Sun May 24 15:57:53 2009 Subject: [GHC] #3258: a.out file in ghc 6.10.3 package, under libraries/haskeline In-Reply-To: <044.97bedf0d77daf2eb39ae59f26c7d9cec@localhost> References: <044.97bedf0d77daf2eb39ae59f26c7d9cec@localhost> Message-ID: <053.f139c8c4ecf870c596f31fabf791bea9@localhost> #3258: a.out file in ghc 6.10.3 package, under libraries/haskeline -------------------------------+-------------------------------------------- Reporter: guest | Owner: judah Type: bug | Status: assigned Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.3 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by judah): * status: new => assigned * owner: => judah Comment: Thanks for the report; I'm looking into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 16:22:27 2009 From: trac at galois.com (GHC) Date: Sun May 24 16:06:53 2009 Subject: [GHC] #3254: add a configure option to turn off profiling In-Reply-To: <050.9d9a599d02ae49f1bbe8ca17c16117c7@localhost> References: <050.9d9a599d02ae49f1bbe8ca17c16117c7@localhost> Message-ID: <059.67bd0b47ccdcdbd8db7c95fcc46127a4@localhost> #3254: add a configure option to turn off profiling ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.1 Comment: I agree. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 16:24:03 2009 From: trac at galois.com (GHC) Date: Sun May 24 16:08:30 2009 Subject: [GHC] #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain In-Reply-To: <045.7911c27a1a92708be5cdea967d156927@localhost> References: <045.7911c27a1a92708be5cdea967d156927@localhost> Message-ID: <054.0bb7f320ec2db7c560ddd336016ca0a1@localhost> #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (FFI) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 16:24:12 2009 From: trac at galois.com (GHC) Date: Sun May 24 16:08:39 2009 Subject: [GHC] #3241: System.Win32.Registry - incorrect length calculation in regSetStringValue In-Reply-To: <046.5e05961aa036dbf948d62b849e5dd19f@localhost> References: <046.5e05961aa036dbf948d62b849e5dd19f@localhost> Message-ID: <055.8469abebfe73c61e247694925e498888@localhost> #3241: System.Win32.Registry - incorrect length calculation in regSetStringValue ----------------------------------+----------------------------------------- Reporter: binarin | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 17:59:51 2009 From: trac at galois.com (GHC) Date: Sun May 24 17:44:17 2009 Subject: [GHC] #3258: a.out file in ghc 6.10.3 package, under libraries/haskeline In-Reply-To: <044.97bedf0d77daf2eb39ae59f26c7d9cec@localhost> References: <044.97bedf0d77daf2eb39ae59f26c7d9cec@localhost> Message-ID: <053.c6a84df121991a824ed69f9e5e1a8408@localhost> #3258: a.out file in ghc 6.10.3 package, under libraries/haskeline -------------------------------+-------------------------------------------- Reporter: guest | Owner: judah Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.3 Severity: minor | Resolution: fixed Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by judah): * status: assigned => closed * resolution: => fixed Comment: Now fixed in Haskeline's HEAD, with the following patch: {{{ * Fix ghc issue #3258: don't leave an a.out file in the current directory when configure checks for iconv. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 18:15:31 2009 From: trac at galois.com (GHC) Date: Sun May 24 18:00:06 2009 Subject: [GHC] #3229: queued GHCi commands are not resume context specific In-Reply-To: <046.c79a02c73014f0a1866970c1d8f5c8e9@localhost> References: <046.c79a02c73014f0a1866970c1d8f5c8e9@localhost> Message-ID: <055.9aeaec7792ae98e56002fcd71dd867bc@localhost> #3229: queued GHCi commands are not resume context specific ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: wontfix Keywords: debugger | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by phercek): Yes, that is what I meant. The scope in which (queued) commands are going to be executed is not lexical. It is hard to predict. Commands are entered in a different scope (the current breakpoint) than the scope they are executed (the scope of breakpoint hit when evaluating rv).[[BR]] wontfix -> ok. Thanks for your response. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 24 21:30:00 2009 From: trac at galois.com (GHC) Date: Sun May 24 21:14:26 2009 Subject: [GHC] #3259: A module-local combinator using Control.Parallel.par behaves differently than when it's imported Message-ID: <047.f55d603926435334ce84eb70656ee259@localhost> #3259: A module-local combinator using Control.Parallel.par behaves differently than when it's imported ---------------------+------------------------------------------------------ Reporter: blamario | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 ---------------------+------------------------------------------------------ There's a moderately long thread@haskell-cafe discussing the problem at: http://www.haskell.org/pipermail/haskell-cafe/2009-May/061765.html I will attach the source files and the outputs of compilation with ghc-6.11.20090421 --make primes-test.hs -threaded -O2 -ddump-simpl on a 32-bit Ubuntu 2009.4. What appears to be happening is that GHC generates the call to function `parallelize' as though it was strict, even though the interface declares it as lazy, but only when the function is imported. The only proof of this, apart from the execution time, is this line of difference between the two -ddump-simpl outputs: > $diff main.simpl imported.simpl > ... > 223c232 > < a_s1rs [ALWAYS Just L] :: GHC.Integer.Internals.Integer > --- > > a_s1sV [ALWAYS Just S] :: GHC.Integer.Internals.Integer > ... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon May 25 14:08:32 2009 From: trac at galois.com (GHC) Date: Mon May 25 13:52:58 2009 Subject: [GHC] #3240: Bad jump on PowerPC In-Reply-To: <044.c9404de701510cb572754e15b36dca29@localhost> References: <044.c9404de701510cb572754e15b36dca29@localhost> Message-ID: <053.da2c95307d827fdf70c3a0d0a14225f6@localhost> #3240: Bad jump on PowerPC -------------------------+-------------------------------------------------- Reporter: duane | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by thorkilnaur): * status: new => closed * resolution: => duplicate Comment: I believe that this is a duplicate of #1845, so closing. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 11:23:23 2009 From: trac at galois.com (GHC) Date: Tue May 26 11:07:46 2009 Subject: [GHC] #3151: Hello World does not compile (missing Prelude?) In-Reply-To: <046.b749efc6988a8d640d3ddf4cc38315c8@localhost> References: <046.b749efc6988a8d640d3ddf4cc38315c8@localhost> Message-ID: <055.8394cd14bb4e57a3d736ff30c576f720@localhost> #3151: Hello World does not compile (missing Prelude?) -----------------------------+---------------------------------------------- Reporter: fft1976 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.10.2 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This was built without the libffi dependency in 6.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 11:24:23 2009 From: trac at galois.com (GHC) Date: Tue May 26 11:08:50 2009 Subject: [GHC] #1779: unknown symbol `hs_hpc_module' In-Reply-To: <044.e238a8559ffe0a21198f4a819a87e869@localhost> References: <044.e238a8559ffe0a21198f4a819a87e869@localhost> Message-ID: <053.69bf8ef1e6d7913540d08a3ee765fb32@localhost> #1779: unknown symbol `hs_hpc_module' ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: low | Milestone: 6.10 branch Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: wontfix Keywords: hpc | Difficulty: Unknown Testcase: hpc_ghc_ghci | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: We won't be merging non-essential fixes into the 6.10 branch any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 11:24:28 2009 From: trac at galois.com (GHC) Date: Tue May 26 11:08:53 2009 Subject: [GHC] #3153: Panic on syntactically wrong LANGUAGE pragma In-Reply-To: <046.e46bd4755ec7800cf1cf91fcd229221c@localhost> References: <046.e46bd4755ec7800cf1cf91fcd229221c@localhost> Message-ID: <055.2942638cfd41675075ab32e204718e2e@localhost> #3153: Panic on syntactically wrong LANGUAGE pragma -------------------------------+-------------------------------------------- Reporter: b_jonas | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.2 Severity: minor | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: We won't be merging non-essential fixes into the 6.10 branch any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 11:24:32 2009 From: trac at galois.com (GHC) Date: Tue May 26 11:08:56 2009 Subject: [GHC] #3126: GHC needs to be more careful about pattern match order In-Reply-To: <044.905997d1d3bd9039e7f58de24b44ab6b@localhost> References: <044.905997d1d3bd9039e7f58de24b44ab6b@localhost> Message-ID: <053.70b1f6d5e8de74ab5c90c08bd7d0b422@localhost> #3126: GHC needs to be more careful about pattern match order -----------------------------------------+---------------------------------- Reporter: claus | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: deSugar/should_run/T3126 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: We won't be merging non-essential fixes into the 6.10 branch any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 11:24:36 2009 From: trac at galois.com (GHC) Date: Tue May 26 11:08:59 2009 Subject: [GHC] #3097: Parser doesn't support doc comments on type aliases In-Reply-To: <044.6ac53274c77a45d41dec45a1148c8504@localhost> References: <044.6ac53274c77a45d41dec45a1148c8504@localhost> Message-ID: <053.9c62b086cb96e67d5ee44a962d9e5e3d@localhost> #3097: Parser doesn't support doc comments on type aliases ---------------------------------+------------------------------------------ Reporter: waern | Owner: Type: merge | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: wontfix Keywords: Haddock | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: We won't be merging non-essential fixes into the 6.10 branch any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 11:42:03 2009 From: trac at galois.com (GHC) Date: Tue May 26 11:26:26 2009 Subject: [GHC] #2781: Install permissions broken In-Reply-To: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> References: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> Message-ID: <053.5828b8b1b744ae1a9ba24dc42999b690@localhost> #2781: Install permissions broken ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: install permissions | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * milestone: 6.10.2 => 6.12.1 Comment: Let's look at this for 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 11:43:37 2009 From: trac at galois.com (GHC) Date: Tue May 26 11:27:59 2009 Subject: [GHC] #3163: GADTs should not allow polymorphism in return type In-Reply-To: <051.9e183310fa287b7470565c1ecdf33535@localhost> References: <051.9e183310fa287b7470565c1ecdf33535@localhost> Message-ID: <060.11a24230b0e4f102670aab8f006dab29@localhost> #3163: GADTs should not allow polymorphism in return type ----------------------------------------+----------------------------------- Reporter: Scott Turner | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm fixing this (easy). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 12:25:02 2009 From: trac at galois.com (GHC) Date: Tue May 26 12:09:22 2009 Subject: [GHC] #3259: A module-local combinator using Control.Parallel.par behaves differently than when it's imported In-Reply-To: <047.f55d603926435334ce84eb70656ee259@localhost> References: <047.f55d603926435334ce84eb70656ee259@localhost> Message-ID: <056.d289d1ac212dfd8e1e90dd843e057bcb@localhost> #3259: A module-local combinator using Control.Parallel.par behaves differently than when it's imported -------------------------+-------------------------------------------------- Reporter: blamario | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Old description: > There's a moderately long thread@haskell-cafe discussing the problem at: > > http://www.haskell.org/pipermail/haskell-cafe/2009-May/061765.html > > I will attach the source files and the outputs of compilation with > > ghc-6.11.20090421 --make primes-test.hs -threaded -O2 -ddump-simpl > > on a 32-bit Ubuntu 2009.4. > > What appears to be happening is that GHC generates the call to function > `parallelize' as though it was strict, even though the interface declares > it as lazy, but only when the function is imported. > > The only proof of this, apart from the execution time, is this line of > difference between the two -ddump-simpl outputs: > > > $diff main.simpl imported.simpl > > ... > > 223c232 > > < a_s1rs [ALWAYS Just L] :: GHC.Integer.Internals.Integer > > --- > > > a_s1sV [ALWAYS Just S] :: GHC.Integer.Internals.Integer > > ... New description: There's a moderately long thread@haskell-cafe discussing the problem at: http://www.haskell.org/pipermail/haskell-cafe/2009-May/061765.html I will attach the source files and the outputs of compilation with {{{ ghc-6.11.20090421 --make primes-test.hs -threaded -O2 -ddump-simpl }}} on a 32-bit Ubuntu 2009.4. What appears to be happening is that GHC generates the call to function `parallelize' as though it was strict, even though the interface declares it as lazy, but only when the function is imported. The only proof of this, apart from the execution time, is this line of difference between the two -ddump-simpl outputs: {{{ > $diff main.simpl imported.simpl > ... > 223c232 > < a_s1rs [ALWAYS Just L] :: GHC.Integer.Internals.Integer > --- > > a_s1sV [ALWAYS Just S] :: GHC.Integer.Internals.Integer > ... }}} Comment: Well diagnosed! Your report reveals quite a long-standing and serious but, so thank you! It'll generate nasty, insidious loss of parallelism. Here's brain dump of what is going on, just to record it for posterity. `par` is defined in `GHC.Conc` thus: {{{ {-# INLINE par #-} par :: a -> b -> b par x y = case (par# x) of { _ -> lazy y } -- The reason for the strange "lazy" call is that -- it fools the compiler into thinking that pseq and par are non-strict in -- their second argument (even if it inlines pseq/par at the call site). -- If it thinks par is strict in "y", then it often evaluates -- "y" before "x", which is totally wrong. }}} The function `lazy` is the identity function, but it is inlined only after strictness analysis, and (via some magic) pretends to be lazy. Hence `par` pretends to be lazy too. The trouble is that both `par` and `lazy` are inlined into your definition of `parallelise`, so that the unfolding for `parallelise` (exposed in `Parallelise.hi`) does not use `lazy` at all. Then when compiling `Main`, `parallelise` is in turn inlined (before strictness analysis), and so the strictness analyser sees too much. This was all sloppy thinking on my part. Inlining `lazy` after strictness analysis works fine for the ''current'' module, but not for ''importing'' modules. My proposed fix is to inline `lazy` only at the very, very end, and in particular ''after'' any unfoldings have been exposed in an interface file. That might mean that we lose some optimisations, but I don't think it'll make much difference. However, I'm going to leave this until Simon M gets back from holiday to discuss. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 13:58:19 2009 From: trac at galois.com (GHC) Date: Tue May 26 13:42:41 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.d90f8c455fd6503fb770dbf8a1cfda20@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * cc: YitzGale (added) Comment: At the start of this ticket I proposed a modest change. I can't say I have followed the conversation between Claus and Simon in detail; but it seems at least that consensus has not been reached. There is a danger that the original suggestion will fall by the wayside by becoming entangled in a larger debate. My suggestion is to implement the change I originally proposed (in brief: have a flag-set for the GHCi prompt, distinct from the ones used for compiling modules), leaving any more sophisticated feature request for another ticket. But before doing so: * No one except Claus has commented on the original suggestion. Does anyone case? If not, maybe it is not worth the bother? * Claus, are you of the opinion that it'd be a retrograde step to implement the original proposal of this ticket, without implementing some version of your proposal? Or would it be a step in the right direction? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 14:06:27 2009 From: trac at galois.com (GHC) Date: Tue May 26 13:50:49 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.4b872231e7d054507f80047dc0f8cbd4@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): I agree that the original proposal makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 14:24:38 2009 From: trac at galois.com (GHC) Date: Tue May 26 14:09:05 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.195c8f057bd913c8142309f7ad7fb27a@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by YitzGale): I thought your mention of #3202 in the original description was already an implicit statement of my support for this, so I kept quiet. But yes, I do support it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue May 26 19:21:39 2009 From: trac at galois.com (GHC) Date: Tue May 26 19:06:10 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.0030a186ca598bbfe1135bf65a7f6876@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by claus): Replying to [comment:11 simonpj]: > ..conversation between Claus and Simon in detail; but it seems at least that consensus has not been reached. I thought consensus was fairly close: - I'm no longer opposed to the change in principle - I'm still slightly worried about the interface adding complexity (perhaps it would suffice to document that `:set` corresponds to commandline options while `:seti` corresponds to in-source pragmas, but it would be better to make it so) - Simon and I seemed to agree that this separation should be followed by making the interactive options match the in-source options for the current module - we agreed that this would be easier to achieve if there was only one `*`-ed module permitted per session (currently many such are permitted) - we only disagreed on whether such a restriction might have negative effects on other use cases; Simon strongly favoured this to avoid having to define what it means for two modules to have compatible options; I tended the other way, assuming it would be useful to have this defined anyway > * Claus, are you of the opinion that it'd be a retrograde step to implement the original proposal of this ticket, without implementing some version of your proposal? Or would it be a step in the right direction? It would be a half step in the right direction. The only disadvantage I can see is that without the other half step, the interim state might actually be more complex (three sets of options to keep track of instead of two). But as I said, I'm no longer opposed (just want more consistency and less complexity;-). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 03:08:42 2009 From: trac at galois.com (GHC) Date: Wed May 27 02:53:08 2009 Subject: [GHC] #3260: Linking stage2 on PPC gives "scattered reloc r_address too large" Message-ID: <043.9087f80d620051a542dc03d51ff19b43@localhost> #3260: Linking stage2 on PPC gives "scattered reloc r_address too large" -----------------------------+---------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: critical Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Linking the head stage2 compiler on PPC has been failing since about the 5th of April, with the following message: {{{ ld warning: atom sorting error for _ghczm6zi11zi20090527_LibFFI_Czuffizucif_closure_tbl and _ghczm6zi11zi20090527_LibFFI_Czuffizutype_closure_tbl in compiler/stage2/build/LibFFI.o ld warning: atom sorting error for _ghczm6zi11zi20090527_LibFFI_Czuffizucif_closure_tbl and _ghczm6zi11zi20090527_LibFFI_Czuffizutype_closure_tbl in compiler/stage2/build/LibFFI.o ld: scattered reloc r_address too large for inferred architecture ppc }}} From the build bot logs, it was working on the 4th of April. Coincidently, a stack of Cmm codegen patches were also pushed that day... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 03:09:41 2009 From: trac at galois.com (GHC) Date: Wed May 27 02:54:02 2009 Subject: [GHC] #3260: Linking stage2 on PPC gives "scattered reloc r_address too large" In-Reply-To: <043.9087f80d620051a542dc03d51ff19b43@localhost> References: <043.9087f80d620051a542dc03d51ff19b43@localhost> Message-ID: <052.aac354da6fc84898fc9122aab69798c3@localhost> #3260: Linking stage2 on PPC gives "scattered reloc r_address too large" ----------------------+----------------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: critical | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: powerpc ----------------------+----------------------------------------------------- Changes (by benl): * os: Unknown/Multiple => MacOS X * architecture: Unknown/Multiple => powerpc -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 04:38:06 2009 From: trac at galois.com (GHC) Date: Wed May 27 04:23:22 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.740d01d8693d8c13d0ff831cc98a4d19@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by tibbe): * cc: johan.tibell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 04:42:07 2009 From: trac at galois.com (GHC) Date: Wed May 27 04:26:28 2009 Subject: [GHC] #2813: Create a utf8 bytestring-a-like In-Reply-To: <044.ad636022be236bf694f594b538272960@localhost> References: <044.ad636022be236bf694f594b538272960@localhost> Message-ID: <053.1e751239a37641e97eb38a5aa3692567@localhost> #2813: Create a utf8 bytestring-a-like ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by tibbe): The `text` library was released quite a while ago. Should we close this ticket and create separate tickets to track libraries that need to switch from `FastString` to `Text`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 06:27:42 2009 From: trac at galois.com (GHC) Date: Wed May 27 06:12:06 2009 Subject: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad In-Reply-To: <046.ecd79a44a24e66ebe8454442595b165e@localhost> References: <046.ecd79a44a24e66ebe8454442595b165e@localhost> Message-ID: <055.0913cb0dfb1cf5d4f713b12465ba9033@localhost> #3138: Returning a known constructor: GHC generates terrible code for cmonad -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * cc: lennart@augustsson.net (added) Comment: Lennart, I've taken a quick look. As you say, it generates quite a lot of code. I attach the result of -ddump-simpl for `Inf.hs` compiled with -O. There is indeed one function that return a simple constructor from a sum type, namely `+=_r1mk`. Doing the CPR transform for this would indeed be a significant improvement. But is that it? Can you point to other lost optimisations? For example, `while` is recursive so we can't inline that. I'm sure you're right that we should get good code here, but because I don't know the code, it's harder to spot what should be done that isn't getting done. Can you help? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 07:26:29 2009 From: trac at galois.com (GHC) Date: Wed May 27 07:10:55 2009 Subject: [GHC] #3013: New simple GADT feature In-Reply-To: <044.28ccf32146b8a6f2dca8fc7552e2ce8a@localhost> References: <044.28ccf32146b8a6f2dca8fc7552e2ce8a@localhost> Message-ID: <053.91920f18ee3286a1efccecf77dd9b057@localhost> #3013: New simple GADT feature ---------------------------------+------------------------------------------ Reporter: guest | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt/T3013 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => gadt/T3013 * owner: => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 14:28:59 2009 From: trac at galois.com (GHC) Date: Wed May 27 14:13:19 2009 Subject: [GHC] #2813: Create a utf8 bytestring-a-like In-Reply-To: <044.ad636022be236bf694f594b538272960@localhost> References: <044.ad636022be236bf694f594b538272960@localhost> Message-ID: <053.722c91091a6c98ba77bda75ffe40cdbd@localhost> #2813: Create a utf8 bytestring-a-like ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by bos): I think that would make sense, but the GHC team should understand that this will make those libraries depend on both {{{bytestring}}} and {{{text}}}, since the {{{text}}} library (quite rightly) performs no I/O. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 14:29:15 2009 From: trac at galois.com (GHC) Date: Wed May 27 14:13:33 2009 Subject: [GHC] #2781: Install permissions broken In-Reply-To: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> References: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> Message-ID: <053.5eb2c76e51826d8b76155359f484700a@localhost> #2781: Install permissions broken ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: install permissions | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Comment (by ray): I use umask 077, and when I installed 6.10.3 from the .tar.bz2, all the permissions were set correctly, except on .hi files which were installed with mode 600. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 15:17:39 2009 From: trac at galois.com (GHC) Date: Wed May 27 15:01:57 2009 Subject: [GHC] #3221: Incorrect "defined but not used" warning for data types using deriving In-Reply-To: <051.1c3c57be6f72429406e355f3cf480220@localhost> References: <051.1c3c57be6f72429406e355f3cf480220@localhost> Message-ID: <060.230fcc6a19396e80b5ed914421ecbcbe@localhost> #3221: Incorrect "defined but not used" warning for data types using deriving --------------------------------------------+------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rename/should_compile/T3221 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => rename/should_compile/T3221 * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Wed May 27 19:21:57 BST 2009 simonpj@microsoft.com * Fix Trac #3221: renamer warnings for deriving clauses This patch arranges to gather the variables used by 'deriving' clauses, so that unused bindings are correctly reported. }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 15:20:05 2009 From: trac at galois.com (GHC) Date: Wed May 27 15:04:22 2009 Subject: [GHC] #3177: support quasiquoting for types In-Reply-To: <044.c3a64b2980f70bac4463359d5d880ce5@localhost> References: <044.c3a64b2980f70bac4463359d5d880ce5@localhost> Message-ID: <053.41e62d603c2b087acd2841a08c43da72@localhost> #3177: support quasiquoting for types ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): OK I've implemented type splices for Template Haskell: {{{ Wed May 27 19:12:42 BST 2009 simonpj@microsoft.com * Template Haskell: allow type splices At last! Trac #1476 and #3177 This patch extends Template Haskell by allowing splices in types. For example f :: Int -> $(burble 3) A type splice should work anywhere a type is expected. This feature has been long requested, and quite a while ago I'd re-engineered the type checker to make it easier, but had never got around to finishing the job. With luck, this does it. There's a ToDo in the HsSpliceTy case of RnTypes.rnHsType, where I am not dealing properly with the used variables; but that's awaiting the refactoring of the way we report unused names. }}} Give it a try. Does that allow us to close this ticket? I have not changed the Mainland quasi-quoting stuff at all. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 15:29:22 2009 From: trac at galois.com (GHC) Date: Wed May 27 15:13:41 2009 Subject: [GHC] #3163: GADTs should not allow polymorphism in return type In-Reply-To: <051.9e183310fa287b7470565c1ecdf33535@localhost> References: <051.9e183310fa287b7470565c1ecdf33535@localhost> Message-ID: <060.3f481741dcd7fb8a7dc8fbde790684d4@localhost> #3163: GADTs should not allow polymorphism in return type ----------------------------------------+----------------------------------- Reporter: Scott Turner | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: gadt/T3163 | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by simonpj): * testcase: => gadt/T3163 * status: new => closed * resolution: => fixed Comment: Done! The fix got mixed into a Template Haskell enhancement: {{{ Wed May 27 19:12:42 BST 2009 simonpj@microsoft.com * Template Haskell: allow type splices M ./compiler/typecheck/TcMType.lhs -4 +8 }}} Specifically there was a bug in `TcMType.check_arg_type`, which is great to have found. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 17:26:29 2009 From: trac at galois.com (GHC) Date: Wed May 27 17:10:46 2009 Subject: [GHC] #3261: Some warnings disappear with -Werror Message-ID: <044.8d6b58b221fa49d86f05eb51fe6b35d1@localhost> #3261: Some warnings disappear with -Werror -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: tcfail204 Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- With `q.hs`: {{{ module Foo where foo :: Int foo = ceiling 6.3 }}} I get: {{{ $ ghc -fforce-recomp -c q.hs -Wall q.hs:5:6: Warning: Defaulting the following constraint(s) to type `Double' `RealFrac t' arising from a use of `ceiling' at q.hs:5:6-16 In the expression: ceiling 6.3 In the definition of `foo': foo = ceiling 6.3 $ ghc -fforce-recomp -c q.hs -Wall -Werror $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed May 27 18:52:26 2009 From: trac at galois.com (GHC) Date: Wed May 27 18:36:44 2009 Subject: [GHC] #3262: Identifiers beginning with _ should not be considered for shadowing Message-ID: <053.7f9640f49679d186d24dc33b724000a9@localhost> #3262: Identifiers beginning with _ should not be considered for shadowing -----------------------------+---------------------------------------------- Reporter: batterseapower | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: trivial Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following program: {{{ main = do let _ignored = 10 let _ignored = 20 return () }}} Prints this warning (when compiled with, for example, -Wall): {{{ temp.hs:3:6: Warning: This binding for `_ignored' shadows the existing binding bound at temp.hs:2:6 In the binding group for: _ignored }}} In my opinion identifiers prefixed with _ should be ignored for the purposes of determining shadowing in the same way as they are ignored for the purposes of checking if something is bound but not used. So in particular, this warning would not be generated. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 00:26:26 2009 From: trac at galois.com (GHC) Date: Thu May 28 00:10:49 2009 Subject: [GHC] #2715: Equality constraint in superclass not supported In-Reply-To: <047.797aaec011bad118fea0580e1c0ce283@localhost> References: <047.797aaec011bad118fea0580e1c0ce283@localhost> Message-ID: <056.29f73d19f488190829e20526a74564e8@localhost> #2715: Equality constraint in superclass not supported ----------------------------------------+----------------------------------- Reporter: rodprice | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Comment (by porges): Just wondering if this is still slated to be in 6.12... :) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 01:42:40 2009 From: trac at galois.com (GHC) Date: Thu May 28 01:26:57 2009 Subject: [GHC] #3263: Warnings for monadic values not used Message-ID: <051.2ba77802c306560898b377ae21be4ade@localhost> #3263: Warnings for monadic values not used -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I would like two warnings. The first {{{-fwarn-unused-monad-bind}}}: {{{ do doesFileExist "foo" ; return 1 }}} {{{doesFileExist}}} returns a value of {{{IO Bool}}}, not {{{IO ()}}}, and does not bind it's result. This warning should be applied to both {{{do}}} notation and {{{>>}}} and should fire on all values which aren't {{{m ()}}}. The second {{{-fwarn-wrong-bind}}}: {{{ do return (doesFileExist "foo") ; return 1 }}} {{{doesFileExist}}} returns a value of type {{{IO (IO a)}}}, which is not bound. This warning should fire on all {{{m (m a)}}} values and also in {{{>>}}}. The names of the flags are intended to be placeholders for a sensibly chosen name. I would make {{{-fwarn-wrong-bind}}} on as a default warning, and both turned on under {{{-Wall}}}. I'm not sure anyone has ever written the second construction without it being a serious error. In the case of {{{IO}}} it's really easy to miss that some side effects are no longer happening after a refactoring. I've just made this very mistake in fairly public way. It seems that problems such as {{{mapM}}} space leaks are common, and that it is not widely known that such constructions without a named binding are always wrong. I've had to explain the problem to fairly experienced Haskell programmers. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 02:46:23 2009 From: trac at galois.com (GHC) Date: Thu May 28 02:30:44 2009 Subject: [GHC] #2715: Equality constraint in superclass not supported In-Reply-To: <047.797aaec011bad118fea0580e1c0ce283@localhost> References: <047.797aaec011bad118fea0580e1c0ce283@localhost> Message-ID: <056.6f27e4d45e022d9f12de0968ee9e28d7@localhost> #2715: Equality constraint in superclass not supported ----------------------------------------+----------------------------------- Reporter: rodprice | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Comment (by simonpj): Yes, that's still the plan. But there's still a fair bit of upheaval going on in the type inference for equalities, so don't hold your breath. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 03:59:37 2009 From: trac at galois.com (GHC) Date: Thu May 28 03:43:55 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.f4fcb8182204ea534e4471edd0422611@localhost> #2953: deriving Functor, Foldable, Traversable ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: twanvl Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK done {{{ Thu May 28 08:50:31 BST 2009 simonpj@microsoft.com * Separate flags -XDeriveFunctor, -XDeriveFoldable, -XDeriveTraversable See Trac #2953. This patch implements a distinct flag for each extended class that may be automatically derived. And I updated the user manual to reflect the fact that we can now derive Functor, Foldable, Traversable. }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 04:00:36 2009 From: trac at galois.com (GHC) Date: Thu May 28 03:45:06 2009 Subject: [GHC] #3013: New simple GADT feature In-Reply-To: <044.28ccf32146b8a6f2dca8fc7552e2ce8a@localhost> References: <044.28ccf32146b8a6f2dca8fc7552e2ce8a@localhost> Message-ID: <053.09d187cdead07578ad65693e3d1c1423@localhost> #3013: New simple GADT feature ---------------------------------+------------------------------------------ Reporter: guest | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: gadt/T3013 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Good idea. Implemented (and documented) by {{{ Thu May 28 08:53:06 BST 2009 simonpj@microsoft.com * Fix Trac #3013: multiple constructors in a GADT decl Makes GADT syntax consistent by allowing multiple constructors to be given a single signature data T wehre A, B :: T C :: Int -> t M ./compiler/parser/Parser.y.pp -6 +10 M ./compiler/parser/RdrHsSyn.lhs -5 +13 M ./docs/users_guide/glasgow_exts.xml +10 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 04:52:25 2009 From: trac at galois.com (GHC) Date: Thu May 28 04:36:40 2009 Subject: [GHC] #3261: Some warnings disappear with -Werror In-Reply-To: <044.8d6b58b221fa49d86f05eb51fe6b35d1@localhost> References: <044.8d6b58b221fa49d86f05eb51fe6b35d1@localhost> Message-ID: <053.456503310f70efac4cdda87e179d4479@localhost> #3261: Some warnings disappear with -Werror ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail204 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => simonpj Comment: Oh OK, I see what is going on. Will fix. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 06:34:20 2009 From: trac at galois.com (GHC) Date: Thu May 28 06:18:39 2009 Subject: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions In-Reply-To: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> References: <046.b0df7eb2aa8d6a2ad69558d84c454719@localhost> Message-ID: <055.a300ef7b44bf46fb3bdec4a07912b8d3@localhost> #3217: Make GHCi have separate flags for interactive Haskell expressions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): I've had a chat with Simon. Here is our proposed design. * Change GHCi so that ''at most one'' module is "fully open", currently denoted *M in GHCi's prompt. If a module M is "fully open", expressions typed at the GHCi prompt are interpreted (roughly) as if they were written in M itself. Specifically: * All the top-level things in the module are in scope * The per-module flags in `{-# OPTIONS #-}` and `{-# LANGUAGE #-}` pragmas * M's `default` declaration holds * Note that currently more than one module can be fully open, and their top level scopes are merged. We propose to make that ''at most one''. * The `DynFlags` used to compile code will be computed as follows. * When compiling a module M: * Start with the baseline `DynFlags` * Apply flags specified on the original command-line * Apply flags specified by `:set` in this GHCi session * Apply flags specified in the module M itself[[BR]][[BR]] * When compiling an expression typed on the GHCi command line: * Start with the baseline `DynFlags` * Apply flags specified on the original command-line * (Perhaps: apply flags specified by `:set` in this GHCi session. We aren't sure whether or not to do this.) * Apply GHCi baseline command-prompt flags (e.g. special defaulting rules) * Apply flags specified by `:seti` in this GHCi session * If there is a fully-open module M, apply flags specified in M itself. That is, flags in M get the last word. * Fixing GHCi so that M's `default` declaration holds is a separate job, but it's really part of the same ball of wax. Implementing this plan will require some representation changes. In particular, since we need to apply M's source-code flags in two difference places, we really need to remember the diffs with M, perhaps as a `(DynFlags -> DynFlags)` function or something. This all seems quite feasible, but it's fiddly. Neither plans to implement it right away, but we'd be happy if someone else did. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 08:39:49 2009 From: trac at galois.com (GHC) Date: Thu May 28 08:24:16 2009 Subject: [GHC] #3257: System.Exit.exitWith exits current thread, not program In-Reply-To: <050.495fc286d66dcfea7ccac05a6bd8fa06@localhost> References: <050.495fc286d66dcfea7ccac05a6bd8fa06@localhost> Message-ID: <059.8a31a1fef37f3f1a317ac5446d6231f3@localhost> #3257: System.Exit.exitWith exits current thread, not program ----------------------------------+----------------------------------------- Reporter: Bart Massey | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown Comment: I'll fix the docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 08:48:11 2009 From: trac at galois.com (GHC) Date: Thu May 28 08:32:27 2009 Subject: [GHC] #3264: Real World Haskell book example issue Message-ID: <043.62b83c250c57017e61ee880ff79b5d25@localhost> #3264: Real World Haskell book example issue -------------------------------------+-------------------------------------- Reporter: oddy | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: panic! | Testcase: Os: Windows | Architecture: x86 -------------------------------------+-------------------------------------- load !SimpleResult.hs from the chapter 5 of the book try to output alist "result" I've got this: {{{ : panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): loadObj: failed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 09:32:50 2009 From: trac at galois.com (GHC) Date: Thu May 28 09:17:10 2009 Subject: [GHC] #3248: internal error: splitLargeBlog In-Reply-To: <042.a16a9634521cae64d42a8b147c2dc965@localhost> References: <042.a16a9634521cae64d42a8b147c2dc965@localhost> Message-ID: <051.ce8cd7e2db4c2374d64c54bc59e75989@localhost> #3248: internal error: splitLargeBlog ---------------------------------+------------------------------------------ Reporter: odr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.10.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report. Already reported as #3156 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 09:35:28 2009 From: trac at galois.com (GHC) Date: Thu May 28 09:19:45 2009 Subject: [GHC] #3156: Error on +RTS kHugeNumber In-Reply-To: <044.bcb7c7bbf404d4091f28f0c21eab873f@localhost> References: <044.bcb7c7bbf404d4091f28f0c21eab873f@localhost> Message-ID: <053.3b088316e95ba17707bd5549f422e56d@localhost> #3156: Error on +RTS kHugeNumber -------------------------------------+-------------------------------------- Reporter: zachk | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: minor | Resolution: Keywords: 6.10.1||6.10.2 Stack | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------------+-------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 10:19:57 2009 From: trac at galois.com (GHC) Date: Thu May 28 10:04:14 2009 Subject: [GHC] #3189: Exception in canonicalizePath if path has national symbols In-Reply-To: <044.a27e70374e3931f7c0e96425b2a1dbab@localhost> References: <044.a27e70374e3931f7c0e96425b2a1dbab@localhost> Message-ID: <053.bd78bdefd535922c19d4f559892d816e@localhost> #3189: Exception in canonicalizePath if path has national symbols ------------------------------------+--------------------------------------- Reporter: Tonal | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 10:35:43 2009 From: trac at galois.com (GHC) Date: Thu May 28 10:19:59 2009 Subject: [GHC] #3186: findExeutable does not respect order of search path on Windows In-Reply-To: <045.8d432c25f775875a5ebadcd8663d4571@localhost> References: <045.8d432c25f775875a5ebadcd8663d4571@localhost> Message-ID: <054.e72cfa4110f84cb2617d33525f166cb0@localhost> #3186: findExeutable does not respect order of search path on Windows ------------------------------------+--------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: Is this ok? {{{ -- On Windows, 'findExecutable' calls the Win32 function 'SearchPath', -- which may search other places before checking the directories in -- @PATH@. Where it actually searches depends on registry settings, -- but notably includes the directory containing the current -- executable. See -- for more details. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 12:23:58 2009 From: trac at galois.com (GHC) Date: Thu May 28 12:08:15 2009 Subject: [GHC] #3186: findExeutable does not respect order of search path on Windows In-Reply-To: <045.8d432c25f775875a5ebadcd8663d4571@localhost> References: <045.8d432c25f775875a5ebadcd8663d4571@localhost> Message-ID: <054.a75e77ed82c39a8079a888a8ee03d1ce@localhost> #3186: findExeutable does not respect order of search path on Windows ------------------------------------+--------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Comment (by duncan): Replying to [comment:7 simonmar]: > Is this ok? Yes, it's suitable vague :-). Linking to the MS docs is a good idea. In particular, I think the search order corresponds to the program you'd run if you call `createProcess` using the direct method rather than using a shell intermediary. That fact is probably worth mentioning, and that it can be different to what you get if you go via a shell because the dir of the current process is different. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 18:35:59 2009 From: trac at galois.com (GHC) Date: Thu May 28 18:20:25 2009 Subject: [GHC] #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) In-Reply-To: <044.a125e44de5957e50d259dfbe1a2d51e0@localhost> References: <044.a125e44de5957e50d259dfbe1a2d51e0@localhost> Message-ID: <053.7a767c248e6750fc119549046daba0f0@localhost> #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by batterseapower): Implemented as a compiler plugin (http://github.com/batterseapower/unroll- plugin/tree/master). Has some unfortunate limitations: * Annotations can only occur on top level things, so we can't unroll local definitions * Ugly annotation syntax :-) * If your functions require dictionaries, the annotated functions sometimes don't 'look' recursive before the simplifier / specialiser has had a go at them, because they call directly into a recursive worker. Workaround: always give your functions monomorphic types! I've tried to avoid this by simplifying a bit before we hit the unroller, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu May 28 21:02:39 2009 From: trac at galois.com (GHC) Date: Thu May 28 20:46:55 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.a0895ee7d9ef5c4ab72bfc77fb99978c@localhost> #3263: Warnings for monadic values not used ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by isaacdupree): Quite an interesting idea! -fwarn-unused-monad-bind: as well as (), it should exclude returns that are polymorphic in any value (this idiom is sometimes used for functions that do not return, such as `exitWith :: ExitCode -> IO a` and possibly [parts of?] `callCC :: MonadCont m => ((a -> m b) -> m a) -> m a`) -fwarn-wrong-bind: good idea... and you'd get around the warning, should it prove necessary to, by explicitly binding to `_` (either `do _ <- ...` or `... >>= \_ ->`)? If you want to avoid `mapM` space leaks in real code among unsuspecting programmers, we'll need a well-designed warning-message that will convince them not to just write {{{ --avoid silly warning: we *don't* use the result _ <- mapM ... }}} Possibly some pragma action could help GHC give more precise suggestions (like "use mapM_") I guess the warnings would hardcode Monad, and probably hardcode () as well, or would it be better (easier? harder?) to apply to any zero- information data (aka `data Zero` and `data One = One` and perhaps some newtype and/or GADT magic)? -Isaac Dupree -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 03:10:58 2009 From: trac at galois.com (GHC) Date: Fri May 29 02:55:13 2009 Subject: [GHC] #3261: Some warnings disappear with -Werror In-Reply-To: <044.8d6b58b221fa49d86f05eb51fe6b35d1@localhost> References: <044.8d6b58b221fa49d86f05eb51fe6b35d1@localhost> Message-ID: <053.fa89b571be72e9c790e4966b33255f2b@localhost> #3261: Some warnings disappear with -Werror ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail204 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Fixed by {{{ Thu May 28 17:49:00 BST 2009 simonpj@microsoft.com * Fix Trac #3261: make default types play nice with -Werror The trial-and-error for type defaults was not playing nicely with -Werror. The fix is simple. M ./compiler/typecheck/TcSimplify.lhs -6 +7 }}} That now shows up a warning as an error, so you need this too: {{{ Thu May 28 17:45:25 BST 2009 simonpj@microsoft.com * Remove type-ambiguous (fromIntegral 0)::Int, replacing it with just 0 This unnecessary ambiguity has been there for ages, and is now rejected by -Werror, after fixing #3261 M ./compiler/ghci/ByteCodeAsm.lhs -1 +1 }}} And there's a similar case in `Float.lhs`, still to fix. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 03:52:35 2009 From: trac at galois.com (GHC) Date: Fri May 29 03:36:57 2009 Subject: [GHC] #3257: System.Exit.exitWith exits current thread, not program In-Reply-To: <050.495fc286d66dcfea7ccac05a6bd8fa06@localhost> References: <050.495fc286d66dcfea7ccac05a6bd8fa06@localhost> Message-ID: <059.cf465cd30ee0f6e033b1e907ac4afb82@localhost> #3257: System.Exit.exitWith exits current thread, not program ----------------------------------+----------------------------------------- Reporter: Bart Massey | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.10.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed * milestone: => 6.12.1 Comment: Fixed: {{{ Thu May 28 05:37:38 PDT 2009 Simon Marlow * Fix #3257: document that exitWith in a forkIO'd thread does not exit the process }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 04:50:43 2009 From: trac at galois.com (GHC) Date: Fri May 29 04:34:56 2009 Subject: [GHC] #3261: Some warnings disappear with -Werror In-Reply-To: <044.8d6b58b221fa49d86f05eb51fe6b35d1@localhost> References: <044.8d6b58b221fa49d86f05eb51fe6b35d1@localhost> Message-ID: <053.1be6c111241fcc32ce44b4128aad9d4c@localhost> #3261: Some warnings disappear with -Werror ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tcfail204 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK library patches pushed, so I'm closing this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 04:52:10 2009 From: trac at galois.com (GHC) Date: Fri May 29 04:36:23 2009 Subject: [GHC] #3262: Identifiers beginning with _ should not be considered for shadowing In-Reply-To: <053.7f9640f49679d186d24dc33b724000a9@localhost> References: <053.7f9640f49679d186d24dc33b724000a9@localhost> Message-ID: <062.35bf4246b2c5065418507d2299818d62@localhost> #3262: Identifiers beginning with _ should not be considered for shadowing ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Good idea. Done {{{ Thu May 28 16:23:59 BST 2009 simonpj@microsoft.com * Fix Trac #3262: suppress name-shadow warning for _names Adopt Max's suggestion for name shadowing, by suppressing shadowing warnings for variables starting with "_". A tiny bit of refactoring along the way. M ./compiler/basicTypes/NameSet.lhs -1 +1 M ./compiler/basicTypes/OccName.lhs -8 +7 M ./compiler/rename/RnEnv.lhs -1 +3 M ./compiler/typecheck/TcInstDcls.lhs -1 +1 M ./docs/users_guide/using.xml +5 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 04:56:40 2009 From: trac at galois.com (GHC) Date: Fri May 29 04:40:53 2009 Subject: [GHC] #3259: A module-local combinator using Control.Parallel.par behaves differently than when it's imported In-Reply-To: <047.f55d603926435334ce84eb70656ee259@localhost> References: <047.f55d603926435334ce84eb70656ee259@localhost> Message-ID: <056.7c7a81f1258e169c70a5818adfedf4fb@localhost> #3259: A module-local combinator using Control.Parallel.par behaves differently than when it's imported -------------------------+-------------------------------------------------- Reporter: blamario | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK so after talking to Simon I indeed moved the exposure of `lazy` into `CorePrep`. That certainly fixes the bug. {{{ Fri May 29 00:20:20 PDT 2009 simonpj@microsoft.com * Fix Trac #3259: expose 'lazy' only after generating interface files Ignore-this: 3c762bda546981c4b4f01d28b8586ff8 This patch fixes an insidious and long-standing bug in the way that parallelism is handled in GHC. See Note [lazyId magic] in MkId. ...snip... The downside is that a little less optimisation may happen on programs that use 'lazy'. And you'll only see this in the results -ddump-prep not in -ddump-simpl. So KEEP AN EYE OUT (Simon and Satnam especially). Still, it should work properly now. Certainly fixes #3259. M ./compiler/basicTypes/MkId.lhs -18 +23 M ./compiler/coreSyn/CorePrep.lhs -2 +10 M ./compiler/stranal/WorkWrap.lhs -10 +3 }}} I have not added a test case, because I can't see a simple way to test it. But please do see if things improve. Do watch out for loss of optimisation as a result. Simon and I do not think it'll be important, but we've been wrong before. For example, in your program you have way too many `lazy` calls: {{{ parallelize a b = lazy a `par` (lazy b `pseq` (a, b)) }}} Here the `lazy` calls are completely unnecessary, and indeed they (now) make the code a bit less efficient. Instead you can say {{{ parallelize a b = a `par` (b `pseq` (a, b)) }}} Thank you for identifying such an insidious bug. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 05:04:05 2009 From: trac at galois.com (GHC) Date: Fri May 29 04:48:21 2009 Subject: [GHC] #3177: support quasiquoting for types In-Reply-To: <044.c3a64b2980f70bac4463359d5d880ce5@localhost> References: <044.c3a64b2980f70bac4463359d5d880ce5@localhost> Message-ID: <053.af773d0f746918391ce471af4f0d2058@localhost> #3177: support quasiquoting for types ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T3177, T3177a | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => th/T3177, T3177a * status: new => closed * resolution: => fixed Comment: OK, I've added a couple of tests and am closing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 06:30:45 2009 From: trac at galois.com (GHC) Date: Fri May 29 06:14:59 2009 Subject: [GHC] #3156: Error on +RTS kHugeNumber In-Reply-To: <044.bcb7c7bbf404d4091f28f0c21eab873f@localhost> References: <044.bcb7c7bbf404d4091f28f0c21eab873f@localhost> Message-ID: <053.eda4ed9d8874ab4554d3c14051de3c39@localhost> #3156: Error on +RTS kHugeNumber -------------------------------------+-------------------------------------- Reporter: zachk | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.2 Severity: minor | Resolution: fixed Keywords: 6.10.1||6.10.2 Stack | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------------+-------------------------------------- Changes (by simonmar): * status: new => closed * component: Compiler => Runtime System * resolution: => fixed Comment: Fixed. There were a series of tweaks necessary to get this fully cleaned up: {{{ Thu May 28 06:33:57 PDT 2009 Simon Marlow * Fix #3156: ensure preconditions of splitLargeBlock() Thu May 28 06:34:40 PDT 2009 Simon Marlow * Round stack size to a whole number of megablocks Fri May 29 02:07:58 PDT 2009 Simon Marlow * Fix bug in previous change: allocate the correct size Fri May 29 02:08:27 PDT 2009 Simon Marlow * don't shrink the stack smaller than the value set by +RTS -k }}} These fix a panic in the RTS when using a large `+RTS -k`. I'm not sure we should merge, since there's a good workaround: don't use `+RTS -k` at all (the RTS will grow the stack as necessary). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 07:16:54 2009 From: trac at galois.com (GHC) Date: Fri May 29 07:01:08 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.df7a19d33114d977fbb792a6aff29d27@localhost> #3263: Warnings for monadic values not used ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by NeilMitchell): We don't need to worry about non-returning functions. Remember {{{do ... ; exitWith ...}}} won't be an error, only if they put a statement after it - which is probably an error since you know it won't execute. I don't suggest giving specific errors in specific circumstances, it's not something GHC does in general. For this I would recommend programmers use HLint, and I'll make {{{_ <- mapM}}} be a suggestion there. My guess would be hardcode () and any Monad, as a first step that is very nearly perfect and fairly simple. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 08:01:33 2009 From: trac at galois.com (GHC) Date: Fri May 29 07:45:46 2009 Subject: [GHC] #3264: Real World Haskell book example issue In-Reply-To: <043.62b83c250c57017e61ee880ff79b5d25@localhost> References: <043.62b83c250c57017e61ee880ff79b5d25@localhost> Message-ID: <052.8fb446c4db7710336ba425c64e4e0d09@localhost> #3264: Real World Haskell book example issue -----------------------------------------+---------------------------------- Reporter: oddy | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: panic! | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: duplicate of #2973. Thanks for the report! (and the screenshot!) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 08:04:31 2009 From: trac at galois.com (GHC) Date: Fri May 29 07:48:44 2009 Subject: [GHC] #3098: loadObj: failed In-Reply-To: <047.e5683801e4ce8e212daa73954b5ab839@localhost> References: <047.e5683801e4ce8e212daa73954b5ab839@localhost> Message-ID: <056.e39763e8eb7a64d74daf0eeacbc0dabc@localhost> #3098: loadObj: failed -------------------------------------+-------------------------------------- Reporter: rheineke | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.12.1 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: undefined impossible | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------------+-------------------------------------- Changes (by simonmar): * status: new => closed * component: Compiler => GHCi * resolution: => duplicate Comment: closing as duplicate of #2973, it's been a couple of months since we asked for feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 08:57:56 2009 From: trac at galois.com (GHC) Date: Fri May 29 08:42:08 2009 Subject: [GHC] #3218: Proposal: System.Posix.fdReadBuf/fdWriteBuf In-Reply-To: <047.b7cb1e3962f0323d9c43a62d2f6b6e90@localhost> References: <047.b7cb1e3962f0323d9c43a62d2f6b6e90@localhost> Message-ID: <056.d51e26e8234df61d59377b440c79f7bf@localhost> #3218: Proposal: System.Posix.fdReadBuf/fdWriteBuf ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/unix | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: pushed. {{{ Fri May 29 13:19:41 BST 2009 Simon Marlow * add fdReadBuf, fdWriteBuf Fri May 29 13:56:09 BST 2009 Simon Marlow * add test for fdReadBuf/fdWriteBuf }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 10:21:39 2009 From: trac at galois.com (GHC) Date: Fri May 29 10:05:52 2009 Subject: [GHC] #3189: Exception in canonicalizePath if path has national symbols In-Reply-To: <044.a27e70374e3931f7c0e96425b2a1dbab@localhost> References: <044.a27e70374e3931f7c0e96425b2a1dbab@localhost> Message-ID: <053.751b39f911c9cbbaf55e091225ca4481@localhost> #3189: Exception in canonicalizePath if path has national symbols ------------------------------------+--------------------------------------- Reporter: Tonal | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed. In directory: {{{ Thu May 28 06:57:06 PDT 2009 Simon Marlow * Fix #3189: use System.Win32.getFullPathName }}} and Win32: {{{ Thu May 28 06:56:35 PDT 2009 Simon Marlow * add getFullPathName }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri May 29 10:32:05 2009 From: trac at galois.com (GHC) Date: Fri May 29 10:16:29 2009 Subject: [GHC] #3265: Type operators can be defined without the TypeOperators extension flag Message-ID: <044.bd55a0547092a6d4c7f6613593a50b08@localhost> #3265: Type operators can be defined without the TypeOperators extension flag -----------------------------+---------------------------------------------- Reporter: nibro | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following code is accepted without any extension flags given: {{{ data a :*: b = Foo a b type a :+: b = Either a b }}} However, to use the defined types we need the TypeOperators flag, without it the following code will not be accepted: {{{ f :: Int :*: Int -> Int f (Foo x y) = x+y }}} It seems clear to me that GHC should not accept the former either without the TypeOperators extension enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat May 30 10:49:00 2009 From: trac at galois.com (GHC) Date: Sat May 30 10:33:09 2009 Subject: [GHC] #3266: Segment fault with WxHaskell and GHC 6.10.2 Message-ID: <051.cf64c613e81199a56945f37be31832f5@localhost> #3266: Segment fault with WxHaskell and GHC 6.10.2 -------------------------+-------------------------------------------------- Reporter: mcastellazzi | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: wxhaskell | Testcase: Os: Windows | Architecture: x86 -------------------------+-------------------------------------------------- When i compile this very simple program : module Main where import Graphics.UI.WX main :: IO () main = start gui gui :: IO () gui = do frame [text := "Hello World!"] return () and that I run it with DOS, I get the error : "Segment fault/access violation in generated code" as soon as the mouse passes over the displayed window. When I compile it and run it with GHCI, under Windows, I get the extra informations : Signature du probl?me?: Nom d??v?nement de probl?me: APPCRASH Nom de l?application: ghc.exe Version de l?application: 0.0.0.0 Horodatage de l'application: 49d14878 Nom du module par d?faut: comctl32.dll_unloaded Version du module par d?faut: 0.0.0.0 Horodateur du module par d?faut: 4549bcb0 Code de l?exception: c0000005 D?calage de l?exception: 73828219 Version du syst?me: 6.0.6000.2.0.0.768.3 Identificateur de param?tres r?gionaux: 1036 Information suppl?mentaire n??1: 916f Information suppl?mentaire n??2: 5a80fd0e43273a8de02792153de3009a Information suppl?mentaire n??3: 3cbc Information suppl?mentaire n??4: a7ba763d72dae8d739732c4202cd60ca I get the same error with almost all the demo programs delivered with WxHaskell. I have Windows Vista, GHC 6.10.2, wxHaskell 0.11.1.2 et WxWidgets 2.8.9. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 31 12:01:50 2009 From: trac at galois.com (GHC) Date: Sun May 31 11:45:58 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.c6ba2208097ca27423a66449b2971c6b@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: gwern0@gmail.com (added) Comment: I second Bulat's comment. This is *very* important for long-running servers. Consider the Gitit wiki server. There are a few pages like 'Recent changes' which get the entire revision history; each time this happens, the memory usage goes up a bit - even though even last bit of the history will get discarded once the page has been constructed and sent off to the client. (We've checked for memory leaks.) This is especially problematic when Gitit is being used, surprisingly enough, as a web host, since typically this is done on virtualized slices or is otherwise resource-constrained. It looks bad for wiki.darcs.net that an idling gitit takes 31% of RAM. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun May 31 15:44:25 2009 From: trac at galois.com (GHC) Date: Sun May 31 15:28:36 2009 Subject: [GHC] #3267: hasktags ctags output enhancement Message-ID: <055.117b0d5ee2131e5ce270f52b6af3f005@localhost> #3267: hasktags ctags output enhancement -----------------------------+---------------------------------------------- Reporter: vincent.berthoux | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.10.2 | Severity: normal Keywords: hasktags | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Modified version of hasktags which handle : - output redirection (-o option), and can print on stdout. - Adding extended information on ctags using the -x option. A switch was added to avoid getting a breaking change -- Ticket URL: GHC The Glasgow Haskell Compiler