From trac at galois.com Thu Mar 1 00:05:23 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1184: Hasktags misses symbol In-Reply-To: <071.cd49219457461831e734204dc9199647@localhost> References: <071.cd49219457461831e734204dc9199647@localhost> Message-ID: <080.fdd4a68b87c0cd275d9e32a6e6827238@localhost> #1184: Hasktags misses symbol ---------------------+------------------------------------------------------ Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Comment (by newsham@lava.net): should be "grep boolM tags". Also backticks around the "find .. grep" clause which are being interpretted as wiki formatting I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 06:49:18 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1176: Infinite loop when printing error message In-Reply-To: <071.292b4275ce2906adf2166d790d602cf3@localhost> References: <071.292b4275ce2906adf2166d790d602cf3@localhost> Message-ID: <080.8fa1dfd7272b455eda36052919605e5e@localhost> #1176: Infinite loop when printing error message ---------------------------------------+------------------------------------ Reporter: Paul_Berry@alumni.hmc.edu | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail177 | Architecture: Multiple Os: Multiple | ---------------------------------------+------------------------------------ Changes (by simonpj): * milestone: => _|_ * priority: normal => low * testcase: => tcfail177 Comment: This is a bug in the pretty-printer. Here's a much smaller program that demonstrates the problem: {{{ module Foo5 where -- The more infix ops we have, the worse fsep works allTests :: Bool allTests :: Bool allTests = foo [a ~?= b ,"Three" ~?= "3" ,"Four" ~?= "4" ,"Five" ~?= "5" ,"Five" ~?= "5" ,"Five" ~?= "5" ,"Two", "Two", "Two" ,"Two", "Two", "Two" ,"Two", "Two", "Two" ,"Two", "Two", "Two" ,"Two", "Two", "Two" ,"Two", "Two", "Two"] a="" b="" (~?=) :: a -> a -> Bool (~?=) = error "urk" foo :: a -> Int foo x = 0 }}} This gives the message: {{{ Foo5.hs:15:12: Couldn't match expected type `Bool' against inferred type `[Char]' In the expression: "Two" In the first argument of `foo', namely `[a ~?= b, "Three" ~?= "3", "Four" ~?= "4", "Five" ~?= "5", "Five" ~?= "5", "Five" ~?= "5", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two"]' In the expression: foo [a ~?= b, "Three" ~?= "3", "Four" ~?= "4", "Five" ~?= "5", "Five" ~?= "5", "Five" ~?= "5", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two", "Two"] }}} Notice the way that the layout is wrong: the lines are not indented enough. If you add one more line containing the infix operator, the infinite loop happens. What is happening is that when the indent goes negative, the space generator goes wild. I've fixed that that, so it'll put zero spaces in when the indent is negative. But there's still a problem: the indent should not be going negative. The pretty-printing library could really do with someone looking at it carefully. We already have an open bug on that: #669, so I'm going to leave this one open because GHC's Pretty module isn't the same as the `Text.PrettyPrint.HughesPJ` module. So infinite loop is fixed, but the bad formatting remains. I've added a test, tcfail177. Please merge the fix the STABLE 6.6 branch: {{{ Thu Mar 1 11:45:13 GMT 2007 simonpj@microsoft.com * Do not go into an infinite loop when pretty-printer finds a negative indent (Trac #1176) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 06:49:27 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #669: negative indentation in Text.PrettyPrint.HughesPJ In-Reply-To: <071.ed380d6fa3fbf0f091e4a61b8ced6e1c@localhost> References: <071.ed380d6fa3fbf0f091e4a61b8ced6e1c@localhost> Message-ID: <080.836ec316301c99b6b018e32de5a788df@localhost> #669: negative indentation in Text.PrettyPrint.HughesPJ ------------------------------------------+--------------------------------- Reporter: waldmann@imn.htwk-leipzig.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: hslibs/text | Version: 6.4.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Comment (by simonpj): See #1176 for another example of negative indentation happening in GHC's version of this library. It would be great if someone would fix this libarary! And when they do, propagate the fixes to GHC's Pretty module. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 09:17:12 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #249: -caf-all bugs In-Reply-To: <071.5046e0b17da2ba00a01db26defcc7943@localhost> References: <071.5046e0b17da2ba00a01db26defcc7943@localhost> Message-ID: <080.66c4bc66c7be9925d82343beb9b8a9d8@localhost> #249: -caf-all bugs -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: low | Milestone: 6.6.1 Component: Profiling | Version: 6.2.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: prof001 prof002 | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * resolution: None => fixed * status: new => closed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 09:17:49 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #839: Generate documentation for built-in types and primitve operations In-Reply-To: <071.a75c0fc5b7a3538cdbb7b6394987f5d5@localhost> References: <071.a75c0fc5b7a3538cdbb7b6394987f5d5@localhost> Message-ID: <080.69a71e5ad1843dd7e3800792ec40fbba@localhost> #839: Generate documentation for built-in types and primitve operations ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Documentation | Version: 6.4.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 09:19:08 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1176: Infinite loop when printing error message In-Reply-To: <071.292b4275ce2906adf2166d790d602cf3@localhost> References: <071.292b4275ce2906adf2166d790d602cf3@localhost> Message-ID: <080.3088188b35610b21d414fd404f89af31@localhost> #1176: Infinite loop when printing error message ---------------------------------------+------------------------------------ Reporter: Paul_Berry@alumni.hmc.edu | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail177 | Architecture: Multiple Os: Multiple | ---------------------------------------+------------------------------------ Comment (by igloo): I've merged the fix, but I'm going to leave the bug open as the underlying problem isn't fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 10:15:20 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded Message-ID: <071.3864d1ecc1af6a242118b8466ac6af5a@localhost> #1185: can't do I/O in the child of forkProcess with -threaded -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.6 Severity: minor | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- `forkProcess` kills all threads, as advertised. Unfortunately this includes the I/O manager thread, so trying to do I/O in the child of `forkProcess` leads to deadlock. It might be possible to fix this, but we'd need to add a way to restart the I/O manager thread. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 10:15:34 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <071.3864d1ecc1af6a242118b8466ac6af5a@localhost> References: <071.3864d1ecc1af6a242118b8466ac6af5a@localhost> Message-ID: <080.441e7127a9d68e69f10ed9a216200df7@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Runtime System | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 10:36:36 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1156: usleep hangs indefinitely when using -threaded In-Reply-To: <071.9ff5afed3239f3f405e1af7ce27d97f9@localhost> References: <071.9ff5afed3239f3f405e1af7ce27d97f9@localhost> Message-ID: <080.d64dac49b429e3e4cc23fdfbfb03f3c3@localhost> #1156: usleep hangs indefinitely when using -threaded ------------------------------------+--------------------------------------- Reporter: Eelis | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.2 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: duplicate Keywords: usleep threaded unistd | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ------------------------------------+--------------------------------------- Changes (by Eelis): * resolution: => duplicate * component: Compiler => Runtime System * status: new => closed Comment: This problem is actually one of the listed symptoms of the problem described in ticket #850 (which I personally feel deserves a higher priority than "low", considering that it renders perfectly ordinary system functions utterly unusable in the threaded RTS). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 11:24:12 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #850: threaded RTS uses SIGALRM In-Reply-To: <071.bb9bf74d8e50823a041ca95b96a3100f@localhost> References: <071.bb9bf74d8e50823a041ca95b96a3100f@localhost> Message-ID: <080.54331e0b4506bd05439003597a5fd8f0@localhost> #850: threaded RTS uses SIGALRM ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: low => normal Comment: Upping priority, as requested by Eelis in #1156 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 11:36:30 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1093: Windows: haddock-html fields are wrong in package.conf In-Reply-To: <071.2b38f0c5951af294941b4c35ebd3730e@localhost> References: <071.2b38f0c5951af294941b4c35ebd3730e@localhost> Message-ID: <080.b1dae75ca8cb5da9787988c9c2668e63@localhost> #1093: Windows: haddock-html fields are wrong in package.conf --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Build System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Windows | --------------------------+------------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 18:46:52 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #970: GHCi crashes under Windows Millenium In-Reply-To: <071.15ead1d6a5d48a914177fac9163f1fc7@localhost> References: <071.15ead1d6a5d48a914177fac9163f1fc7@localhost> Message-ID: <080.d466dbf6c61da20bc0f80ad17a91f41f@localhost> #970: GHCi crashes under Windows Millenium --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: GHCi | Version: 6.6 Severity: normal | Resolution: fixed Keywords: Windows GHCi | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------+------------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Sigbjorn has confirmed that the changes have been committed, and it sounds like they work for everyone. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 1 18:46:59 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #976: GHCi crashes on Windows 98 In-Reply-To: <071.1be6bed09433b8966834b565845026a7@localhost> References: <071.1be6bed09433b8966834b565845026a7@localhost> Message-ID: <080.5b6f22e1e2b5b40412428e77301c6c93@localhost> #976: GHCi crashes on Windows 98 ------------------------------+--------------------------------------------- Reporter: cwxdev@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: GHCi | Version: 6.6 Severity: normal | Resolution: fixed Keywords: windows 98 ghci | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Sigbjorn has confirmed that the changes have been committed, and it sounds like they work for everyone. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 2 03:42:10 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #850: threaded RTS uses SIGALRM In-Reply-To: <071.bb9bf74d8e50823a041ca95b96a3100f@localhost> References: <071.bb9bf74d8e50823a041ca95b96a3100f@localhost> Message-ID: <080.c92f0cd8c690a3cabdfec8767b52b458@localhost> #850: threaded RTS uses SIGALRM ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'm looking at this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 2 05:58:10 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1186: GHC as a library panic on loading second module Message-ID: <071.c729b729fb656db3b094dc59987ef601@localhost> #1186: GHC as a library panic on loading second module ---------------------------------+------------------------------------------ Reporter: ArthurVanLeeuwen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: powerpc | Os: Unknown ---------------------------------+------------------------------------------ Given the following two modules: {{{ module GHCLibTest where import GHC import PackageConfig import DynFlags main = do session <- newSession JustTypecheck (Just "/usr/local/lib/ghc-6.6") f <- getSessionDynFlags session f' <- parseDynamicFlags f ["-isrc","-ilib","-ilib/DData ","-fglasgow-ex ts","-package wx"] setSessionDynFlags session (fst f'){hscTarget = HscInterpreted} let preludeModule = mkModule (stringToPackageId "base") (mkModuleName "Prelude") setContext session [] [preludeModule] t <- guessTarget "src/Main.hs" Nothing addTarget session t load session LoadAllTargets }}} and {{{ module OtherModule where import Data.List type Nummer = String data Beademing = HFO | CPAP | IPPV | Geen deriving (Show, Read, Eq) data Bloeddruk = Hypertensie | Hypotensie | TensieNormaal deriving (Show, Read, Eq) data Partus = PartusTeVroeg | PartusNormaal deriving (Show, Read, Eq) }}} the following results: {{{ harlan:~/Werk/dss/software/ghclib arthurvl$ echo "main" | ghci -package ghc ghclibtest.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package Cabal-1.1.6 ... linking ... done. Loading package regex-base-0.71 ... linking ... done. Loading package regex-posix-0.71 ... linking ... done. Loading package regex-compat-0.71 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package ghc-6.6 ... linking ... done. [1 of 2] Compiling OtherModule ( OtherModule.hs, interpreted ) [2 of 2] Compiling GHCLibTest ( ghclibtest.hs, interpreted ) Ok, modules loaded: OtherModule, GHCLibTest. *GHCLibTest> ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for powerpc-apple-darwin): lookup_dfun main:OtherModule.$f1{v r5ig} [lid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *GHCLibTest> Leaving GHCi. harlan:~/Werk/dss/software/ghclib arthurvl$ }}} This does not just occur for this recursive case, but also for cases where the main module is from some completely different program. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 2 07:37:04 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics In-Reply-To: <071.72f02e9ed7b048544184dc7ac1d149d0@localhost> References: <071.72f02e9ed7b048544184dc7ac1d149d0@localhost> Message-ID: <080.9216fd0dfa66f19895894849bf3ba5fd@localhost> #1171: GHC doesn't respect the imprecise exceptions semantics ----------------------+----------------------------------------------------- Reporter: neil | Owner: Type: bug | Status: reopened Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: cg059 | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Comment (by igloo): The below is from e-mail and IRC conversations that happened in parallel with this bug report. I've editted things slightly to make them flow better, but hopefully haven't changed any important meanings. ---- __I said:``__ In http://research.microsoft.com/~simonpj/Papers/imprecise-exn.htm I think you claim in section 4.3, in the rationale for the Bad case, that if we have {{{ f x = case x of True -> error "A" False -> error "B" }}} then the call {{{ f (error "X") }}} is allowed to raise B, as this permits transformations like {{{ f' x = let b = error "B" in b `seq` case x of True -> error "A" False -> b }}} which in turn is justified because the case expression is strict in {{{ error "B" }}} (as well as every other expression). However, the Ok case tells me that if I call {{{ f True }}} then I can get the errors raised by the {{{ True -> error "A" }}} branch only. Thus it must raise A. But with the above transformation f' raises B. I also think that this behaviour is very confusing to users; it makes sense that {{{ error "A" + error "B" }}} needs to evaluate both values, so throwing either exception is reasonable, but in {{{ f True }}} it is "obvious" that A is raised and B is not! Traditionally, we would say that e is strict in x if {{{ x = _|_ => e = _|_ }}} However, with the set-based imprecise exceptions, in which we distinguish between different bottoms, it seems to me that a better definition would be that e is strict in x if {{{ x = Bad xs => e = Bad ys and xs \subseteq ys }}} Thus, for example, a case can throw an exception if either the scrutinee can or /all/ the branches can, i.e. in the Bad case in 4.3 we take the big intersection rather than big union. So we wouldn't be allowed to pull {{{ error "B" }}} out of the above case, but we would still be able to translate {{{ case x of True -> y False -> y }}} into {{{ y `seq` case x of True -> y False -> y }}} I am also unconvinced by a non-terminating program being allowed to throw anything it likes. It seems much nicer to permit it only to either not terminate or to throw a special exception, here-on written N. I haven't written a denotational semantics or anything, so perhaps this would all unravel if I tried, but here are some example definitions followed by what exceptions I think various expressions ought to be able to throw; are there any obvious nasty corners I have left unexplored?: {{{ f x = case x of True -> error "A" False -> error "B" g x = case x of True -> error "C" False -> error "C" h () () = () i = i j = error "D" + j ----- f True A f (error "E") E g True C g (error "F") C or F h (error "G") (error "H") G or H i N or non-termination j D, N or non-termination }}} I also haven't looked into the performance implications, although personally I'd prefer a semantics that is more intuitive along with a few more bang patterns sprinkled around. ---- __Simon PJ replied:``__ I think you are basically right here. Another way to say it is this. In 4.5 we claim that GHC's transformations can reduce the set of possible exceptions from a term, but not increase it. But the (current) strictness analysis transformation increases it. I agree that is undesirable. As I say on the Trac, we could change this at the cost of making fewer functions strict. I can tell anyone how to do this, if you want. It would be good to measure the performance impact of doing so. ---- __Simon M__ has a memory that there is some problem, possibly related to monotonicity, with only allowing non-terminating programs to either not terminate or throw a special non-termination error, rather than allowing them to behave like any bottom they wish as the imprecise exceptions paper allows them to. However, he can't remember what the problem actually is; if anyone can then it would be good to have it documented. ---- Regarding __Simon PJ__``'s earlier comment {{{ It's easily stopped, too, by stopping GHC treating error like bottom; but that would make many functions less strict. It'd be interesting to measure the performance impact of this. }}} __Simon M replied:``__ It would be a shame if error wasn't treated as _|_, because that would lose the opportunity to transform {{{ Case error "foo" of alts ===> error "foo" }}} wouldn't it? This is only dead code elimination of course. and __Simon PJ followed up with:``__ You are right that the strictness of an Id would have to distinguish: * normal * diverges (bottom) * crashes (calls error) Currently it does not. Changing the strictness analyser to make 'error' look like 'normal' rather than 'diverges' would indeed have the effect of making GHC not realise that (error "x") was a case scrutinee that could be simplified. So yes, there is a bit more to testing the effect of making 'error' less strict than I was suggesting. Quite doable, but more than a moment's work. ---- Regarding my strictness test {{{ x = Bad xs => e = Bad ys and xs \subseteq ys }}} __Simon M__ suggested that an implementation might: invent a magic exception X only used by the strictness analyser, and treat this as {{{ x = Bad X => e = Bad ys and X `elem` ys }}} All other exceptions (and _|_) can be mapped to the same thing; all that matters is whether x's exception was raised or not. I imagine you'd need to fiddle around with the strictness analyser's domain. ---- The sort of case where Simon PJ is worried we will lose performance is {{{ f x [] = error "Can't happen" f x (y:ys) = ... strict in x ... }}} where we would no longer be allowed to claim to be strict in x, as {{{ f (error "X") [] }}} should only throw "Can't happen". Debatably it's better to tell the compiler explicitly that you want it to be strict in x with {{{ f !x [] = error "Can't happen" f !x (y:ys) = ... strict in x ... }}} anyway, rather than relying on the strictness analyser to figure it out. ---- Finally, I am not entirely convinced by the semantics of imprecise exceptions as given in the paper; they tend allow too many exceptions to be thrown, possibly under the assumption no compiler would actually transform a program in such a way that the unexpected exceptions actually would be thrown. For example {{{ (error "A") (error "B") }}} is permitted to throw B, even though {{{ error "B" }}} would never be evaluated under non-strict evaluation. Similarly, {{{ case error "A" of True -> error "B" False -> 'x' }}} is allowed to throw B. Incidentally, I do think it is reasonable for {{{ case error "A" of True -> error "B" False -> error "B" }}} to throw B. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 2 08:39:32 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1093: Windows: haddock-html fields are wrong in package.conf In-Reply-To: <071.2b38f0c5951af294941b4c35ebd3730e@localhost> References: <071.2b38f0c5951af294941b4c35ebd3730e@localhost> Message-ID: <080.c6730ad1aac50c332247ff4d921c2889@localhost> #1093: Windows: haddock-html fields are wrong in package.conf --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Build System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Windows | --------------------------+------------------------------------------------- Comment (by igloo): I can't reproduce the problem - everything seems to not use doc/ in both the 6.6 branch and the HEAD. However, there are a couple of issues outstanding. Here base was built as part of the GHC build process while mtl was built with cabal; note the varying number of '\'s and quotes in one case only: {{{ $ ~/ghc/darcs/build/inst/bin/ghc-pkg field base haddock-html haddock-html: C:/cygwin/home/ian/ghc/darcs/build/inst\html\libraries\base $ ~/ghc/darcs/build/inst/bin/ghc-pkg field mtl haddock-html haddock-html: "C:\\Program Files\\Common Files\\mtl-1.0\\doc\\html" }}} Trying to `./Setup haddock` a package that uses mtl gives {{{ Warning: cannot use package mtl-1.0: HTML directory "C:\\Program Files\\Common Files\\mtl-1.0\\doc\\html" does not exist. }}} but {{{ $ ls 'c:\Program Files\Common Files\mtl-1.0\doc\html\' Control-Monad-Cont.html Control-Monad-State.html haskell_icon.gif ... }}} I'm not sure why the docs are going there at all, given I gave cabal a prefix when configuring. Finally, just a note that a darcs version of haddock is necessary as 0.8 doesn't strip line endings correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 2 08:53:36 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #850: threaded RTS uses SIGALRM In-Reply-To: <071.bb9bf74d8e50823a041ca95b96a3100f@localhost> References: <071.bb9bf74d8e50823a041ca95b96a3100f@localhost> Message-ID: <080.e9cc2459bfebd0ebc5817329d24ad3ad@localhost> #850: threaded RTS uses SIGALRM ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.4.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * resolution: => fixed * status: new => closed Comment: The problem with `usleep()` is that it stops with `EINTR` whenever a signal is received, and there's no way to restart it because it doesn't let you know how much of the original time has expired. The right way these days is to use `nanosleep()`, so I've added support for that to the unix package: {{{ Fri Mar 2 11:41:18 GMT 2007 Simon Marlow * don't retry usleep() on EINTR (see #850/#1156) Fri Mar 2 13:28:18 GMT 2007 Simon Marlow * Provide nanosleep if we have it, and use it to implement usleep Fixes #1156 }}} The SIGALRM question is really orthogonal: `usleep` will be interrupted by whatever signal we use. However, I've modified the RTS to use `timer_create()` instead of `setitimer()` and therefore we now use `SIGVTALRM` for timer signals on both the threaded and non-threaded RTSs: {{{ Fri Mar 2 03:31:04 PST 2007 Simon Marlow * Use timer_create() for the interval timer, if available }}} I'll do the appropriate merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 2 09:18:40 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1093: Windows: haddock-html fields are wrong in package.conf In-Reply-To: <071.2b38f0c5951af294941b4c35ebd3730e@localhost> References: <071.2b38f0c5951af294941b4c35ebd3730e@localhost> Message-ID: <080.2f74af4c6cbc3f6c80043c89ef7c811b@localhost> #1093: Windows: haddock-html fields are wrong in package.conf --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Build System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Windows | --------------------------+------------------------------------------------- Comment (by simonmar): I suspect Sigbjorn rearranges the files in the distribution. If that's correct, then the `haddock-html` fields also need to be modified. I don't know about the backslash vs. fwdslash issues, but I do know why your docs are ending up in `C:/Program Files/Common Files/...`: http://www.haskell.org/ghc/docs/latest/html/Cabal/builders.html#setup- configure-paths Currently docs are installed under `$datadir`, which on Windows defaults to an absolute location obtained by querying the OS. Seems to me it would be better to make this relative to `$prefix`, I think it was Neil Mitchell who suggested the current scheme. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 2 11:47:45 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1186: GHC as a library panic on loading second module In-Reply-To: <071.c729b729fb656db3b094dc59987ef601@localhost> References: <071.c729b729fb656db3b094dc59987ef601@localhost> Message-ID: <080.8ca04cd76a9eb0798003ed5a1b03b2a5@localhost> #1186: GHC as a library panic on loading second module ------------------------------+--------------------------------------------- Reporter: ArthurVanLeeuwen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: Unknown | ------------------------------+--------------------------------------------- Comment (by thorkilnaur): I have tried this on a PPC Mac OS X 10.4 and got: {{{ Thorkil-Naurs-Computer:~/tn/test/GHC/trac/1186/work thorkilnaur$ diff ghclibtest.hs ../original/ghclibtest.hs 7c7 < main = do session <- newSession JustTypecheck (Just "/Users/thorkilnaur/tn/install/ghc-6.6-for-buildbot- 20070221_1000/lib/ghc-6.6.20070220") --- > main = do session <- newSession JustTypecheck (Just "/usr/local/lib/ghc-6.6") Thorkil-Naurs-Computer:~/tn/test/GHC/trac/1186/work thorkilnaur$ echo main | ghci -package ghc ghclibtest.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.20070220, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package Cabal-1.1.6 ... linking ... done. Loading package regex-base-0.71 ... linking ... done. Loading package regex-posix-0.71 ... linking ... done. Loading package regex-compat-0.71 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package ghc-6.6.20070220 ... linking ... done. [1 of 1] Compiling GHCLibTest ( ghclibtest.hs, interpreted ) Ok, modules loaded: GHCLibTest. *GHCLibTest> unknown package: wx *GHCLibTest> Leaving GHCi. Thorkil-Naurs-Computer:~/tn/test/GHC/trac/1186/work thorkilnaur$ }}} I am wondering: Where, in your case, is the !OtherModule referenced? I cannot seem to find any reference to it in ghclibtest.hs. Please supply some additional details. Thanks and regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 2 17:58:27 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1187: GHC.Conc.prodServiceThread can deadlock Message-ID: <071.39595794168aedcbe4357e163ec9fa33@localhost> #1187: GHC.Conc.prodServiceThread can deadlock -------------------------------+-------------------------------------------- Reporter: ms43 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.6 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Multiple | Os: Multiple -------------------------------+-------------------------------------------- i am using GHC 6.6 from darcs (checked out on 2007-02-18). there is a race condition in GHC.Conc.prodServiceThread: if an async exception arrives between taking the MVar prodding and putting the value back, the MVar will be left empty. in this case, any further calls to e.g. threadDelay will try to take the empty MVar and deadlock. this can only happen on -threaded with at least -N2. this results in stack traces like this (all threads look like this up to frame 4): {{{ Thread 3 (Thread 16386 (LWP 6185)): #0 0x400a7604 in __pthread_sigsuspend () from /lib/libpthread.so.0 #1 0x400a73c8 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x400a3f2b in pthread_cond_wait@GLIBC_2.0 () from /lib/libpthread.so.0 #3 0x080da958 in waitCondition (pCond=0xfffffffc, pMut=0xfffffffc) at posix/OSThreads.c:65 #4 0x080e3fe4 in yieldCapability (pCap=0xbf7ffa9c, task=0x811ee80) at Capability.c:498 #5 0x080d5615 in schedule (initialCapability=0x8116d2c, task=0x811ee80) at Schedule.c:365 #6 0x080d6646 in workerStart (task=0x811ee80) at Schedule.c:2660 }}} here is a patch which should fix the race condition. well, at least i could no longer reproduce it, so it might actually be correct :) (note that i have not tested on win32) {{{ --- ghc/libraries/base/GHC/Conc.lhs 2007-02-18 22:45:27.000000000 +0100 +++ /home/ms/stuff/ghc/libraries/base/GHC/Conc.lhs 2007-02-28 00:55:11.000000000 +0100 @@ -100,7 +101,8 @@ #ifndef mingw32_HOST_OS import GHC.Base ( Int(..) ) #endif -import GHC.Exception ( catchException, Exception(..), AsyncException(..) ) +import GHC.Exception ( catchException, Exception(..), AsyncException(..), + block ) import GHC.Pack ( packCString# ) import GHC.Ptr ( Ptr(..), plusPtr, FunPtr(..) ) import GHC.STRef @@ -773,13 +788,16 @@ prodding = unsafePerformIO (newMVar False) prodServiceThread :: IO () -prodServiceThread = do +prodServiceThread = block $ do b <- takeMVar prodding - if (not b) - then do hdl <- readIORef stick - c_sendIOManagerEvent io_MANAGER_WAKEUP - else return () - putMVar prodding True + catchException (do + if (not b) + then do hdl <- readIORef stick + c_sendIOManagerEvent io_MANAGER_WAKEUP + else return () + putMVar prodding True) + (\e -> do putMVar prodding True + throw e) -- Walk the queue of pending delays, waking up any that have passed -- and return the smallest delay to wait for. The queue of pending @@ -932,14 +950,17 @@ prodding = unsafePerformIO (newMVar False) prodServiceThread :: IO () -prodServiceThread = do +prodServiceThread = block $ do b <- takeMVar prodding - if (not b) - then do fd <- readIORef stick - with io_MANAGER_WAKEUP $ \pbuf -> do - c_write (fromIntegral fd) pbuf 1; return () - else return () - putMVar prodding True + catchException (do + if (not b) + then do fd <- readIORef stick + with io_MANAGER_WAKEUP $ \pbuf -> do + c_write (fromIntegral fd) pbuf 1; return () + else return () + putMVar prodding True) + (\e -> do putMVar prodding True + throw e) foreign import ccall "&signal_handlers" handlers :: Ptr (Ptr (StablePtr (IO ()))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 2 18:02:06 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1188: STM.c:stmCommitNestedTransaction bogosity Message-ID: <071.ad62bfb8b52ac71bd8f0deb97b7e4dfd@localhost> #1188: STM.c:stmCommitNestedTransaction bogosity -------------------------------+-------------------------------------------- Reporter: ms43 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.6 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Multiple | Os: Multiple -------------------------------+-------------------------------------------- there is a superfluous if (result) in stmCommitNestedTransaction in STM.c. as a consequence, if check_read_only returns non-zero, revert_ownership will not be called, which means that when the transaction is restarted and reads a variable, that TVar will still be locked by the previous attempt, resulting in an infinite loop in readTVar. here is a patch (against ghc 6.6 darcs checked out on 2007-02-18). {{{ --- /home/ms/www/ghc/rts/STM.c 2007-02-18 19:52:42.000000000 +0100 +++ ./STM.c 2007-03-02 23:27:53.000000000 +0100 @@ -1013,7 +1013,6 @@ // at the end of the call to validate_and_acquire_ownership. This forms the // linearization point of the commit. - if (result) { TRACE("%p : read-check succeeded\n", trec); FOR_EACH_ENTRY(trec, e, { // Merge each entry into the enclosing transaction record, release all @@ -1027,9 +1026,8 @@ merge_update_into(cap, et, s, e -> expected_value, e -> new_value); ACQ_ASSERT(s -> current_value != (StgClosure *)trec); }); - } else { + } else { revert_ownership(trec, FALSE); - } } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 2 20:07:28 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1164: building ghc-6.7.20070221 failed on debian etch In-Reply-To: <071.7f9a1af1c8e101f19ec3abe8c7f8ce74@localhost> References: <071.7f9a1af1c8e101f19ec3abe8c7f8ce74@localhost> Message-ID: <080.703c00bc9cbd0b52dd8754a33ac10777@localhost> #1164: building ghc-6.7.20070221 failed on debian etch ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by guest): * resolution: => fixed * status: new => closed Comment: It works now (20070303) on debian etch amd64. Cheers, thorat -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 3 02:26:17 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #345: GADT - fundep interaction In-Reply-To: <071.bfc72a05ca553409f36f771922e06c54@localhost> References: <071.bfc72a05ca553409f36f771922e06c54@localhost> Message-ID: <080.a0553aac0956e6d41d951b6ac8999f6e@localhost> #345: GADT - fundep interaction -------------------------------------+-------------------------------------- Reporter: bring | Owner: simonpj Type: bug | Status: assigned Priority: normal | Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.4 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: gadt-fd | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by jyrinx): GHC doesn't even like the first clause nowadays. Sez version 6.7.20070224: {{{ Couldn't match expected type `z' (a rigid variable) against inferred type `y' (a rigid variable) `z' is bound by the type signature for `append' at Bug345.hs:16:19 `y' is bound by the type signature for `append' at Bug345.hs:16:17 Expected type: List a z Inferred type: List a y In the expression: ys In the definition of `append': append Nil ys = ys }}} (I did have to compile with -fallow-undecidable-instances, though.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 3 09:54:49 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1126: Add Data.String, containing IsString(fromString), to base In-Reply-To: <071.29007d5604190f211a89e53cd10ec1db@localhost> References: <071.29007d5604190f211a89e53cd10ec1db@localhost> Message-ID: <080.965d47733c35296eb8f26d0aed714e74@localhost> #1126: Add Data.String, containing IsString(fromString), to base ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: David Roundy proposed adding Eq as a requirement for the IsString class so pattern matching wouldn't need an Eq constraint, but Lennart Augustsson pointed out that you may wish to use IsString types for which Eq cannot be (usefully) defined, such as an AST type he has. Neil Mitchell asked about adding a toString function to the class. Lennart Augustsson pointed out that Num has fromInteger but not toInteger. Presumably toString too could not be usefully defined for his AST type. Applied: {{{ * Add Data.String, containing IsString(fromString); trac proposal #1126 This is used by the overloaded strings extension (-foverloaded-strings in GHC). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 3 10:35:26 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1127: Make mtl lazier In-Reply-To: <071.9c174927b6b4a9ca312758e41cd98227@localhost> References: <071.9c174927b6b4a9ca312758e41cd98227@localhost> Message-ID: <080.8e375a7e61ffc4352a3daf3a811a6d7e@localhost> #1127: Make mtl lazier -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: While this started off as just making StateT lazy, it has ultimately ended up as a much larger rejig of the mtl library. The patch description is: {{{ Sat Mar 3 15:22:21 GMT 2007 Ian Lynagh * Rejig mtl; trac proposal #1127 Moved the MonadFoo classes to Control.Monad.Foo.Class. Put the instances consistently in the module which defines the type they give an instance for. Made the existing transformers lazy to match the existing monads, and put them in Control.Monad.Foo.Lazy. Also added Control.Monad.Foo.Strict with strict monads and transformers. Control.Monad.Foo still exports what it used to. Created a MonadRWS class. Made the MonadWriter w (ErrorT e m) instance strict to match everything else. }}} Neil Mitchell advocated State and State' rather than State.Lazy and State.Strict but there seemed to be a concensus for the latter (also used by some modules in the base package). Don Stewart asked for an example showing the different behaviours, to which I replied: {{{ The attached without the ~ gives: $ time ./p 1000000 Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. ./p 1000000 1.96s user 0.05s system 96% cpu 2.095 total whereas with the ~ you can pump up the argument as high as you like without any runtime or stack use worries: $ time ./p 1000000 'a' ./p 1000000 0.00s user 0.00s system 93% cpu 0.004 total $ time ./p 1000000000 'a' ./p 1000000000 0.00s user 0.00s system 101% cpu 0.004 total For a non-contrived example see the compression package in hackage. }}} with this program attached: {{{ import Control.Monad.Identity import Control.Monad.State import System.Environment type M = StateT Char Identity main = do [x] <- getArgs print $ head $ runIdentity $ evalStateT (f $ read x) 'a' f :: Int -> M [Char] f 0 = return [] f (n+1) = do st <- get rest <- f n return (st:rest) }}} Should you wish to see the whole thread, it begins with http://www.haskell.org/pipermail/libraries/2007-January/006805.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 4 03:59:10 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1189: Add First and Last wrappers around Maybe to Data.Monoid Message-ID: <071.85cdf44fe1e63d086232ad186640e967@localhost> #1189: Add First and Last wrappers around Maybe to Data.Monoid -------------------------------+-------------------------------------------- Reporter: jyasskin | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- First and Last `mappend` to the first and last non-Nothing elements of the input. These instances seem to fit with the other simple instances in this file and are useful, for example, to turn foldMap into findFirst or findLast, or to get a really trivial Writer monad. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 4 07:25:41 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1190: base:System.Posix.Signals is empty on Windows Message-ID: <071.5d663bc584bb71d515b51069ce7dc464@localhost> #1190: base:System.Posix.Signals is empty on Windows -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- From http://www.haskell.org/pipermail/libraries/2006-August/005762.html: __Neil Mitchell:``__ Why is System.Posix.Signals defined in base on Windows, but entirely blank, while System.Posix.Process is defined in Unix? If this is a dependancy issue, then shouldn't System.Posix.Internals.Signals be in the base, and then unix export System.Posix.Signals, which is just a reexport of this? This issue is annoying because I'm trying to at least write null stubs for the functions so I can compile a program requiring unix on Windows. It doesn't help that Windows ships a version of Signals with an entirely different interface... __Simon Marlow:``__ Good point. I think this is mostly historical, System.Posix.Signals is required to bootstrap GHC, which is why it was originally in base (I think at one stage we bootstrapped using only base+haskell98). It's too late to sort this out for GHC 6.6, but we'll do something about it after the release. (feel free to submit a patch if you get to it before us). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 4 08:07:09 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1191: Proposal: Add ioeGetLocation, ioeSetLocation to System/IO/Error.hs Message-ID: <071.fc1f7c600c4892b14cf50767966e334e@localhost> #1191: Proposal: Add ioeGetLocation, ioeSetLocation to System/IO/Error.hs -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- This is a proposal to add ioeGetLocation and ioeSetLocation to System/IO/Error.hs. The functions are visible only to GHC and hugs; nhc is already missing some of this family of functions. Deadline: About a week after discussion stops. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 4 08:22:45 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1192: GHC-only IOErrorType constructors, and is*Error(Type) functions Message-ID: <071.83b307571e5c4a34330393102b492d48@localhost> #1192: GHC-only IOErrorType constructors, and is*Error(Type) functions --------------------------------+------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: minor | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Currently we don't have `is*Error` and `is*ErrorType` functions for those constructors of `IOErrorType` below the `GHC only` comment. It would be nice to add them, but better still to make the constructors known to the other implementations first. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 4 11:46:42 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1193: panic! addImpDecls in TH_dataD1 test Message-ID: <071.08736a8ad9925c5628e9e353d1b89254@localhost> #1193: panic! addImpDecls in TH_dataD1 test ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.2 Component: Template Haskell | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------+------------------------------------------ addImpDecls seems to be being passed an empty group, and the list of decls {{{ [$(dataD [] (mkName "D") [] [normalC "K" []] [])] }}} while it expects {{{ -- The decls are imported, and should not have a splice }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 4 11:47:35 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1193: panic! addImpDecls in TH_dataD1 test In-Reply-To: <071.08736a8ad9925c5628e9e353d1b89254@localhost> References: <071.08736a8ad9925c5628e9e353d1b89254@localhost> Message-ID: <080.31ae94bbdd6b568653e1caaf24ce16d6@localhost> #1193: panic! addImpDecls in TH_dataD1 test ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.2 Component: Template Haskell | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_dataD1 | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * testcase: => TH_dataD1 Old description: > addImpDecls seems to be being passed an empty group, and the list of > decls > {{{ > [$(dataD [] (mkName "D") [] [normalC "K" []] [])] > }}} > while it expects > {{{ > -- The decls are imported, and should not have a splice > }}} New description: When running the test TH_dataD1, addImpDecls seems to be being passed an empty group, and the list of decls {{{ [$(dataD [] (mkName "D") [] [normalC "K" []] [])] }}} while it expects {{{ -- The decls are imported, and should not have a splice }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 4 16:53:05 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1194: tcrun032 regressed Message-ID: <071.f9adba99073f93376233166eb8b80982@localhost> #1194: tcrun032 regressed -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: tcrun032 Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- The tcrun032 test: {{{ {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances #-} -- This tests the recursive-dictionary stuff. -- -- The derived instance needs module Main where data Fix f = In (f (Fix f)) deriving( Show, Eq ) data L x = Nil | Cons Int x deriving (Show, Eq) main = do { print (In Nil); print (In Nil == In Nil) } }}} now fails with: {{{ tcrun032.hs:9:5: No instance for (Show (f (Fix f))) arising from the 'deriving' clause of a data type declaration at tcrun032.hs:9:5 Possible fix: add an instance declaration for (Show (f (Fix f))) When deriving the instance for `Show (Fix f)' tcrun032.hs:9:5: No instance for (Eq (f (Fix f))) arising from the 'deriving' clause of a data type declaration at tcrun032.hs:9:5 Possible fix: add an instance declaration for (Eq (f (Fix f))) When deriving the instance for `Eq (Fix f)' }}} in the 6.6 branch. Both 6.6 and the HEAD work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 05:18:24 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1186: GHC as a library panic on loading second module In-Reply-To: <071.c729b729fb656db3b094dc59987ef601@localhost> References: <071.c729b729fb656db3b094dc59987ef601@localhost> Message-ID: <080.52f01fc46723d95c962d4f8780e9af56@localhost> #1186: GHC as a library panic on loading second module ------------------------------+--------------------------------------------- Reporter: ArthurVanLeeuwen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: Unknown | ------------------------------+--------------------------------------------- Comment (by ArthurVanLeeuwen): Just to check my sanity (the bugreport was an attempted pare-down of the original problem): {{{ harlan:~/Werk/dss/software/ghclib arthurvl$ uname -a Darwin harlan.cs.uu.nl 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc harlan:~/Werk/dss/software/ghclib arthurvl$ echo "setupsession >>= loadsession" | ghci -package ghc ghclibtest.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package Cabal-1.1.6 ... linking ... done. Loading package regex-base-0.71 ... linking ... done. Loading package regex-posix-0.71 ... linking ... done. Loading package regex-compat-0.71 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package ghc-6.6 ... linking ... done. [1 of 2] Compiling OtherModule ( OtherModule.hs, interpreted ) [2 of 2] Compiling GHCLibTest ( ghclibtest.hs, interpreted ) Ok, modules loaded: OtherModule, GHCLibTest. *GHCLibTest> ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for powerpc-apple-darwin): lookup_dfun main:OtherModule.$f1{v r5x8} [lid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *GHCLibTest> Leaving GHCi. harlan:~/Werk/dss/software/ghclib arthurvl$ lsOtherModule.hs ghclibtest.hs harlan:~/Werk/dss/software/ghclib arthurvl$ cat OtherModule.hs module OtherModule where import Data.List type Nummer = String data Beademing = HFO | CPAP | IPPV | Geen deriving (Show, Read, Eq) data Bloeddruk = Hypertensie | Hypotensie | TensieNormaal deriving (Show, Read, Eq) data Partus = PartusTeVroeg | PartusNormaal deriving (Show, Read, Eq) harlan:~/Werk/dss/software/ghclib arthurvl$ cat ghclibtest.hs module GHCLibTest (setupsession,loadsession) where import GHC import PackageConfig import DynFlags import OtherModule main = setupsession >>= loadsession setupsession = do session <- newSession JustTypecheck (Just "/usr/local/lib/ghc-6.6") f <- getSessionDynFlags session f' <- parseDynamicFlags f ["-package ghc"] setSessionDynFlags session (fst f'){hscTarget = HscInterpreted} let preludeModule = mkModule (stringToPackageId "base") (mkModuleName "Prelude") setContext session [] [preludeModule] t <- guessTarget "ghclibtest.hs" Nothing addTarget session t return session loadsession session = load session LoadAllTargets other = 12 }}} I did note however, that *compiling* this does not seem to evoke the bug: {{{ harlan:~/Werk/dss/software/ghclib arthurvl$ ghc -package ghc --make -main- is GHCLibTest.main ghclibtest.hs [1 of 2] Compiling OtherModule ( OtherModule.hs, OtherModule.o ) [2 of 2] Compiling GHCLibTest ( ghclibtest.hs, ghclibtest.o ) Linking ghclibtest ... harlan:~/Werk/dss/software/ghclib arthurvl$ ./ghclibtest harlan:~/Werk/dss/software/ghclib arthurvl$ ls OtherModule.hi OtherModule.o ghclibtest.hi ghclibtest.o OtherModule.hs ghclibtest ghclibtest.hs }}} And then using the compiled modules with ghci doesn't break things anymore either! {{{ harlan:~/Werk/dss/software/ghclib arthurvl$ echo "setupsession >>= loadsession" | ghci -package ghc ghclibtest.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package Cabal-1.1.6 ... linking ... done. Loading package regex-base-0.71 ... linking ... done. Loading package regex-posix-0.71 ... linking ... done. Loading package regex-compat-0.71 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package ghc-6.6 ... linking ... done. Ok, modules loaded: OtherModule, GHCLibTest. Prelude GHCLibTest> Prelude GHCLibTest> Leaving GHCi. harlan:~/Werk/dss/software/ghclib arthurvl$ }}} Maybe the intermediate code for interpreted modules isn't re-entrant enough? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 05:25:15 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:18 2007 Subject: [GHC] #1187: GHC.Conc.prodServiceThread can deadlock In-Reply-To: <071.39595794168aedcbe4357e163ec9fa33@localhost> References: <071.39595794168aedcbe4357e163ec9fa33@localhost> Message-ID: <080.c916f5fd0b6aeda0a1bd1be341edb60f@localhost> #1187: GHC.Conc.prodServiceThread can deadlock ----------------------------+----------------------------------------------- Reporter: ms43 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by simonmar): * milestone: => 6.6.1 * owner: => simonmar Comment: The patch isn't completely correct; it should be using modifyMVar, which uses block/unblock internally (there's a still a race between takeMVar and catchException otherwise). However, modifyMVar isn't available yet, so we'd have to define a local copy of it. Instead it might be better to use atomicModifyIORef. Anyway, I'll look at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 08:27:01 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1093: Windows: haddock-html fields are wrong in package.conf In-Reply-To: <071.2b38f0c5951af294941b4c35ebd3730e@localhost> References: <071.2b38f0c5951af294941b4c35ebd3730e@localhost> Message-ID: <080.6646b00c5f7d50dcf79373af3f9dada4@localhost> #1093: Windows: haddock-html fields are wrong in package.conf --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Build System | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Windows | --------------------------+------------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: The filename problems turns out to be this: The haddock-html field is ultimately printed out by: {{{ showFilePath :: FilePath -> Doc showFilePath = showToken showToken :: String -> Doc showToken str | not (any dodgy str) && not (null str) = text str | otherwise = text (show str) where dodgy c = isSpace c || c == ',' }}} Thus when haddock asks ghc-pkg for the haddock-html field and the path contains spaces, it doesn't get a plain path back like it expects. It then checks to see if the mangled path exists, which it doesn't. I think the right way to fix this would be to have a ghc-pkg flag that gives more machine understandable output. However, as I assume haddock-ghc will not have this problem I'm going to close this bug; we might want to open a new one for a machine-understandable flag to ghc-pkg anyway. I've opened bugs in Cabal for a couple of issues that came up: http://hackage.haskell.org/trac/hackage/ticket/115 http://hackage.haskell.org/trac/hackage/ticket/116 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 08:46:00 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1195: Build error on MacOSX (Intel) 10.4.8 for HEAD from 2007-03-05 when compiling with ghc-6.6 Message-ID: <071.702f3c50571824505d2f4c3550b61394@localhost> #1195: Build error on MacOSX (Intel) 10.4.8 for HEAD from 2007-03-05 when compiling with ghc-6.6 -----------------------------------+---------------------------------------- Reporter: nominolo@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: x86 | Os: MacOS X -----------------------------------+---------------------------------------- make on MacOSX does not seem to stop when built errors occur. The first error message is: /tmp/ghc23705_0/ghc23705_0.split__38.s:unknown:missing indirect symbols for section (__TEXT,__symbol_stub) which happens after build step: == make all -r -f Makefile; in /Users/nominolo/Devel/Haskell/ghc/libraries/base ------------------------------------------------------------------------ ../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict-fields -package-name base-2.0 -O -Rghc-timing -fgenerics -fgenerics -split-objs -c GHC/Float.lhs -o GHC/Float.o -ohi GHC/Float.hi ------------------------------------------------------------------------ All following files consequently fail to build with the error message: .hs:1:0: Failed to load interface for `Prelude': Use -v to see a list of the files searched for. I was building with: $ uname -a Darwin 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 $ gcc -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform- name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5250) $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 08:54:14 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #957: No way to use -lgmp from a non-standard location In-Reply-To: <071.6d373de6fbf2d52f3259fbc414c4f107@localhost> References: <071.6d373de6fbf2d52f3259fbc414c4f107@localhost> Message-ID: <080.e86e4263fe36b964746e1aedc622572f@localhost> #957: No way to use -lgmp from a non-standard location ----------------------------------+----------------------------------------- Reporter: trangayesi@gmail.com | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Build System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: x86 Os: FreeBSD | ----------------------------------+----------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 11:49:46 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <071.bd4ae66865d4330446a06eaf62a80a52@localhost> References: <071.bd4ae66865d4330446a06eaf62a80a52@localhost> Message-ID: <080.b95fcd70dc096fc0f3dc6b73b332ff7e@localhost> #1110: Setting PATH needed in Windows Vista ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: Type: bug | Status: new Priority: high | Milestone: 6.6.1 Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------------------+------------------------------------------ Comment (by simonmar): It's a bug in MinGW (and/or gcc). Here's the latest thread I could find: [http://thread.gmane.org/gmane.comp.gnu.mingw.user/21709/focus=21711] it doesn't look like the MinGW folks have a fix checked in yet. So we could be hosed. One temporary fix could be to set the `GCC_EXEC_PREFIX` env var from GHC, I'll try that here and see if it works. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 11:58:36 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs Message-ID: <071.d38ee025a6e3ab4c7d0e4e7399c23440@localhost> #1196: Cabal on Windows doesn't like the in-place GHCs -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: cabal01 Architecture: Unknown | Os: Windows -------------------------+-------------------------------------------------- From e.g. a cmd prompt, Windows doesn't like the in-place GHCs: {{{ C:\>C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace' is not recognized as an internal or external command, operable program or batch file. C:\>cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc- inplace #!/bin/sh exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc -BC:\\\\cygwin\\\\home\\\\ian\\\\ghc\\\\6.6-branch\\\\build "$@" }}} which means the cabal01 test fails thus: {{{ $ ./setup configure --prefix=`pwd`/install --with- compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc- inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace --enable-library-profiling setup.exe: Warning: Package is copyright All Rights Reserved setup.exe: Warning: No license-file field. 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace' is not recognized as an internal or external command, operable program or batch file. Configuring test-1.0... }}} (the odd output order is due to buffering) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 12:18:23 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs In-Reply-To: <071.d38ee025a6e3ab4c7d0e4e7399c23440@localhost> References: <071.d38ee025a6e3ab4c7d0e4e7399c23440@localhost> Message-ID: <080.f812448be45a57b563cbed1e3971b647@localhost> #1196: Cabal on Windows doesn't like the in-place GHCs ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: cabal01, cabal02 | Architecture: Unknown Os: Windows | ------------------------------+--------------------------------------------- Changes (by igloo): * testcase: cabal01 => cabal01, cabal02 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 12:34:02 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1197: Windows: conc023.exe: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks failed: Not enough storage is available to process this command. Message-ID: <071.d0f4238e279c5a8a97d8ee42386d0a36@localhost> #1197: Windows: conc023.exe: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks failed: Not enough storage is available to process this command. -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.2 Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: conc023 Architecture: Unknown | Os: Windows -------------------------+-------------------------------------------------- When running conc023 in the 6.6 branch the "normal" way on Windows I get: {{{ $ ./conc023 conc023.exe: getMBlocks: VirtualAlloc MEM_RESERVE 1 blocks failed: Not enough storage is available to process this command. }}} All other ways work. The 6.6 release also exhibits the bug (and may be worse - the opt way seems to sometimes break too). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 13:11:59 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #669: negative indentation in Text.PrettyPrint.HughesPJ In-Reply-To: <071.ed380d6fa3fbf0f091e4a61b8ced6e1c@localhost> References: <071.ed380d6fa3fbf0f091e4a61b8ced6e1c@localhost> Message-ID: <080.7aec72bbbee092042bc1f48d741b533e@localhost> #669: negative indentation in Text.PrettyPrint.HughesPJ ------------------------------------------+--------------------------------- Reporter: waldmann@imn.htwk-leipzig.de | Owner: thorkilnaur Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: hslibs/text | Version: 6.4.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by thorkilnaur): * owner: => thorkilnaur -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 13:12:57 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1176: Infinite loop when printing error message In-Reply-To: <071.292b4275ce2906adf2166d790d602cf3@localhost> References: <071.292b4275ce2906adf2166d790d602cf3@localhost> Message-ID: <080.1660a491d732606ee438a09cc9b02921@localhost> #1176: Infinite loop when printing error message ---------------------------------------+------------------------------------ Reporter: Paul_Berry@alumni.hmc.edu | Owner: thorkilnaur Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail177 | Architecture: Multiple Os: Multiple | ---------------------------------------+------------------------------------ Changes (by thorkilnaur): * owner: => thorkilnaur -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 13:28:56 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1186: GHC as a library panic on loading second module In-Reply-To: <071.c729b729fb656db3b094dc59987ef601@localhost> References: <071.c729b729fb656db3b094dc59987ef601@localhost> Message-ID: <080.90f59ff138ab0e0ce5d75577498963bc@localhost> #1186: GHC as a library panic on loading second module ------------------------------+--------------------------------------------- Reporter: ArthurVanLeeuwen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: Unknown | ------------------------------+--------------------------------------------- Comment (by thorkilnaur): Thanks a lot, I can repeat it now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 14:46:14 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1198: readwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument (Invalid argument) Message-ID: <071.9217093692e4747cf08bb198f3b5eaeb@localhost> #1198: readwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument (Invalid argument) -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.2 Component: libraries/base | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: readwrite002 Architecture: Unknown | Os: Windows -------------------------------+-------------------------------------------- On Windows, readwrite002 is failing with {{{ readwrite002.exe: readwrite002.inout: hWaitForInput: invalid argument (Invalid argument) }}} The error is being generated by {{{ rc = PeekNamedPipe( hFile, NULL, 0, NULL, &avail, NULL ); }}} in the `inputReady` function in `cbits/inputReady.c`, during a call to `hReady`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 16:06:39 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs In-Reply-To: <071.d38ee025a6e3ab4c7d0e4e7399c23440@localhost> References: <071.d38ee025a6e3ab4c7d0e4e7399c23440@localhost> Message-ID: <080.a5146bac00777d488ebb429285f0fca8@localhost> #1196: Cabal on Windows doesn't like the in-place GHCs ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: cabal01, cabal02 | Architecture: Unknown Os: Windows | ------------------------------+--------------------------------------------- Comment (by simonmar): Yes, I got halfway to fixing this and didn't finish it. Basically I was planning to do away with the ghc-inplace scripts on Windows, and instead have the GHC binary figure out whether it was in a build tree or not by inspecting the binary pathname. ghc-inplace causes problems for the testsuite driver too, IIRC. Unfortunately similar changes would also be required to ghc-pkg (doing away with ghc-pkg-inplace on Windows), since there's no way to pass extra arguments to ghc-pkg via Cabal (perhaps there should be?). Better ideas welcome... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 16:30:18 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1167: mangler makes global symbol disappear on linux-ppc In-Reply-To: <071.569fb501a598f699bbd778dff994ec2f@localhost> References: <071.569fb501a598f699bbd778dff994ec2f@localhost> Message-ID: <080.e6a51dbf82266653195d13cf9c1f53ba@localhost> #1167: mangler makes global symbol disappear on linux-ppc ---------------------------------+------------------------------------------ Reporter: arekm@pld-linux.org | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: Linux | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.6.1 Old description: > Enviroment: linux-ppc, very fresh software, upcoming gcc 4.2, ghc 6.6. I > was trying to build alex software which ended with: > GNU ld version 2.17.50.0.12 20070128 > Supported emulations: > elf32ppclinux > elf32ppc > elf32ppcsim > ghc3729_0.hc:(.text+0x104a): undefined reference to > `ParseMonad_alexStartPos_closure' > ghc3729_0.hc:(.text+0x104e): undefined reference to > `ParseMonad_alexStartPos_closure' > dist/build/alex/alex-tmp/Info.o: In function `shII_info': > ghc3729_0.hc:(.text+0x106e): undefined reference to `Util_lvl1_closure' > ghc3729_0.hc:(.text+0x1072): undefined reference to `Util_lvl1_closure' > ghc3729_0.hc:(.text+0x107a): undefined reference to `Util_lvl1_closure' > dist/build/alex/alex-tmp/Info.o:(.rodata+0x40): undefined reference to > `Util_lvl1_closure' > > The problem is that these symbol disappear after going through mangler > (so problem is visible only when -O2 is used) > > In short the problem is that: > .globl ParseMonad_alexStartPos_closure > disappears. New description: Enviroment: linux-ppc, very fresh software, upcoming gcc 4.2, ghc 6.6. I was trying to build alex software which ended with: {{{ GNU ld version 2.17.50.0.12 20070128 Supported emulations: elf32ppclinux elf32ppc elf32ppcsim ghc3729_0.hc:(.text+0x104a): undefined reference to `ParseMonad_alexStartPos_closure' ghc3729_0.hc:(.text+0x104e): undefined reference to `ParseMonad_alexStartPos_closure' dist/build/alex/alex-tmp/Info.o: In function `shII_info': ghc3729_0.hc:(.text+0x106e): undefined reference to `Util_lvl1_closure' ghc3729_0.hc:(.text+0x1072): undefined reference to `Util_lvl1_closure' ghc3729_0.hc:(.text+0x107a): undefined reference to `Util_lvl1_closure' dist/build/alex/alex-tmp/Info.o:(.rodata+0x40): undefined reference to `Util_lvl1_closure' }}} The problem is that these symbol disappear after going through mangler (so problem is visible only when -O2 is used) In short the problem is that: {{{ .globl ParseMonad_alexStartPos_closure }}} disappears. Comment: I'm putting this in the 6.6.1 milestone for now as it looks pretty bad if it bites often, but I'm not sure if anyone's actively working on the registerised Linux/PPC port, so we might well end up punting on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 16:36:57 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1174: Impredicative type-class context causes stack overflow or non-termination in type checker In-Reply-To: <071.cce8a754d295089ada17949ea93cadf0@localhost> References: <071.cce8a754d295089ada17949ea93cadf0@localhost> Message-ID: <080.e4d81692e053254f006039dd014cffa3@localhost> #1174: Impredicative type-class context causes stack overflow or non-termination in type checker ----------------------+----------------------------------------------------- Reporter: ccshan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * resolution: => duplicate * status: new => closed Comment: Thanks for the report. This is a duplicate of #940, fixed in the 6.6 branch and the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 17:45:55 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1199: Type variables in DataD do not match up: Message-ID: <071.fb05384152d275a9ee262513ead0e00f@localhost> #1199: Type variables in DataD do not match up: ---------------------------------+------------------------------------------ Reporter: wolfgang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Multiple | Os: Multiple ---------------------------------+------------------------------------------ When reigying an ADT, the type variables listed on the left side are different from those used on the right side: {{{ Prelude Language.Haskell.TH> $(reify ''Maybe >>= stringE . show) "TyConI (DataD [] Data.Maybe.Maybe [a_1627391676] [NormalC Data.Maybe.Nothing [],NormalC Data.Maybe.Just [(NotStrict,VarT a_1627391681)]] [])" }}} The type variables do match up when we look just at the constructor: {{{ Prelude Language.Haskell.TH> $(reify 'Just >>= stringE . show) "DataConI Data.Maybe.Just (ForallT [a_1627391681] [] (AppT (AppT ArrowT (VarT a_1627391681)) (AppT (ConT Data.Maybe.Maybe) (VarT a_1627391681)))) Data.Maybe.Maybe (Fixity 9 InfixL)" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 17:56:36 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1182: splitAt does not implement H98 report behaviour, it is too strict in 'n' In-Reply-To: <071.b6f26db9d731c26710326b7297cf4211@localhost> References: <071.b6f26db9d731c26710326b7297cf4211@localhost> Message-ID: <080.b7fe9031a92a3e528213193758e77587@localhost> #1182: splitAt does not implement H98 report behaviour, it is too strict in 'n' ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: libraries/haskell98 | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.8 Comment: I've opened a Haskell' bug at http://hackage.haskell.org/trac/haskell-prime/ticket/119 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 17:59:44 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1184: Hasktags misses symbol In-Reply-To: <071.cd49219457461831e734204dc9199647@localhost> References: <071.cd49219457461831e734204dc9199647@localhost> Message-ID: <080.8cb783d6da7e372c92bbc1656d4710df@localhost> #1184: Hasktags misses symbol ---------------------+------------------------------------------------------ Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.2 Component: None | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Changes (by igloo): * milestone: => 6.6.2 Old description: > (not sure I filed this bug appropriately. I belive hasktags came as part > of the ghc-6.6 binary package. Please advise if there's a better place) > > Hasktags is missing an obvious symbol. > > $ darcs get --partial http://happs.org/HAppS > > $ cd HAppS/src > > $ hasktags -c `find . -name '*.hs' |grep -v _darcs` > > $ grep boolM # <- not found > > $ grep boolM `find . -name '*.hs' |grep -v _darcs` # <- found New description: (not sure I filed this bug appropriately. I belive hasktags came as part of the ghc-6.6 binary package. Please advise if there's a better place) Hasktags is missing an obvious symbol. {{{ $ darcs get --partial http://happs.org/HAppS $ cd HAppS/src $ hasktags -c `find . -name '*.hs' |grep -v _darcs` $ grep boolM # <- not found $ grep boolM `find . -name '*.hs' |grep -v _darcs` # <- found }}} Comment: This is the right place. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 5 19:13:51 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1188: STM.c:stmCommitNestedTransaction bogosity In-Reply-To: <071.ad62bfb8b52ac71bd8f0deb97b7e4dfd@localhost> References: <071.ad62bfb8b52ac71bd8f0deb97b7e4dfd@localhost> Message-ID: <080.ad91cac2d23867f3c2efe43d20aafe40@localhost> #1188: STM.c:stmCommitNestedTransaction bogosity ----------------------------+----------------------------------------------- Reporter: ms43 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: I've applied this fix to the 6.6 branch (it turns out it was already in the HEAD); thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 6 01:58:48 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1199: Type variables in DataD do not match up: In-Reply-To: <071.fb05384152d275a9ee262513ead0e00f@localhost> References: <071.fb05384152d275a9ee262513ead0e00f@localhost> Message-ID: <080.5c5d6c9c8f21f18cf18b3106b674ea4d@localhost> #1199: Type variables in DataD do not match up: ------------------------------+--------------------------------------------- Reporter: wolfgang | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: Ah yes, good point. Now fixed. Pls merge: Tue Mar 6 06:56:41 GMT Standard Time 2007 simonpj@microsoft.com * Simple fix for Trac #1199 (pls merge to branch) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 6 02:56:36 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1200: ghci scripts ending in printf lines fail with Exception: Prelude.undefined Message-ID: <071.05f2d8500667cefb0c40c6178ec5c4a0@localhost> #1200: ghci scripts ending in printf lines fail with Exception: Prelude.undefined ------------------------+--------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- There appears to be some differences in runhaskell/ghci and ghc when it comes to printf. Consider this program: {{{ import Text.Printf import System.Environment main = do [who] <- getArgs printf "hello, %s\n" who }}} when compiled: {{{ $ ghc A.hs $ ./A world hello, world }}} When run in GHci: {{{ $ ghci A.hs Prelude Main> :set args world Prelude Main> main hello, world *** Exception: Prelude.undefined }}} Hmm! And in runhaskell: {{{ $ runhaskell A.hs world hello, world *** Exception: Prelude.undefined }}} An ugly 'return ()' seems to help: {{{ import Text.Printf import System.Environment main = do [who] <- getArgs printf "hello, %s\n" who return () }}} which produces: {{{ $ runhaskell A.hs world hello, world }}} As does an explicit annotation: {{{ $ cat A.hs import Text.Printf import System.Environment main = do [who] <- getArgs printf "hello, %s\n" who :: IO () }}} So some defaulting is coming into play? {{{ $ ghci Prelude> :l A.hs *Main> :t main main :: IO t *Main> :set args world *Main> main :: IO () hello, world *Main> main :: IO String hello, world "*** Exception: Prelude.undefined }}} Is GHCi/runhaskell giving an overly generous type to 'main'? I note the following is also valid "runhaskell" programs: {{{ $ cat A.hs main = return "hello, world" $ runhaskell A.hs "hello, world" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 6 04:22:01 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1076: runhaskell crash with .hi/.o files in the directory In-Reply-To: <071.bd967e6a99c05563037af5f6e38b2774@localhost> References: <071.bd967e6a99c05563037af5f6e38b2774@localhost> Message-ID: <080.455756aac117c3958b06182af48eb33b@localhost> #1076: runhaskell crash with .hi/.o files in the directory ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * resolution: => duplicate * status: new => closed Comment: No answer from submitter; I tried the example code and couldn't reproduce any bugs. The "unknown or unimplemented opcode" crash is almost certainly the same as #1013, and the other problems are most likely due to inconsistent .o/.hi files. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 6 04:26:51 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1186: GHC as a library panic on loading second module In-Reply-To: <071.c729b729fb656db3b094dc59987ef601@localhost> References: <071.c729b729fb656db3b094dc59987ef601@localhost> Message-ID: <080.af8958cf81ea4dcfedd6f0d3550bb43f@localhost> #1186: GHC as a library panic on loading second module ------------------------------+--------------------------------------------- Reporter: ArthurVanLeeuwen | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.2 Component: GHC API | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: Unknown | ------------------------------+--------------------------------------------- Changes (by simonmar): * milestone: => 6.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 6 07:48:09 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1201: ghci runs Template Haskell splices 4 times Message-ID: <071.14843676904b05ef893bac1373e42547@localhost> #1201: ghci runs Template Haskell splices 4 times ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.2 Component: Template Haskell | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: ghci016 Architecture: Unknown | Os: Unknown ---------------------------------+------------------------------------------ ghci (both 6.6 and HEAD) appears to run Template Haskell splices 4 times, as shown here: {{{ $ ghci -fth -v0 Prelude> :m + Language.Haskell.TH Prelude Language.Haskell.TH> $(do runIO $ (Random.randomIO :: IO Int) >>= print; [| 1 |] ) 7184082642420483628 -8222359774145102883 2625059211496099566 1462332877512834399 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 6 07:51:06 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1201: ghci runs Template Haskell splices 4 times In-Reply-To: <071.14843676904b05ef893bac1373e42547@localhost> References: <071.14843676904b05ef893bac1373e42547@localhost> Message-ID: <080.7bbc3ca447ccc981cef750a22fa8b3f9@localhost> #1201: ghci runs Template Haskell splices 4 times ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.2 Component: Template Haskell | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ghci018 | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * testcase: ghci016 => ghci018 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 6 08:11:15 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1199: Type variables in DataD do not match up: In-Reply-To: <071.fb05384152d275a9ee262513ead0e00f@localhost> References: <071.fb05384152d275a9ee262513ead0e00f@localhost> Message-ID: <080.7e45b785d65a00894d703f684ecbd81d@localhost> #1199: Type variables in DataD do not match up: ------------------------------+--------------------------------------------- Reporter: wolfgang | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: TH_reifyDecl2 | Architecture: Multiple Os: Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * resolution: => fixed * testcase: => TH_reifyDecl2 * status: new => closed Comment: Not merged: the 6.6 branch works already. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 6 09:50:29 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1077: documentation error and omission In-Reply-To: <071.3d99ff25768abf8c5be29dd11eefbea4@localhost> References: <071.3d99ff25768abf8c5be29dd11eefbea4@localhost> Message-ID: <080.f991ffd6db505729878d26bc6a7610e0@localhost> #1077: documentation error and omission ---------------------------+------------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.6.1 Component: Documentation | Version: 6.6 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Multiple | ---------------------------+------------------------------------------------ Changes (by igloo): * resolution: => fixed * status: new => closed Comment: The 6.6 branch is now also without building guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 6 09:52:24 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <071.bd4ae66865d4330446a06eaf62a80a52@localhost> References: <071.bd4ae66865d4330446a06eaf62a80a52@localhost> Message-ID: <080.6f309fd5c4f968477118530768914ec5@localhost> #1110: Setting PATH needed in Windows Vista ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.6.1 Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 6 10:56:25 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #986: SMP race condition in getContents In-Reply-To: <071.e597e5a37c8a401a679e6f5a37f233ed@localhost> References: <071.e597e5a37c8a401a679e6f5a37f233ed@localhost> Message-ID: <080.f6a2cf79fd4c99e8214a1683c3731973@localhost> #986: SMP race condition in getContents ----------------------------+----------------------------------------------- Reporter: int-e | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: I've committed some fixes to the HEAD for this, let's let them settle a while before merging. The patches are: {{{ Tue Mar 6 14:31:12 GMT 2007 Simon Marlow * add noDuplicate# Tue Mar 6 14:27:32 GMT 2007 Simon Marlow * THREADED_RTS: use cas() when claiming thunks }}} and for libraries/base: {{{ Tue Mar 6 14:54:24 GMT 2007 Simon Marlow * Prevent duplication of unsafePerformIO on a multiprocessor }}} and for the testsuite: {{{ Tue Mar 6 15:54:50 GMT 2007 Simon Marlow * add test for #986 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From sof at galois.com Tue Mar 6 11:32:04 2007 From: sof at galois.com (Sigbjorn Finne) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs In-Reply-To: <071.d38ee025a6e3ab4c7d0e4e7399c23440@localhost> References: <071.d38ee025a6e3ab4c7d0e4e7399c23440@localhost> Message-ID: <45ED9784.7070901@galois.com> I added support for generating .bat files (to HEAD, I believe) for these in-place wrappers some time ago just to address this issue, so you may want to look into dragging those Makefile mods over. --sigbjorn On 3/5/2007 08:58, GHC wrote: > #1196: Cabal on Windows doesn't like the in-place GHCs > -------------------------+-------------------------------------------------- > Reporter: igloo | Owner: > Type: bug | Status: new > Priority: normal | Milestone: _|_ > Component: Compiler | Version: 6.6 > Severity: normal | Keywords: > Difficulty: Unknown | Testcase: cabal01 > Architecture: Unknown | Os: Windows > -------------------------+-------------------------------------------------- > From e.g. a cmd prompt, Windows doesn't like the in-place GHCs: > {{{ > C:\>C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace > 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace' is > not recognized as an internal or external command, operable program or > batch file. > > C:\>cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc- > inplace > #!/bin/sh > exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc > -BC:\\\\cygwin\\\\home\\\\ian\\\\ghc\\\\6.6-branch\\\\build "$@" > }}} > which means the cabal01 test fails thus: > {{{ > $ ./setup configure --prefix=`pwd`/install --with- > compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc- > inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace > --enable-library-profiling > setup.exe: Warning: Package is copyright All Rights Reserved > setup.exe: Warning: No license-file field. > 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace' is > not recognized as an internal or external command, > operable program or batch file. > Configuring test-1.0... > }}} > (the odd output order is due to buffering) > > > ------------------------------------------------------------------------ > > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > From simonmarhaskell at gmail.com Tue Mar 6 11:46:22 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs In-Reply-To: <45ED9784.7070901@galois.com> References: <071.d38ee025a6e3ab4c7d0e4e7399c23440@localhost> <45ED9784.7070901@galois.com> Message-ID: <45ED9ADE.2090701@gmail.com> Ah, so you did, thanks for reminding me. We still need to do something about ghc-pkg, though. Cheers, Simon Sigbjorn Finne wrote: > I added support for generating .bat files (to HEAD, I believe) for these > in-place > wrappers some time ago just to address this issue, so you may want to > look into > dragging those Makefile mods over. > > --sigbjorn > > On 3/5/2007 08:58, GHC wrote: >> #1196: Cabal on Windows doesn't like the in-place GHCs >> -------------------------+-------------------------------------------------- >> >> Reporter: igloo | Owner: Type: >> bug | Status: new Priority: normal | >> Milestone: _|_ Component: Compiler | Version: 6.6 >> Severity: normal | Keywords: Difficulty: Unknown >> | Testcase: cabal01 >> Architecture: Unknown | Os: Windows >> -------------------------+-------------------------------------------------- >> >> From e.g. a cmd prompt, Windows doesn't like the in-place GHCs: >> {{{ >> C:\>C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace >> 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace' is >> not recognized as an internal or external command, operable program or >> batch file. >> >> C:\>cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc- >> inplace >> #!/bin/sh >> exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc >> -BC:\\\\cygwin\\\\home\\\\ian\\\\ghc\\\\6.6-branch\\\\build "$@" >> }}} >> which means the cabal01 test fails thus: >> {{{ >> $ ./setup configure --prefix=`pwd`/install --with- >> compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc- >> inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace >> --enable-library-profiling >> setup.exe: Warning: Package is copyright All Rights Reserved >> setup.exe: Warning: No license-file field. >> 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace' is >> not recognized as an internal or external command, >> operable program or batch file. >> Configuring test-1.0... >> }}} >> (the odd output order is due to buffering) >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Glasgow-haskell-bugs mailing list >> Glasgow-haskell-bugs@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs >> > > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > From sof at galois.com Tue Mar 6 11:49:45 2007 From: sof at galois.com (Sigbjorn Finne) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1196: Cabal on Windows doesn't like the in-place GHCs In-Reply-To: <45ED9ADE.2090701@gmail.com> References: <071.d38ee025a6e3ab4c7d0e4e7399c23440@localhost> <45ED9784.7070901@galois.com> <45ED9ADE.2090701@gmail.com> Message-ID: <45ED9BA9.3090206@galois.com> If you're referring to ghc-pkg-inplace invocations from Cabal, the same hack was applied in utils/ghc-pkg also. --sigbjorn On 3/6/2007 08:46, Simon Marlow wrote: > Ah, so you did, thanks for reminding me. We still need to do > something about ghc-pkg, though. > > Cheers, > Simon > > Sigbjorn Finne wrote: >> I added support for generating .bat files (to HEAD, I believe) for >> these in-place >> wrappers some time ago just to address this issue, so you may want to >> look into >> dragging those Makefile mods over. >> >> --sigbjorn >> >> On 3/5/2007 08:58, GHC wrote: >>> #1196: Cabal on Windows doesn't like the in-place GHCs >>> -------------------------+-------------------------------------------------- >>> >>> Reporter: igloo | Owner: Type: >>> bug | Status: new Priority: normal | >>> Milestone: _|_ Component: Compiler | Version: >>> 6.6 Severity: normal | Keywords: >>> Difficulty: Unknown | Testcase: cabal01 >>> Architecture: Unknown | Os: Windows >>> -------------------------+-------------------------------------------------- >>> >>> From e.g. a cmd prompt, Windows doesn't like the in-place GHCs: >>> {{{ >>> C:\>C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace >>> >>> 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc-inplace' >>> is >>> not recognized as an internal or external command, operable program or >>> batch file. >>> >>> C:\>cat C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage2\ghc- >>> inplace >>> #!/bin/sh >>> exec C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage2/ghc >>> -BC:\\\\cygwin\\\\home\\\\ian\\\\ghc\\\\6.6-branch\\\\build "$@" >>> }}} >>> which means the cabal01 test fails thus: >>> {{{ >>> $ ./setup configure --prefix=`pwd`/install --with- >>> compiler=C:/cygwin/home/ian/ghc/6.6-branch/build/compiler/stage1/ghc- >>> inplace --with-hc-pkg=../../../../../utils/ghc-pkg/ghc-pkg-inplace >>> --enable-library-profiling >>> setup.exe: Warning: Package is copyright All Rights Reserved >>> setup.exe: Warning: No license-file field. >>> 'C:\cygwin\home\ian\ghc\6.6-branch\build\compiler\stage1\ghc-inplace' >>> is >>> not recognized as an internal or external command, >>> operable program or batch file. >>> Configuring test-1.0... >>> }}} >>> (the odd output order is due to buffering) >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Glasgow-haskell-bugs mailing list >>> Glasgow-haskell-bugs@haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs >>> >> >> _______________________________________________ >> Glasgow-haskell-bugs mailing list >> Glasgow-haskell-bugs@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs >> From trac at galois.com Tue Mar 6 12:28:06 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:19 2007 Subject: [GHC] #1195: Build error on MacOSX (Intel) 10.4.8 for HEAD from 2007-03-05 when compiling with ghc-6.6 In-Reply-To: <071.702f3c50571824505d2f4c3550b61394@localhost> References: <071.702f3c50571824505d2f4c3550b61394@localhost> Message-ID: <080.4e3c545b5e5ae0cf6398797228d01cb8@localhost> #1195: Build error on MacOSX (Intel) 10.4.8 for HEAD from 2007-03-05 when compiling with ghc-6.6 --------------------------------+------------------------------------------- Reporter: nominolo@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | --------------------------------+------------------------------------------- Comment (by thorkilnaur): On PPC Mac OS X 10.4, http://darcs.haskell.org:8010/tnaur%20PPC%20OSX%20head/builds/12/step- compilestage1/0 has a different error: {{{ == make all -r -f Makefile; in /Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx/tnaur-ppc-osx- head/build/libraries/base ------------------------------------------------------------------------ ../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict-fields -package-name base-2.0 -O -fasm -fgenerics -fgenerics -c GHC/Err.lhs-boot -o GHC/Err.o-boot -ohi GHC/Err.hi-boot GHC error in desugarer lookup in base:GHC.Err: Failed to load interface for `GHC.Base': Use -v to see a list of the files searched for. ghc-6.7.20070221: panic! (the 'impossible' happened) (GHC version 6.7.20070221 for powerpc-apple-darwin): initDs user error (IOEnv failure) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[2]: *** [GHC/Err.o-boot] Error 1 }}} But the reaction following the error is similar: {{{ ------------------------------------------------------------------------ == make all -r -f Makefile; in /Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx/tnaur-ppc-osx- head/build/libraries/haskell98 ------------------------------------------------------------------------ ../../compiler/ghc-inplace -H16m -O -package-name haskell98-1.0 -O -fasm -fgenerics -package base -fgenerics -c Ix.hs -o Ix.o -ohi Ix.hi Ix.hs:1:0: Failed to load interface for `Prelude': Use -v to see a list of the f