From trac at galois.com Sun Nov 1 01:22:58 2009 From: trac at galois.com (GHC) Date: Sun Nov 1 01:59:17 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input Message-ID: <051.646cea9a90aceb1e42e96d631b059b64@localhost> #3631: Overload the Prelude iterate to support list input -----------------------------+---------------------------------------------- Reporter: shelbymoore3 | Owner: Type: feature request | Status: new Priority: normal | Component: Prelude Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Had to overload the Prelude function iterate to support list input. The overload could be global (should be added to Prelude), no need to wrap in where. My example fibonacci sequence usage follows. {{{ fibs = 0 : 1 : zipWith (+) fibs (tail fibs) }}} Make forward iteration explicit, and remove self referential space "leak" above due direct recursion on fibs. {{{ fibs = iterate (\x -> last x + last init x) [ 0 : 1 ] where iterate :: ([a] -> [a]) -> [a] -> [a] iterate f x = iterate f (x : (f x)) -- iterate f x == [x, f x, f (f x), ...] }}} Or verbosely: {{{ fibs = iterate (\x -> fib -1 + fib -2 where fib i = | i==-1=last x | i==-2=last init x) [ 0 : 1 ] -- negative indices in local function fib offset from end of list }}} P.S. Note I not using HUGS nor GHC, this is just in my head. The above are my unique solutions, didn't lift them from www. I am just learning FP and Haskell for first time in my head past few days. So this might be rubbish. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 1 01:25:16 2009 From: trac at galois.com (GHC) Date: Sun Nov 1 01:01:35 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.39ea0f2cf78d17a27bd19eb63ba993ec@localhost> #3631: Overload the Prelude iterate to support list input ------------------------------+--------------------------------------------- Reporter: shelbymoore3 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by shelbymoore3): Prelude function iterate: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v%3Aiterate -- Ticket URL: GHC The Glasgow Haskell Compiler From marlowsd at gmail.com Mon Nov 2 08:52:11 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Nov 2 08:28:32 2009 Subject: mkdirhier fails on Ubuntu Hardy i686 with dash shell In-Reply-To: <20091025193447.GA26087@matrix.chaos.earth.li> References: <20091025193447.GA26087@matrix.chaos.earth.li> Message-ID: <4AEEE40B.4090201@gmail.com> On 25/10/2009 19:34, Ian Lynagh wrote: > On Mon, Oct 19, 2009 at 12:49:44PM -0600, Zooko Wilcox-O'Hearn wrote: >> >> Replacing the contents of mkdirhier and mkdirhier.sh with "mkdir -p $*" >> works-around the problem. > > Does anyone know why we don't just call "mkdir -p" normally? Are there > portability problems with it? I believe 'mkdir -p' was not supported by some old unices, but AFAICT it seems to be supported by everything we build on these days. It probably wouldn't hurt to use it instead of mkdirhier. Cheers, Simon From trac at galois.com Mon Nov 2 16:19:42 2009 From: trac at galois.com (GHC) Date: Mon Nov 2 15:55:56 2009 Subject: [GHC] #3632: lift restrictions on records with existential fields, especially in the presence of class constraints Message-ID: <047.bdd2c439db336bced650a9d8503aba8e@localhost> #3632: lift restrictions on records with existential fields, especially in the presence of class constraints ------------------------------------------------+--------------------------- Reporter: eflister | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: existential records accessor update | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------------------------+--------------------------- the attached file demos the use of a record with an existential field with a class constraint. it shows several cases where lifting the current restrictions on accessing and updating this field would be both well- defined and useful. here is the record definition; the dur field is existential, but constrained to be in class NoteDur. {{{ data Note = forall x . NoteDur x => Note { midiNum :: Int -- 0-255 , vel :: Int -- 0-255 , chan :: Int -- 0-15 , measure :: Integral a => a , beat :: Int , subdiv :: RealFrac a => a -- % of beat , dur :: x } }}} here is a walk through of places in the code where the current restrictions are unnecessary and intrusive: lines 64-95 -- these functions wouldn't be necessary if record update syntax were enabled for both existential and non-existential fields. i know 6.12 introduces it for non-existentials, but i don't see why it isn't also possible for existential fields (even without a class constraint). lines 33-35 and 60 show how much nicer it is to use regular updater syntax in this case. the same is true for existential accessors when there is a class constraint -- there's no need to restrict this situation because the accessor can have type: fieldName :: (SomeClass x) => Record -> x line 142 shows a case where this would be very nice to have. line 100 + 107 -- the foralls could be implicit (maybe offer an extention that would allow them to be implicit) lines 134-136 compared to 138-139 show how additional factoring could be achieved if one were allowed to pattern match on the type of an existential with class constraints. lines 124-127 show how it would be nice to have existential classes lastly, allow curried updater functions: (rec {field = }) 5 instead of (\x -> (rec {field = x})) 5 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 2 19:47:24 2009 From: trac at galois.com (GHC) Date: Mon Nov 2 19:23:38 2009 Subject: [GHC] #3632: lift restrictions on records with existential fields, especially in the presence of class constraints In-Reply-To: <047.bdd2c439db336bced650a9d8503aba8e@localhost> References: <047.bdd2c439db336bced650a9d8503aba8e@localhost> Message-ID: <056.ac08188eb9e4651059e2f3e52db0a184@localhost> #3632: lift restrictions on records with existential fields, especially in the presence of class constraints -------------------------------------------------+-------------------------- Reporter: eflister | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: existential records accessor update | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------------------+-------------------------- Changes (by eflister): * cc: erik.flister@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 2 20:22:43 2009 From: trac at galois.com (GHC) Date: Mon Nov 2 19:58:57 2009 Subject: [GHC] #3630: Suggested algorithm to control upper bound of space "leaks" In-Reply-To: <051.72af98bc6de8e1372fe3431e4a8c348a@localhost> References: <051.72af98bc6de8e1372fe3431e4a8c348a@localhost> Message-ID: <060.2ae3c29b5dd81b657af6160771e10931@localhost> #3630: Suggested algorithm to control upper bound of space "leaks" ------------------------------+--------------------------------------------- Reporter: shelbymoore3 | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by shelbymoore3): Simon Marlow replied and I replied with more thoughts: http://www.haskell.org/pipermail/cvs-ghc/2009-November/050946.html And here: http://www.haskell.org/pipermail/haskell-cafe/2009-November/068436.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 2 21:05:57 2009 From: trac at galois.com (GHC) Date: Mon Nov 2 20:42:16 2009 Subject: [GHC] #3633: Heap size suggestion of > 2145 MB gets ignored Message-ID: <042.715300f691a60275dfa2a5a83e344a71@localhost> #3633: Heap size suggestion of > 2145 MB gets ignored --------------------+------------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Severity: minor Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- Hello, If I run a GHC-compiled program with: {{{+RTS -H2150M -RTS}}} or any value greater than 2150 MB, the heap size suggestion apparently gets ignored. If there is a limit on how big the heap size suggestion can be, at least I should get an error message. My machine has 4 GB of RAM and I'm eager to use it :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 02:41:18 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 02:17:32 2009 Subject: [GHC] #3634: Add traceM, traceShowM and withTrace Message-ID: <060.9dd940925e454c846a3ca3a5aadefbb9@localhost> #3634: Add traceM, traceShowM and withTrace ----------------------------------+----------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ----------------------------------+----------------------------------------- On haskell-libraries we have [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/12019 discussed] the addition of the following three functions to module Debug.Trace: {{{ withTrace :: Show a => String -> a -> a withTrace msg x = trace (msg ++ show x) x traceM :: Monad m => String -> m () traceM msg = trace msg (return ()) traceShowM :: (Show a, Monad m) => a -> m () traceShowM = traceM . show }}} The current documentation for that module is a little terse so we have also added an example to clarify the use of trace. The following people have participated in the discussion and all expressed interest, agreement or concerns (but always with constructive comments) in or over the new functions: Philip H?lzenspies, pepe, Lennart Augustsson, Felipe Lessa, Evan !LaForge, Joachim Breitner, Twan van Laarhoven, Ben Franksen, Ian Lynagh, Sean Leather. Please see the thread for more detail. I have attached a diff that can be applied to the module. Could one of the GHC developers check it and apply it? Thanks, Martijn. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 03:59:49 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 03:36:02 2009 Subject: [GHC] #3635: base-3-compat with 6.12 won't load in GHCi, Template Haskell on Windows Message-ID: <044.df7c80f0816e4233c9d311717355b62b@localhost> #3635: base-3-compat with 6.12 won't load in GHCi, Template Haskell on Windows -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.12.1 RC1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple -----------------------+---------------------------------------------------- base3-compat/GHC/Handle.hs needs: {{{ #ifndef mingw32_HOST_OS .. #endif }}} Wrapped around its export for and definition of unlockFile. This is because unlockFile is a RTS symbol that is only compiled on non-Windows OSes. This #ifdef exists in base4, it looks like it was just omitted from base3. The result of this bug is that any package using base 3 doesn?t work with template-haskell or GHCi: {{{ $ ghci -package base-3.0.3.2 WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular) doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead GHCi, version 6.12.0.20091010: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package syb-0.1.0.2 ... linking ... done. Loading package base-3.0.3.2 ... linking ... : unable to load package `base-3.0.3.2' : C:\ghc\GHC-61~2.200\lib\base-3.0.3.2\HSbase-3.0.3.2.o: unknown symbol `_unlockFile' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 04:01:25 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 03:37:39 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.d042cd103e4b18f5cad5140991711e74@localhost> #3631: Overload the Prelude iterate to support list input ------------------------------+--------------------------------------------- Reporter: shelbymoore3 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by shelbymoore3): The suggested iterate function remains as stated. I just want to point out my example lamba function usage was not returning a list. Corrected: fibs = iterate (\x -> [last x + last init x]) [ 0 : 1 ] where Ditto (and I think I need to add the semicolon in the one line guard?): fibs = iterate (\x -> [fib -1 + fib -2] where fib i = | i==-1=last x; | i==-2=last init x) [ 0 : 1 ] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 04:06:40 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 03:42:53 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.1e03fcc93a828fc1584b8aa516425151@localhost> #3631: Overload the Prelude iterate to support list input ------------------------------+--------------------------------------------- Reporter: shelbymoore3 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by shelbymoore3): Another correction, I need to use (++) append operation, not cons (:). {{{ iterate :: ([a] -> [a]) -> [a] -> [a] iterate f x = iterate f (x ++ (f x)) -- iterate f x == [x, f x, f (f x), ...] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 04:55:18 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 04:31:30 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.63013ebfe78fd2681b7fa3e124a494ad@localhost> #3631: Overload the Prelude iterate to support list input ------------------------------+--------------------------------------------- Reporter: shelbymoore3 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by shelbymoore3): Note scanl is more concise for fibs, but iterate is more general. fibs3 = 0 : scanl (+) 1 fibs -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 04:55:59 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 04:32:11 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.f52cf2963c6814771ffaaefc0376f45f@localhost> #3631: Overload the Prelude iterate to support list input ------------------------------+--------------------------------------------- Reporter: shelbymoore3 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by shelbymoore3): {{{ fibs = 0 : scanl (+) 1 fibs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 06:19:07 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 05:55:35 2009 Subject: [GHC] #3636: ghc --make sends progress output to stderr Message-ID: <041.ed5db1080b9d405db642a9233ac01378@localhost> #3636: ghc --make sends progress output to stderr -----------------------------+---------------------------------------------- Reporter: ab | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This is a relatively minor problem, but it is really annoying. Running {{{ghc --make}}} generates progress output on the standard error stream rather than the usual standard out. For example, lines such as the following appear on stderr: {{{ [ 1 of 13] Compiling Poly ( tools/mackerel/Poly.hs, Poly.o ) [ 2 of 13] Compiling Space ( tools/mackerel/Space.hs, Space.o ) }}} Could you please consider changing this so that progress output goes to stdout and only actual errors go to stderr? Without this, it is much harder to quieten the output from ghc but still see actual errors, and various build system tools incorrectly identify the progress output as error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 06:27:40 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 06:03:53 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.22193a0943ff18a14d24812d3decf777@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Thanks for the suggestion, but if you would like to propose changes to the libraries, please see: http://www.haskell.org/haskellwiki/Library_submissions However, a few things come to mind with your proposed change: * If you did change the Prelude `iterate` rather than adding a new function, then you would probably break lots of code * Your definition retains the whole list, so could cause space leaks * `last` takes time linear in the length of its input, so performance where you want the last element (as current uses of `iterate` do) will not be good -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 07:00:33 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 06:36:47 2009 Subject: [GHC] #3541: Allow local foreign imports In-Reply-To: <044.f182d5c0327086f8b5193630cf333bb0@localhost> References: <044.f182d5c0327086f8b5193630cf333bb0@localhost> Message-ID: <053.249fb789ed7aaeb861ba8364ecbdf378@localhost> #3541: Allow local foreign imports ---------------------------------+------------------------------------------ Reporter: mokus | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (FFI) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: Unknown => Moderate (1 day) * milestone: 6.14.1 => _|_ Comment: Let's leave this as an unmilestoned feature request for now. It's something that a contributor could tackle. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 07:01:46 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 06:37:58 2009 Subject: [GHC] #3545: As-patterns for type signatures In-Reply-To: <053.fe8bf7158bc08565495d5ddfb70742d3@localhost> References: <053.fe8bf7158bc08565495d5ddfb70742d3@localhost> Message-ID: <062.30b4284b18bf7c4f60cba4b33d4a762d@localhost> #3545: As-patterns for type signatures ----------------------------------------+----------------------------------- Reporter: LouisWasserman | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonmar): * milestone: 6.14.1 => _|_ Comment: Let's leave this as an unmilestoned feature request. It needs a lot more discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 07:02:07 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 06:38:23 2009 Subject: [GHC] #3632: lift restrictions on records with existential fields, especially in the presence of class constraints In-Reply-To: <047.bdd2c439db336bced650a9d8503aba8e@localhost> References: <047.bdd2c439db336bced650a9d8503aba8e@localhost> Message-ID: <056.b94c0b609d8d780cb033ea209c4bcfa3@localhost> #3632: lift restrictions on records with existential fields, especially in the presence of class constraints ----------------------------------------------------+----------------------- Reporter: eflister | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: existential records accessor update | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------------+----------------------- Changes (by simonpj): * difficulty: => Unknown Old description: > the attached file demos the use of a record with an existential field > with a class constraint. it shows several cases where lifting the > current restrictions on accessing and updating this field would be both > well-defined and useful. > > here is the record definition; the dur field is existential, but > constrained to be in class NoteDur. > > {{{ > data Note = forall x . NoteDur x => Note { > midiNum :: Int -- 0-255 > , vel :: Int -- 0-255 > , chan :: Int -- 0-15 > , measure :: Integral a => a > , beat :: Int > , subdiv :: RealFrac a => a -- % of beat > , dur :: x > } > }}} > > here is a walk through of places in the code where the current > restrictions are unnecessary and intrusive: > > lines 64-95 -- these functions wouldn't be necessary if record update > syntax were enabled for both existential and non-existential fields. i > know 6.12 introduces it for non-existentials, but i don't see why it > isn't also possible for existential fields (even without a class > constraint). lines 33-35 and 60 show how much nicer it is to use regular > updater syntax in this case. > > the same is true for existential accessors when there is a class > constraint -- there's no need to restrict this situation because the > accessor can have type: > fieldName :: (SomeClass x) => Record -> x > line 142 shows a case where this would be very nice to have. > > line 100 + 107 -- the foralls could be implicit (maybe offer an extention > that would allow them to be implicit) > > lines 134-136 compared to 138-139 show how additional factoring could be > achieved if one were allowed to pattern match on the type of an > existential with class constraints. > > lines 124-127 show how it would be nice to have existential classes > > lastly, allow curried updater functions: > (rec {field = }) 5 > instead of > (\x -> (rec {field = x})) 5 New description: the attached file demos the use of a record with an existential field with a class constraint. it shows several cases where lifting the current restrictions on accessing and updating this field would be both well- defined and useful. here is the record definition; the dur field is existential, but constrained to be in class NoteDur. {{{ data Note = forall x . NoteDur x => Note { midiNum :: Int -- 0-255 , vel :: Int -- 0-255 , chan :: Int -- 0-15 , measure :: Integral a => a , beat :: Int , subdiv :: RealFrac a => a -- % of beat , dur :: x } }}} here is a walk through of places in the code where the current restrictions are unnecessary and intrusive: 1. lines 64-95 -- these functions wouldn't be necessary if record update syntax were enabled for both existential and non-existential fields. i know 6.12 introduces it for non-existentials, but i don't see why it isn't also possible for existential fields (even without a class constraint). lines 33-35 and 60 show how much nicer it is to use regular updater syntax in this case. 2. Line 142. The same is true for existential accessors when there is a class constraint -- there's no need to restrict this situation because the accessor can have type: {{{ fieldName :: (SomeClass x) => Record -> x }}} line 142 shows a case where this would be very nice to have. 3. line 100 + 107 -- the foralls could be implicit (maybe offer an extention that would allow them to be implicit) 4. lines 134-136 compared to 138-139 show how additional factoring could be achieved if one were allowed to pattern match on the type of an existential with class constraints. 5. lines 124-127 show how it would be nice to have existential classes 6. lastly, allow curried updater functions: `(rec {field = }) 5` instead of `(\x -> (rec {field = x})) 5` Comment: Brief responses. 1. It's not all that simple; if a record had two existential fields (e.g. `dur1,dur2::x`), you'd have to update them both simultaneously. But the rule could, and probably should, be: if the desugared version typechecks, so should the record-update form. So, yes. 2. Either I misunderstand you, or this is unsound. Remember, the type 'x' is unknown, so it can't be supplied by the caller. So, as far as I can see this is a non-starter. 3. This is already possible {{{ data ModDur where Dotted :: NoteDur x => x -> ModDur Triplet :: DurBase -> ModDur }}} 4. I don't understand this at all. In your example {{{ quarters (x y) = quarters y * case x of }}} what are you expecting 'x' to be bound to? The constructor itself? If so, you are way beyond Haskell. Check out [http://www- staff.it.uts.edu.au/~cbj/patterns/ Barry Jay's excellent work]. 5. I have no idea what you mean here. 6. Quite possible, along the lines of tuple sections. The complexity/benefit ratio is debatable; my nose says "not quite worth it" but I'd be interested to know what others think. So for me (1) is the thing that would be worth fixing. I remember spending a while thinking about doing this a year ago, but I didn't do it for some reason. I think it might have been to do with generating sensible error messages. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 07:11:51 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 06:48:02 2009 Subject: [GHC] #3548: test T3294 incorrectly reported as error for unregistered build In-Reply-To: <045.3508f93b8c2d71a124ee09b2c47fcd9e@localhost> References: <045.3508f93b8c2d71a124ee09b2c47fcd9e@localhost> Message-ID: <054.91009b2e612e6a7361301584a29d25b0@localhost> #3548: test T3294 incorrectly reported as error for unregistered build ---------------------------------+------------------------------------------ Reporter: dterei | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Test Suite | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T3294 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: igloo => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 07:16:39 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 06:52:53 2009 Subject: [GHC] #3583: Default view patterns In-Reply-To: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> References: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> Message-ID: <051.7b3903a5bf5abbb059e093c50ae5477f@localhost> #3583: Default view patterns ---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: Unknown => Moderate (1 day) * milestone: 6.14.1 => _|_ Comment: Feature requests are unmilestoned until we decide to do them. This is also a task that a contributor could tackle. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 3 18:01:09 2009 From: trac at galois.com (GHC) Date: Tue Nov 3 17:37:25 2009 Subject: [GHC] #3637: ./configure doesn't understand Gentoo's build/host/target Message-ID: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> #3637: ./configure doesn't understand Gentoo's build/host/target -----------------------------+---------------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.1 RC1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Apparently there are several styles in how to write your build/host/target variables. In Gentoo they look like this for my amd64 {{{x86_64-pc-linux-gnu}}} which doesn't play well with the current build system. Default {{{./configure}}} execution in Gentoo ebuilds will pass the following flags: {{{ ./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man \ --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc \ --localstatedir=/var/lib --libdir=/usr/lib64 --build=x86_64-pc-linux- gnu }}} Which results in: {{{ checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... given 6.12.0.20091010 checking for ghc... /usr/bin/ghc checking version of ghc... 6.10.4 Target platform inferred as: x86_64-unknown-linux Unknown vendor linux }}} So we sed it like this: {{{ build=`echo "$build" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'` host=`echo "$host" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'` target=`echo "$target" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'` }}} but of course we would prefer not to have to handle this specially. That is, the {{{vendor}}} is {{{pc}}} and the {{{OS}}} is {{{linux-gnu}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 02:12:23 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 01:48:32 2009 Subject: [GHC] #3638: Redundant signature required with RULES and GADTs Message-ID: <041.a5ceb666d94c0fd232b5a23718e1981c@localhost> #3638: Redundant signature required with RULES and GADTs -----------------------------+---------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.13 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Here is a small program: {{{ data T a where TInt :: T Int foo :: T Int -> Int foo TInt = 0 {-# RULES "foo" forall x. foo x = case x of { TInt -> 0 } #-} }}} GHC complains: {{{ GADT pattern match with non-rigid result type `t' Solution: add a type signature for the entire case expression In a case alternative: TInt -> 0 In the expression: case x of { TInt -> 0 } When checking the transformation rule "foo" }}} And indeed, changing the rule to {{{ {-# RULES "foo" forall x. foo x = case x of { TInt -> 0 } :: Int #-} }}} works. The signature is redundant, though, because the type of the case is determined by the type of the rule head. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 03:38:55 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 03:15:05 2009 Subject: [GHC] #3638: Redundant signature required with RULES and GADTs In-Reply-To: <041.a5ceb666d94c0fd232b5a23718e1981c@localhost> References: <041.a5ceb666d94c0fd232b5a23718e1981c@localhost> Message-ID: <050.28f5ac63b1953657ca6570ac0287f37c@localhost> #3638: Redundant signature required with RULES and GADTs ----------------------------------------+----------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Ha, well at least the error message was on target. This'll be fixed when we switch to the [http://research.microsoft.com/~simonpj/papers/gadt OutsideIn algorithm] for inference. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 04:40:12 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 04:16:27 2009 Subject: [GHC] #3639: GHC 6.10.1 fails to build with "../includes/ghcautoconf.h: No such file or directory" Message-ID: <050.66ce4fb5ee0d3fd9e206b6a3d851462b@localhost> #3639: GHC 6.10.1 fails to build with "../includes/ghcautoconf.h: No such file or directory" -----------------------------+---------------------------------------------- Reporter: spookylukey | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I am attempting to build GHC 6.10.1 on a CentOS 4.5 machine. At the 'make install' stage, I get this error: {{{ /home/build/build/ghc-6.10.1/libraries/cabal-bin /home/build/local/bin/ghc /home/build/build/ghc-6.10.1/libraries/bootstrapping.conf build --distpref dist-stage1 --ghc-option=-H32m --ghc-option=-O --ghc- option=-H32m --ghc-option=-O Preprocessing executables for ghc-bin-6.10.1... Building ghc-bin-6.10.1... In file included from Main.hs:13:0: /home/build/local/lib/ghc-6.10.4/ghc-6.10.4/include/HsVersions.h:23:0: ../includes/ghcautoconf.h: No such file or directory make[2]: *** [build.stage.1] Error 1 make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 }}} This was also reported here http://www.haskell.org/pipermail/glasgow- haskell-bugs/2008-November/015981.html but with no follow up. I am building using GHC 6.10.4 (which I cannot use for other purposes because of bug #3179). I have to compile from source because of #2211 I already have GHC 6.8.3 built, so I will uninstall 6.10.4 to try to build 6.10.1 with 6.8.3 instead, and report back here if I have success. Otherwise, as GHC 6.10.1 is apparently the only version of GHC that I can use (library dependencies rule out 6.8.*), I would really appreciate help on fixing this or a workaround! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 04:53:08 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 04:29:20 2009 Subject: [GHC] #2034: In FilePath, current directory should be ".", not "" In-Reply-To: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost> References: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost> Message-ID: <053.2857be1e0ae2b0e1bc46da0b88bdfa2a@localhost> #2034: In FilePath, current directory should be ".", not "" ----------------------------------+----------------------------------------- Reporter: igloo | Owner: neil Type: proposal | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by simonmar): Patch version 2 added, after discussion on the libraries list. The new patch description is: {{{ Wed Nov 4 09:51:09 GMT 2009 Simon Marlow * The current directory is ".", not "" (GHC bug #2034) (patch version 2) So now splitFileName "foo" = ("./", "foo") which gives us the additional property that > Valid x => isValid (fst (splitFileName x)) This property is important, because it means that we can pass the result of takeDirectory to any of the functions in System.Directory, whereas previously we would have to check for the empty case first. After discussion on the libraries list, I removed the second part of the original change: "." x = x This small bit of normalisation was there to ensure that the property > Valid x => uncurry (splitFileName x) == x still held. However, it was arguably inconsistent (see the discussion). Now this property has an exception: > Valid x => uncurry () (splitFileName x) == x || fst (splitFileName x) == "./" This is a small price to pay to gain the new property above. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 05:21:28 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 04:57:40 2009 Subject: [GHC] #3639: GHC 6.10.1 fails to build with "../includes/ghcautoconf.h: No such file or directory" In-Reply-To: <050.66ce4fb5ee0d3fd9e206b6a3d851462b@localhost> References: <050.66ce4fb5ee0d3fd9e206b6a3d851462b@localhost> Message-ID: <059.61146bf0f1038f481d82bac04a554ff8@localhost> #3639: GHC 6.10.1 fails to build with "../includes/ghcautoconf.h: No such file or directory" ------------------------------+--------------------------------------------- Reporter: spookylukey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by spookylukey): Cannot build with 6.8.3 either: {{{ Configuring ghc-6.10.1... cabal-bin: At least the following dependencies are missing: Cabal -any, base <3, filepath >=1 && <1.2, haskell98 -any, hpc -any, template-haskell -any, unix -any make[2]: *** [boot.stage.2] Error 1 make[2]: Leaving directory `/home/build/build/ghc-6.10.1/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/home/build/build/ghc-6.10.1' make: *** [bootstrap2] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 05:59:15 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 05:36:35 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.ab3f9e0c1d1acf19ca9ed05859d0acaa@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by guest): * cc: pierreetienne.meunier@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 06:23:22 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 06:00:03 2009 Subject: [GHC] #3640: NamedFieldPuns broken in where clauses Message-ID: <042.e30183e327673937ec9a9f1dede6ed45@localhost> #3640: NamedFieldPuns broken in where clauses ---------------------------+------------------------------------------------ Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Severity: major Keywords: NamedFieldPuns | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---------------------------+------------------------------------------------ The attached file compiles fine under GHC 6.10. However, under 6.12, it produces the error {{{ BadPun.hs:8:17: Conflicting definitions for `pun-right-hand-side' In the binding group for: pun-right-hand-side, pun-right-hand-side, pun-right-hand-side }}} Note that this affects the named field puns only in the where clause of {{{badPun}}}; {{{goodPun}}}, which uses them in the LHS of a top-level definition, does not have this problem. A possibly interesting additional note is that if you change {{{Record{f1,f2,}}}... to {{{Record{f1=f1,f2,}}}..., you'll find that you get this error message instead: {{{ BadPun.hs:8:23: Conflicting definitions for `pun-right-hand-side' In the binding group for: f1, pun-right-hand-side, pun-right-hand-side }}} Changing {{{f2}}} to {{{f2=f2}}} as well makes the error go away, presumably because there's now only one {{{pun-right-hand-side}}} defined. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 07:34:12 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 07:10:25 2009 Subject: [GHC] #3639: GHC 6.10.1 fails to build with "../includes/ghcautoconf.h: No such file or directory" In-Reply-To: <050.66ce4fb5ee0d3fd9e206b6a3d851462b@localhost> References: <050.66ce4fb5ee0d3fd9e206b6a3d851462b@localhost> Message-ID: <059.0ad3f49bc88fd939f9cb755b4353c8d6@localhost> #3639: GHC 6.10.1 fails to build with "../includes/ghcautoconf.h: No such file or directory" ---------------------------------+------------------------------------------ Reporter: spookylukey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Could this be related to #2619? (I have no idea, but it looks vaguely similar.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 08:44:36 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 08:21:04 2009 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> Message-ID: <060.09e7790efae9912f81fa0aa823c89e30@localhost> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by kolmodin): * cc: kolmodin@gentoo.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 09:10:14 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 08:46:22 2009 Subject: [GHC] #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? Message-ID: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? -----------------------------+---------------------------------------------- Reporter: Aviator | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I use Ctrl+L a lot to clear the terminal. The clear screen feature is incorporated in various Unix shells, also programming language interpreters like Python. This worked in 6.8.x as I can remember, but not in 6.10.x. I don't know if someone has posted a similar bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 09:17:58 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 08:54:07 2009 Subject: [GHC] #3548: test T3294 incorrectly reported as error for unregistered build In-Reply-To: <045.3508f93b8c2d71a124ee09b2c47fcd9e@localhost> References: <045.3508f93b8c2d71a124ee09b2c47fcd9e@localhost> Message-ID: <054.8c1b41ad0f2093f7b0f5c6d48b3c5788@localhost> #3548: test T3294 incorrectly reported as error for unregistered build ---------------------------------+------------------------------------------ Reporter: dterei | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Test Suite | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T3294 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed {{{ Tue Nov 3 04:11:26 PST 2009 Simon Marlow * Only run T3294 if we have an NCG (#3548) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 09:40:30 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 09:16:39 2009 Subject: [GHC] #3441: readProcess ... (exit 11): failed In-Reply-To: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> References: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> Message-ID: <054.8e3bec6a3fb5a54f82aa98ea0cce73a3@localhost> #3441: readProcess ... (exit 11): failed ------------------------------------+--------------------------------------- Reporter: Andriy | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: libraries/process | Version: 6.10.3 Severity: major | Resolution: Keywords: readProcess exit 11 | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------------------+--------------------------------------- Changes (by Andriy): * status: closed => reopened * resolution: worksforme => Comment: Simon, I finally got a core dump. Attaching it. However this time the program failed with exit code 139. The core dump is however 95 Mb. Is it Ok to attach it to the ticket or do you want me to upload it somewhere else? Thanks, Andriy -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 09:47:21 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 09:23:31 2009 Subject: [GHC] #3642: GHC does not build using the Haskell Platform on Windows Message-ID: <047.f7dc4955002df3f44f0e5e850b71a0c9@localhost> #3642: GHC does not build using the Haskell Platform on Windows -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Build System | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- We still have issues with paths containing spaces in the build system. I have fixed some of them, but there are more (that are not easy to fix). The current bug I ran into is in `rules/distdir-way-opts.mk` where we make the HSC2HS_OPTS by prepending --cflag/--lflag to the beginning of CC_OPTS and LD_OPTS respectively, that doesn't know where the word breaks in CC_OPTS/LD_OPTS are supposed to be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 10:57:21 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 10:33:30 2009 Subject: [GHC] #3624: Parse fails when foreign import declarations contain path information (like those generated by c2hs). In-Reply-To: <048.e18b59101dfab8616bf0f6866665ebfc@localhost> References: <048.e18b59101dfab8616bf0f6866665ebfc@localhost> Message-ID: <057.5b29b9c625a5ca0047e99f20327a0de1@localhost> #3624: Parse fails when foreign import declarations contain path information (like those generated by c2hs). ----------------------------------+----------------------------------------- Reporter: twadleigh | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler (Parser) | Version: 6.12.1 RC1 Severity: major | Resolution: Keywords: FFI, c2hs | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 11:39:05 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 11:15:16 2009 Subject: [GHC] #3639: GHC 6.10.1 fails to build with "../includes/ghcautoconf.h: No such file or directory" In-Reply-To: <050.66ce4fb5ee0d3fd9e206b6a3d851462b@localhost> References: <050.66ce4fb5ee0d3fd9e206b6a3d851462b@localhost> Message-ID: <059.b76d1e8a1c0e415989eec90feccb4a58@localhost> #3639: GHC 6.10.1 fails to build with "../includes/ghcautoconf.h: No such file or directory" ---------------------------------+------------------------------------------ Reporter: spookylukey | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by spookylukey): * status: new => closed * resolution: => duplicate Comment: It looks like the original bug report is the same as #2619. I don't know about the second part (the fact that I couldn't build 6.10.1 with 6.8.3. It's possibly due to additional libraries that I installed, above and beyond the base 6.8.3 distribution. I have now succeeded in building 6.10.1 (via building 6.6.1 !), and I don't have time to investigate this second part. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 11:47:18 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 11:23:29 2009 Subject: [GHC] #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? In-Reply-To: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> References: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> Message-ID: <055.256afde1f905941157c858b133c03677@localhost> #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? ------------------------------+--------------------------------------------- Reporter: Aviator | Owner: judah Type: bug | Status: assigned Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by judah): * status: new => assigned * owner: => judah Comment: Ctrl-L works for me in 6.10.3, which should behave the same as 6.10.4. A few questions: - What operating system are you using? - What terminal environment are you using? (xterm, urxvt, Windows console, etc.) - If you run `infocmp` in the environment where you run ghci, what is the output? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 11:49:45 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 11:25:56 2009 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> Message-ID: <055.c165ffa323ae9e5683912ee601eb3d79@localhost> #3472: Porting through .hc files broken ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:3 ksf]: > Solution 2 to issue 2 (running hsc2hs with the target's headers on the host) needs a cross-compiler, at least if the system's bytesizes differ. Otherwise, offsetof is going to return borkage, even if given the right headers. In the past we've avoided using `hsc2hs` in parts of the libraries that are required by the bootstrap for exactly this reason. I think we recently regressed in this area since I started using `System.Posix` stuff to implement `System.Directory`; my humble apologies. It was fragile to start with though. We either have to come up with a solution for using hsc2hs (take the intermediate C files to the target and compile/run them?) or convert .hsc files to autoconf + CPP (yeuch). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 11:59:28 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 11:36:00 2009 Subject: [GHC] #3640: NamedFieldPuns broken in where clauses In-Reply-To: <042.e30183e327673937ec9a9f1dede6ed45@localhost> References: <042.e30183e327673937ec9a9f1dede6ed45@localhost> Message-ID: <051.5bba4e6be34abd44373bd9a62aba46bb@localhost> #3640: NamedFieldPuns broken in where clauses -------------------------------+-------------------------------------------- Reporter: cjs | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Severity: major | Resolution: Keywords: NamedFieldPuns | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 13:57:57 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 13:34:05 2009 Subject: [GHC] #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications In-Reply-To: <044.e3702794ded3f91904f114f506e31845@localhost> References: <044.e3702794ded3f91904f114f506e31845@localhost> Message-ID: <053.7c7e0ecd2f2ac8dc6b0e3da07b71741d@localhost> #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: Severity: trivial | Resolution: Keywords: Typeable, efficiency | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------+-------------------------------------- Old description: > Data.Typeable: Easily make Typeable keys pure(used in Eq), so that > Typeable keys don?t vary from run to run. This permits an efficient > storage of the keys in files and to be transmitted trough communications > as well as processed without loss of efficiency. Actually gaining > efficiency probably, since the keys caches are not necessary. > > Currently, whenever the user needs to communicate types, he must transmit > the full string name for each type. Moreover, in the reception, the > programmer is forced to handle these full string keys for mapping types > to handlers, in equality checks etc. if the type keys are pure, the > efficiency of key handling can be keept across communications. > > short description of task: > Istead of using a Hash( stringType, generatedKey) use hashString > (string-of-type) > > Long description: > > 1) drop the cache > drop newKey > > 2) use instead the expression: > > Key $ hashString str > > whenever a new key is needed > > from the package Data.HashTable: > hashString :: String -> Int > > the key obtained is pure so: > > 3) drop the "IO" in typeRepKey signature New description: Data.Typeable: Easily make Typeable keys pure(used in Eq), so that Typeable keys don?t vary from run to run. This permits an efficient storage of the keys in files and to be transmitted trough communications as well as processed without loss of efficiency. Actually gaining efficiency probably, since the keys caches are not necessary. Currently, whenever the user needs to communicate types, he must transmit the full string name for each type. Moreover, in the reception, the programmer is forced to handle these full string keys for mapping types to handlers, in equality checks etc. if the type keys are pure, the efficiency of key handling can be keept across communications. short description of task: Istead of using a Hash( stringType, generatedKey) use hashString (string- of-type) Long description: 1) drop the cache; drop newKey 2) use instead the expression: {{{ Key $ hashString str }}} whenever a new key is needed from the package `Data.HashTable`: {{{ hashString :: String -> Int }}} the key obtained is pure so: 3) drop the "IO" in `typeRepKey` signature Comment (by simonpj): Something that does a better job of `TypeRep` would certainly be welcome: 1. Those `unsafePerformIO`s are embarrassing. And indeed they lead to trouble if (as can happen in GHCi or Template Haskell) you get two instances of that hash table. 2. If you were (naughtily) to serialise one of those keys into a file, they'd be wrong when you read them back in. But this never happens (see the `Show` instance for `TypeRep`: what you serialise is the `TypeRep` data structure ''without'' the keys. When it's read back in a new set of keys is constructed. (Actually there is no `Read` instance but that is what would happen if there were.) The keys are ''solely'' used to speed up comparison. Comparing the data structures and strings is the underlying ground truth. So it's perfectly fine for keys to vary from run to run. However, it's vital that if two `TypeRep`s with the same key really are equal. Hashing the string to an `Int` does not guarantee that. To be sure, you'd need a lot more bits, something like the fingerprints we store in interface files. See `compiler/utils/Fingerprint.hsc`. I'm not sure about the best approach. The baseline is: * Compare `TypeRep` structures as one would any data structure. * At a `TyCon` compare the `String` representation of the type constructor. An alternative, that would do the fingerprint stuff once and for all at compile time, is: * Compare `TypeRep` structures as one would any data structure. * At a `TyCon` compare the fingerprint of the string representation of the `TyCon` Neither of these give constant-time comparison of `TypeRep`s, but I doubt that such comparisons are going to be in the inner loop of any program. And both fix (1) above Other things to think about: * Surely `TypeRep` should be in `Ord`! * We should check that the `String` used to make a `Typeable.TyCon` includes the full, versioned, package Id. * Even then I'm slightly worried. The expection is that `foo-3.2:Foo.T` uniquely defines the entire structure of `T`. But what if you forget to bump the package version? * More subtly what if `T` is defined thus: {{{ data T = MkT S -- S comes from package bar }}} Then if S's definition in package `bar` changes, but package `foo` is unchanged, the `TyCon` for `T` should really change too. Otherwise you might serialise a value of type `T` into a file along with its `TypeRep`, and try to read it back in with the wrong deserialiser. I'm not sure whether the package versioning rules force `foo`'s version to be bumped. Maybe we want `foo`'s new `PackageId`? * But in fact the `PackageId` is perhaps ''too'' fine-grained, becuase it changes whenever anything in package `foo` changes. We really only want the `Typeable.TyCon` for `T` to change when the structure of `T` (transitively) changes. Aha! We already have fingerprints for that, used for versioning in interface files. So perhpas, once we've calculated `T`'s fingerprint we can use that in the `Typeable.TyCon` for `T`. That seems to me to be best story. We could do with someone who'd like to follow these things up. Dynamic typing is important. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 15:12:51 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 14:48:59 2009 Subject: [GHC] #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? In-Reply-To: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> References: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> Message-ID: <055.e5f882401f68c0e018012d0e125d9b08@localhost> #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? ------------------------------+--------------------------------------------- Reporter: Aviator | Owner: judah Type: bug | Status: assigned Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by Aviator): Not working for me when I used 6.10.4. > What operating system are you using? Ubuntu 9.10. > What terminal environment are you using? GNOME's default terminal. > If you run infocmp in the environment where you run ghci, what is the output? {{{ $ infocmp # Reconstructed via infocmp from file: /lib/terminfo/x/xterm xterm|X11 terminal emulator, am, bce, km, mc5i, mir, msgr, npc, xenl, colors#8, cols#80, it#8, lines#24, pairs#64, acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l, clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A, cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS, invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=\177, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\EO2P, kf14=\EO2Q, kf15=\EO2R, kf16=\EO2S, kf17=\E[15;2~, kf18=\E[17;2~, kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~, kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~, kf25=\EO5P, kf26=\EO5Q, kf27=\EO5R, kf28=\EO5S, kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~, kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~, kf35=\E[23;5~, kf36=\E[24;5~, kf37=\EO6P, kf38=\EO6Q, kf39=\EO6R, kf4=\EOS, kf40=\EO6S, kf41=\E[15;6~, kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~, kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~, kf48=\E[24;6~, kf49=\EO3P, kf5=\E[15~, kf50=\EO3Q, kf51=\EO3R, kf52=\EO3S, kf53=\E[15;3~, kf54=\E[17;3~, kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~, kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~, kf61=\EO4P, kf62=\EO4Q, kf63=\EO4R, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El, memu=\Em, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM, rin=\E[%p1%dT, rmacs=\E(B, rmam=\E[?7l, rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[27m, rmul=\E[24m, rs1=\Ec, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7, setab=\E[4%p1%dm, setaf=\E[3%p1%dm, setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m, setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m, sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\E(0%e\E(B%;, sgr0=\E[m\E(B, smacs=\E(0, smam=\E[?7h, smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m, smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd, }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 16:06:34 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 15:42:50 2009 Subject: [GHC] #3637: ./configure doesn't understand Gentoo's build/host/target In-Reply-To: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> References: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> Message-ID: <056.97559bd2728c8d6f48c776ffe66e47f5@localhost> #3637: ./configure doesn't understand Gentoo's build/host/target ------------------------------+--------------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Severity: minor | Resolution: Keywords: regression | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by slyfox): * keywords: => regression * cc: slyfox@community.haskell.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 4 17:56:10 2009 From: trac at galois.com (GHC) Date: Wed Nov 4 17:32:20 2009 Subject: [GHC] #1735: unused binding changes program behaviour In-Reply-To: <044.165e86ea1e61301d33d53cf154829fac@localhost> References: <044.165e86ea1e61301d33d53cf154829fac@localhost> Message-ID: <053.58cfdfc156e0e4577d40b40871a90f98@localhost> #1735: unused binding changes program behaviour -------------------------------------------+-------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_run/T1735 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by simonpj): * testcase: => typecheck/should_run/T1735 * status: new => closed * resolution: => fixed Comment: This one has been in my to-do list for a long time, and I've finally gotten around to looking at it again. The key declarations in `Xml.hs` read thus: {{{ class (Data XmlD a) => Xml a where ... instance Xml String where ... -- The Xml [a] context is a bit scary, but if we don't -- have it then GHC complains about overlapping instances instance (Xml a, Xml [a]) => Xml [a] where .... }}} Wihtout the "scary" `Xml [a]` in the context, GHC 6.8 rejected the latter instance thus {{{ Xml.hs:128:0: Overlapping instances for Xml [a] arising from the superclasses of an instance declaration at Xml.hs:128:0 Matching instances: instance [overlap ok] (Xml a) => Xml [a] -- Defined at Xml.hs:(128,0)-(136,68) instance [overlap ok] Xml String -- Defined at Xml.hs:(138,0)-(142,26) }}} But that got fixed when I fixed #1470; see `Note [Recursive superclasses]` in `TcInstDcls`. So now the program works fine without the scary bit, and with or without `-DFOO`. If you have the scary bit, then it's unsurprising that things go badly wrong. The details are: * The superclass for the `Xml [a]` dictionary being constructed is gotten by superclass-selection from the `Xml [a]` dictionary passed in. {{{ $fXml dx dxs = MkD ($p2 dxs) ... }}} * When the instance declaration is used, you get a recursive dictionary, thus {{{ d :: Xml [YesOrNo] d = $fXml[] d' d }}} * So every `Xml [a]` dictionary has a superclass that is exactly bottom. The odd behaviour of the unused definition arises thus: * It just so happens that the unused binding gives rise to the need for an XML [YesOrNo] dictionary. It isn't used, but when the contraints simplifier needs a `Data XMLD [YesOrNo]` dictionary, it can get it from the (bogus) dictionary it has lying around. If you write instance declarations like that, wierd stuff is going to happen to you. Closing this ticket! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 07:10:41 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 06:46:47 2009 Subject: [GHC] #3604: Use of template-haskell is broken with shared libraries In-Reply-To: <044.80a0861c1656d96474979b0b59adc47b@localhost> References: <044.80a0861c1656d96474979b0b59adc47b@localhost> Message-ID: <053.06e4f2e1fe75b9daf8b104c881c19fa6@localhost> #3604: Use of template-haskell is broken with shared libraries ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Fixed: {{{ Wed Nov 4 08:30:39 PST 2009 Simon Marlow * #3604: treat TH with -dynamic in the same way as -prof }}} It's not entirely satisfactory because you have to compile two ways, just like with `-prof`. Cabal handles this behind the scenes. I'm not sure it's possible to fix it properly: even if GHC were dynamically linked, then we'd be in the same situation for static object files. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 07:11:40 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 06:47:49 2009 Subject: [GHC] #3439: Improve the setup for ticky In-Reply-To: <046.97ec1b5f2b20c06c8559b26055a95a61@localhost> References: <046.97ec1b5f2b20c06c8559b26055a95a61@localhost> Message-ID: <055.46960975fdc05e1bdc0899f43c006e9a@localhost> #3439: Improve the setup for ticky ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: feature request => merge Comment: Fixed: {{{ Wed Nov 4 06:55:07 PST 2009 Simon Marlow * Finish #3439: -ticky implies -debug at link time; the ticky "way" has gone Thu Nov 5 02:15:03 PST 2009 Simon Marlow * Update docs on ticky-ticky profiling }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 07:35:16 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 07:11:21 2009 Subject: [GHC] #3234: foldr/single no longer firing in GHC 6.10 In-Reply-To: <041.6f78ca9107f6c0f52fc046199711a2f3@localhost> References: <041.6f78ca9107f6c0f52fc046199711a2f3@localhost> Message-ID: <050.a24ce5b083421cbc632ea8a7abdf0fea@localhost> #3234: foldr/single no longer firing in GHC 6.10 -----------------------------------------------+---------------------------- Reporter: r6 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: simplCore/should_compile/T3234 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------+---------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/T3234 * status: new => closed * resolution: => fixed Comment: I fixed this as part of the big INLINE patch. The relevant note is in `Desugar.lhs`, namely `Note [Desugaring RULE left hand sides]`. I've added a test too. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 09:35:22 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 09:11:29 2009 Subject: [GHC] #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications In-Reply-To: <044.e3702794ded3f91904f114f506e31845@localhost> References: <044.e3702794ded3f91904f114f506e31845@localhost> Message-ID: <053.e912f568154bafedf8f2a68ca6df4343@localhost> #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: Severity: trivial | Resolution: Keywords: Typeable, efficiency | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------+-------------------------------------- Comment (by simonmar): Replying to [comment:2 simonpj]: > Neither of these give constant-time comparison of `TypeRep`s, but I doubt that such comparisons are going to be in the inner loop of any program. And both fix (1) above Aren't such comparisons in the inner loop of SYB traversals? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 09:40:51 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 09:17:03 2009 Subject: [GHC] #3622: ghci ignores LANGUAGE TemplateHaskell pragma In-Reply-To: <044.7dfa5c40d61cba8b59351f570466f2ba@localhost> References: <044.7dfa5c40d61cba8b59351f570466f2ba@localhost> Message-ID: <053.bad33c18e6dfdc401c2f0705f98f4028@localhost> #3622: ghci ignores LANGUAGE TemplateHaskell pragma ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: dup of #3217 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 10:03:31 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 09:39:39 2009 Subject: [GHC] #3609: ar.exe: Bad file number In-Reply-To: <046.6971073bd0dd34bb84a681dc5bdcec98@localhost> References: <046.6971073bd0dd34bb84a681dc5bdcec98@localhost> Message-ID: <055.e15eb028f924a76a134d278dcadce445@localhost> #3609: ar.exe: Bad file number ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: #3201 wasn't fixed on the 6.10 branch, the fix is only in 6.12 and later. I'm not sure exactly why, perhaps it was an oversight. Re the testsuite, the download page says "If you unpack this tarball on top of the above then you will be able to run the testsuite.", or if you get the sources from darcs, then darcs-all automatically puts it in the right place. Which bit isn't clear? I'm closing this ticket as a dup of #3201; please open separate tickets for the latter two issues in simonpj's list. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 10:23:30 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 09:59:36 2009 Subject: [GHC] #3606: The Ord instance for unboxed arrays is very inefficient In-Reply-To: <046.5524abf7655d34a8f91d5dca7267dc7d@localhost> References: <046.5524abf7655d34a8f91d5dca7267dc7d@localhost> Message-ID: <055.c26afa585e550d33752c097d72867bab@localhost> #3606: The Ord instance for unboxed arrays is very inefficient -----------------------------------------+---------------------------------- Reporter: blarsen | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: array, performance, Ord | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -----------------------------------------+---------------------------------- Changes (by simonmar): * type: bug => run-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 10:29:17 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 10:05:22 2009 Subject: [GHC] #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications In-Reply-To: <044.e3702794ded3f91904f114f506e31845@localhost> References: <044.e3702794ded3f91904f114f506e31845@localhost> Message-ID: <053.dbc699d280cbb2396d3cc8b45c889e6a@localhost> #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: Severity: trivial | Resolution: Keywords: Typeable, efficiency | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------+-------------------------------------- Comment (by simonpj): Um, yes, that's true. I had forgotten that. But types are typically small. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 11:09:35 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 10:45:42 2009 Subject: [GHC] #3642: GHC does not build using the Haskell Platform on Windows In-Reply-To: <047.f7dc4955002df3f44f0e5e850b71a0c9@localhost> References: <047.f7dc4955002df3f44f0e5e850b71a0c9@localhost> Message-ID: <056.880902ed807fd9be1449a2fb639bfbc6@localhost> #3642: GHC does not build using the Haskell Platform on Windows ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Some fixes have been committed: {{{ Wed Nov 4 08:43:43 PST 2009 Simon Marlow * Fix some bugs to do with tools in paths containing spaces Thu Nov 5 06:13:10 PST 2009 Simon Marlow * Fix #3642: m GHC builds using the Haskell Platform }}} I still have a build failure when using `-split-objs`, which I'm trying to track down. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 11:33:42 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 11:10:01 2009 Subject: [GHC] #3605: Dll's freeze with -threaded In-Reply-To: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> References: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> Message-ID: <060.0506743d50ad81695c9c557f012982e3@localhost> #3605: Dll's freeze with -threaded ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): I had a nagging feeling I'd come across this before, and indeed the docs do have a section describing a lot of the problems with `DllMain()`: [http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html#id585039] However earlier on in that section the sample code still contains a `DllMain()` that calls `startupHaskell`, so we should fix that. Also the section on `DllMain` talks more about shutdown than startup, but both are dangerous (fortunately the example code it gives is correct). Neil, Lennart: could you check the docs I linked to above and see if you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 11:48:47 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 11:24:53 2009 Subject: [GHC] #3615: GHCi doesn't allow the use of imported data contructors In-Reply-To: <047.8819d6591abc7952ad9279636b532fe8@localhost> References: <047.8819d6591abc7952ad9279636b532fe8@localhost> Message-ID: <056.25159095c9c6e9e3813df4ac759d8608@localhost> #3615: GHCi doesn't allow the use of imported data contructors --------------------------------+------------------------------------------- Reporter: blamario | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | --------------------------------+------------------------------------------- Changes (by simonmar): * milestone: 6.14.1 => _|_ Comment: I think the docs are pretty clear: [http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive- evaluation.html#ghci-scope] Personally I think the chances of us being able to improve matters here are pretty slim. The solution that Simon suggests (keeping everything unless -O2 is on) would be even more strange than the current situation, IMO, and Duncan's suggestion is tricky to implement for a relatively small gain. Still, I'll leave the ticket open as an acknowledgment that the current situation is unsatisfying, and to act as a place to collect ideas. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 11:52:46 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 11:28:52 2009 Subject: [GHC] #3616: ghci crash from :l In-Reply-To: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> References: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> Message-ID: <056.f193e6121d3e801a7e82c2cfae0c4f29@localhost> #3616: ghci crash from :l -------------------------+-------------------------------------------------- Reporter: eflister | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: dup of #3153 (the most opt-reported GHC bug! we could have saved ourselves a lot of time by merging that fix into 6.10.4. oh well.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 12:00:05 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 11:36:13 2009 Subject: [GHC] #3615: GHCi doesn't allow the use of imported data contructors In-Reply-To: <047.8819d6591abc7952ad9279636b532fe8@localhost> References: <047.8819d6591abc7952ad9279636b532fe8@localhost> Message-ID: <056.0d36cf442dc2a2bd3db7003ff57cd545@localhost> #3615: GHCi doesn't allow the use of imported data contructors --------------------------------+------------------------------------------- Reporter: blamario | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | --------------------------------+------------------------------------------- Comment (by isaacdupree): this idea is possibly even worse than Duncan's, but: In simonpj's example, do inline 'f' because it's only used once -- but ALSO keep a copy of it, so that ghci people can at least call it. If that leads to bloat in even the compiled code, here is an even-weirder idea: keep a separate .hi and .o file for the stuff that's accessible from within the module (perhaps excluding the stuff that's exported, since it's in the other hi/o files that we already make) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 12:01:53 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 11:37:58 2009 Subject: [GHC] #3628: exceptions reported to stderr when they propagate past forkIO In-Reply-To: <045.1fd3d7941c00c82461fdc1db8e459688@localhost> References: <045.1fd3d7941c00c82461fdc1db8e459688@localhost> Message-ID: <054.9f9afcbb490bb20618d049c350f19e59@localhost> #3628: exceptions reported to stderr when they propagate past forkIO ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): So what do you suggest? I don't think we can propagate to the "main thread": there might not be one, in the case of a Haskell DLL. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 12:48:45 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 12:24:51 2009 Subject: [GHC] #3628: exceptions reported to stderr when they propagate past forkIO In-Reply-To: <045.1fd3d7941c00c82461fdc1db8e459688@localhost> References: <045.1fd3d7941c00c82461fdc1db8e459688@localhost> Message-ID: <054.e6c2247d43cf97598e4abc6ca503d2e4@localhost> #3628: exceptions reported to stderr when they propagate past forkIO ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): If we cannot propagate to parent threads then perhaps they should just be discarded. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 13:15:12 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 12:51:19 2009 Subject: [GHC] #3628: exceptions reported to stderr when they propagate past forkIO In-Reply-To: <045.1fd3d7941c00c82461fdc1db8e459688@localhost> References: <045.1fd3d7941c00c82461fdc1db8e459688@localhost> Message-ID: <054.e182c5c12b699651bb8857d336bcd15e@localhost> #3628: exceptions reported to stderr when they propagate past forkIO ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): In Erlang (see [Erlang's Exception Handling Revisited http://ftp.sunet.se/pub/lang/erlang/workshop/2004/exception.pdf]) processes can be informed when another process terminates, and that includes an exit term or exception. Apparently unhandled exceptions that terminate a process are also reported to a global error logger service provided by the runtime system. See figure 7. I'm not sure that any of this really helps. It seems to me that we have to decide if exceptions that terminate a thread are important or not. If they are then they must be thrown somewhere else, if they are not then they can be discarded. Reporting to stderr or a windows popup is some kind of intermediate judgement: "important enough to annoy the users with but not important enough to handle properly". Having the thread just die seems ok to me. If people want to be notified then they can already do that by adding an exception handler. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 14:17:42 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 13:53:47 2009 Subject: [GHC] #3616: ghci crash from :l In-Reply-To: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> References: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> Message-ID: <056.5fedf236697f7d2323d9a23271735cf0@localhost> #3616: ghci crash from :l --------------------------------+------------------------------------------- Reporter: eflister | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | --------------------------------+------------------------------------------- Changes (by eflister): * status: closed => reopened * type: bug => feature request * resolution: duplicate => Comment: sorry, i didn't search for dupes cuz the message said to report it and i didn't have time to dig through a large ticket system. should i re-enter the two suggestions above as FR's? i can't tell if they were addressed in the fix to 3153: -unify -X and pragma formats/error messages so that cut/paste is easy, etc -allow vertical tab structure of pragmas so they are easy to toggle with comments -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 5 14:36:03 2009 From: trac at galois.com (GHC) Date: Thu Nov 5 14:12:08 2009 Subject: [GHC] #3632: lift restrictions on records with existential fields, especially in the presence of class constraints In-Reply-To: <047.bdd2c439db336bced650a9d8503aba8e@localhost> References: <047.bdd2c439db336bced650a9d8503aba8e@localhost> Message-ID: <056.6646a7a29b620a64b391c06f45856cbf@localhost> #3632: lift restrictions on records with existential fields, especially in the presence of class constraints ----------------------------------------------------+----------------------- Reporter: eflister | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: existential records accessor update | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------------+----------------------- Comment (by eflister): wow, thanks for getting back to me so fast! > 1. if a record had two existential fields (e.g. `dur1,dur2::x`), you'd have to update them both simultaneously. ah, i see what you mean. 'dur1,dur2::x', is an assertion that dur1 and dur2 have the same type, even if that type is not concretely known (only that it is in class NoteDur). but if this were written 'dur1::x,dur2::y', with 'forall x y. NoteDur x, NoteDur y', then they could be independently updated, right, even though there are two existential fields? > 2. Either I misunderstand you, or this is unsound. Remember, the type 'x' is unknown, so it can't be supplied by the caller. So, as far as I can see this is a non-starter. i know you know what your'e talking about -- so i'm just not seeing something! :) but don't lots of functions have a type like this? all the caller needs to do is restrict itself to using methods of class SomeClass, it never has to know the underlying type. > 3. This is already possible > {{{ > data ModDur where > Dotted :: NoteDur x => x -> ModDur > Triplet :: DurBase -> ModDur > }}} oh ok, sorry, that worked! i hadn't seen that way (i don't fully grok GADTs). but it still seems like the following form would be more uniform/natural. {{{ data ModDur = NoteDur x => Dotted x | Triplet DurBase }}} and what about line 107? following the same approach you suggested, maybe something like: {{{ data Note where Note :: NoteDur x => x -> Note ... }}} but i don't see where to go from there, or a nice way to have multiple existential fields, etc. the following feels very natural to me, just omitting the forall (implicit universal quantification seems to already be present in the first place): {{{ data Note = NoteDur x => Note { midiNum :: Int -- 0-255 , vel :: Int -- 0-255 , chan :: Int -- 0-15 , measure :: Integral a => a , beat :: Int , subdiv :: RealFrac a => a -- % of beat , dur :: x } }}} although i think it is tricky to find a way to communicate the difference between class constraints expressed inside vs. outside the Note constructor. it's something like compile-time vs. runtime polymorphism, right? but for such a big difference, this difference in expression doesn't make that clear at all. > 4. I don't understand this at all. In your example > {{{ > quarters (x y) = quarters y * case x of > }}} > what are you expecting 'x' to be bound to? The constructor itself? If so, you are way beyond Haskell. Check out [http://www- staff.it.uts.edu.au/~cbj/patterns/ Barry Jay's excellent work]. right -- don't we pattern match on constructors frequently? would binding them leak out of this kind of application and cause ambiguous problems in other situations? the reference looks very relevant -- are those ideas not amenable to inclusion in haskell? in this example, i wasn't just playing golf -- i was trying to express the idea that the 'quarters' part of the function is constant, only the factor 3/2 vs. 2/3 is sensitive to the input. is there a natural way to do this in haskell that i'm missing? > 5. I have no idea what you mean here. sorry. :) note in the example: {{{ class NoteDur a where beats :: (Real x, Floating x) => a -> x -- beats d = (quarters d) / (quarters $ unit timeSig) -- want to factor out the application of quarters -- beats d = uncurry (/) $ join (***) quarters (d, unit timeSig) -- join (***) from Saizan_ @ #haskell, but isn't existentially polymorphic beats d = uncurry (/) $ both quarters (d, unit timeSig) where both (f :: forall a b. (NoteDur a, Real b, Floating b) => a -> b) (x, y) = (f x, f y) -- lame that this has to be class specific (copumpkin @ #haskell says a 'forall classes' would be nice) }}} again, i wanted to factor out the application of quarters to the nominator and denominator, to show that it is not a free choice. but i couldn't find a natural way to express this -- since the nominator and denominator are different types, it is hard to find a way to map the application of 'quarters' over them in a way that interacts nicely with expressing that there must be exactly two (one denominator and one nominator, so we can later divide them). i wind up having to define 'both' -- which already is a bit unnatural. but what makes it really unsatisfying is that both has to be defined just to operate on these specific classes -- there's no way that i could find to express "apply some class method to exactly N class instances" without *specifying* the classes involved. then copumpkin mentioned that he had run into similar situations and thought a "forall classes" construct would give you the desired polymorphism here. so something like: {{{ both :: (forall p q a b. (p a, q b) => a -> b) -> (a,a) -> (b,b) }}} but what is really wanted is some kind of existential tuple map -- one shouldn't have to write 'both' manually and specifically for each N... {{{ mapTup'' :: (forall p q a b. (p a, q b) => a -> b) -> (a,a) -> (b,b) mapTup''' :: (forall p q a b. (p a, q b) => a -> b) -> (a,a,a) -> (b,b,b) ... }}} maybe if every tuple were a functor, fmap could be defined like this? as long as it worked existentially... > 6. Quite possible, along the lines of tuple sections. The complexity/benefit ratio is debatable; my nose says "not quite worth it" but I'd be interested to know what others think. yeah i hear you. it was from the perspective of someone new to haskell trying to internalize its philosophy and apply it consistently, it's just kind of a nasty surprise when it doesn't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 04:19:45 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 03:55:51 2009 Subject: [GHC] #3614: Cabal file parser can't handle colon in description In-Reply-To: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> References: <042.a1fcf46934be35bcc5f0659de5b6d5ca@localhost> Message-ID: <051.25c3ee0c062bdb5d6910c3e9712a0435@localhost> #3614: Cabal file parser can't handle colon in description ---------------------------------+------------------------------------------ Reporter: dsf | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.12.1 RC1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: Thanks; closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 04:27:52 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 04:03:59 2009 Subject: [GHC] #3630: Suggested algorithm to control upper bound of space "leaks" In-Reply-To: <051.72af98bc6de8e1372fe3431e4a8c348a@localhost> References: <051.72af98bc6de8e1372fe3431e4a8c348a@localhost> Message-ID: <060.a5425e8c52420543e70b19c51e9cff4b@localhost> #3630: Suggested algorithm to control upper bound of space "leaks" ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: I still don't have a clear idea what it is you want to do. I think you want to turn off updates for certain thunks, based on some metrics (or profile-directed feedback?). I pointed out that disabling thunk update might actually cause a space leak, because the free variables of the thunk have to be retained. Also you don't explain how you're going to decide which thunks should have update disabled. I think probably a ticket is not the right place for this discussion - a wiki page might be better? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 04:30:45 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 04:06:50 2009 Subject: [GHC] #3635: base-3-compat with 6.12 won't load in GHCi, Template Haskell on Windows In-Reply-To: <044.df7c80f0816e4233c9d311717355b62b@localhost> References: <044.df7c80f0816e4233c9d311717355b62b@localhost> Message-ID: <053.ba46339245452b4933186b76bbe7ac2e@localhost> #3635: base-3-compat with 6.12 won't load in GHCi, Template Haskell on Windows ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 04:38:00 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 04:14:06 2009 Subject: [GHC] #3441: readProcess ... (exit 11): failed In-Reply-To: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> References: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> Message-ID: <054.82c4daba72162066d652ea9c842f0241@localhost> #3441: readProcess ... (exit 11): failed ------------------------------------+--------------------------------------- Reporter: Andriy | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: libraries/process | Version: 6.10.3 Severity: major | Resolution: Keywords: readProcess exit 11 | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------------------+--------------------------------------- Comment (by simonmar): Please upload it somewhere. Are you using the standard 6.10.3 binary distribution for x86/Linux? (I'll need to use the same one to interpret your core dump). I'm not hopeful that I'll be able to debug this one, but I'll give it a go anyway. Things you could do that might help: * try to find a reproducible test case. Maybe replace the long-running child process with a dummy program that runs much more quickly? * compile your program with -debug * try a later version of GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 04:38:12 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 04:14:15 2009 Subject: [GHC] #3441: readProcess ... (exit 11): failed In-Reply-To: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> References: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> Message-ID: <054.51f4eeabd1f64c02998b46705d6cecaa@localhost> #3441: readProcess ... (exit 11): failed ------------------------------------+--------------------------------------- Reporter: Andriy | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/process | Version: 6.10.3 Severity: major | Resolution: Keywords: readProcess exit 11 | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------------------+--------------------------------------- Changes (by simonmar): * status: reopened => new * owner: => simonmar * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 04:44:35 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 04:20:39 2009 Subject: [GHC] #3490: Relax superclass restrictions In-Reply-To: <046.d4ecd3a8759936af7853c82b7c4c099e@localhost> References: <046.d4ecd3a8759936af7853c82b7c4c099e@localhost> Message-ID: <055.9c7f24a3f25a137528afdd9bc7e56477@localhost> #3490: Relax superclass restrictions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): So should this be closed as a duplicate? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 04:45:05 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 04:21:12 2009 Subject: [GHC] #3491: Relax superclass restrictions In-Reply-To: <046.b6fd04394dc8a665bff9cc46e7abd115@localhost> References: <046.b6fd04394dc8a665bff9cc46e7abd115@localhost> Message-ID: <055.f2666aa44682582d81ea564fc4af902d@localhost> #3491: Relax superclass restrictions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: ticket created twice: see #3490 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 05:33:11 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 05:09:21 2009 Subject: [GHC] #3630: Suggested algorithm to control upper bound of space "leaks" In-Reply-To: <051.72af98bc6de8e1372fe3431e4a8c348a@localhost> References: <051.72af98bc6de8e1372fe3431e4a8c348a@localhost> Message-ID: <060.e79b66bc300bffff3c413243e0ad460c@localhost> #3630: Suggested algorithm to control upper bound of space "leaks" ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by shelbymoore3): Readers can continue clicking "next message" on the links I have provided to see all the discussion. For example: http://www.haskell.org/pipermail/cvs-ghc/2009-November/050949.html In link above I offered the idea that the decision on which thunks to not update would probably be best determined not individually, but stochastic- ally on timer in groups by determining if the (space allocated per unit time / thunks updated per unit time) was excessive given the level of paging (fault) load last reported by the virtual memory manager, and if so then reverting those memo-izations. I understand that you said (at the mailing list), that we can not revert (discard the memo/normal form) without retaining the free variables, so I suggested at link above that we would retain these only temporarily in the GC nursery and make the decision on whether to revert, before these evaluated thunks are pushed out of the nursery. There would be no need to retain the revert overhead until the paging fault load is approaching the level we need to start throttling space allocation rate. We do not want to employ to binary (on/off) approach, but rather a rate reduction approach (so that gradually space intensive operations are not memo-ized, so that our annealing coverges, see http://www.haskell.org/pipermail /haskell-cafe/2009-November/068479.html). We are not trying to kill all space leaks (e.g. free variables), but rather gradually slow down the rate (velocity) of which we are creating additional space allocation as we gradually approach some intolerable measure of the paging fault load. We know that paging fault load is orders-of-magnitude more costly performance-wise than CPU load. With a high paging fault load, the program can be unusable. So we do not need to worry about free variables retaining space allocation, as we are approaching this stochastically with global measure of the impact of additional space allocation (i.e. paging load). Hopefully the above achieves a trade-off in absolute speed, for tolerable speed in spite of what would have been crushing space leaks. And hopefully there is no impact on absolute speed at all, until paging load has become a factor. Note even though I have also tried to suggest this area of work (and alternative approaches) for a master's thesis, I think perhaps the solution above is straight forward enough to proceed: http://www.haskell.org/pipermail/haskell-cafe/2009-November/068638.html Maybe I would be willing to experiment if I had a better understanding of the Haskell source code. I suppose I could do that at some time in future, if no one jumps on this before then. It might be a year or more from now. I would prefer to see someone earn their masters on this, because I would get no compensation at all for working on this, and Haskell is not (yet) my area of specialization. It is nice to leave some work for fresh students, since this seems to be in the theoretical realm (as much as in the practical realm). If a wiki is better, must I create one then post a link to it here? P.S. Simon apologies if I have overly impinged on your time or if I have made any gross error. I am trying to help. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 05:56:09 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 05:32:12 2009 Subject: [GHC] #3490: Relax superclass restrictions In-Reply-To: <046.d4ecd3a8759936af7853c82b7c4c099e@localhost> References: <046.d4ecd3a8759936af7853c82b7c4c099e@localhost> Message-ID: <055.049233c1c18c094a6568da21ad9a7d59@localhost> #3490: Relax superclass restrictions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * type: bug => feature request Comment: Actually I'll close #714 in favour of this ticket. #714 has an interesting discussion but it wanders around a bit, whereas this ticket now focuses on the actual feature request. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 05:56:57 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 05:33:06 2009 Subject: [GHC] #714: Inconsistency between handling functional dependencies in class and signature constraints In-Reply-To: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> References: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> Message-ID: <071.70776605000152df98e11e1e66dcef7f@localhost> #714: Inconsistency between handling functional dependencies in class and signature constraints ----------------------------------------+----------------------------------- Reporter: claus.reinke@talk21.com | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.5 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: I'll close this long thread in favour of #3490, which summarises the key feature request. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 06:08:36 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 05:45:06 2009 Subject: [GHC] #3640: NamedFieldPuns broken in where clauses In-Reply-To: <042.e30183e327673937ec9a9f1dede6ed45@localhost> References: <042.e30183e327673937ec9a9f1dede6ed45@localhost> Message-ID: <051.bd3426d500a0cfe7cc60279f944212de@localhost> #3640: NamedFieldPuns broken in where clauses --------------------------------------------+------------------------------- Reporter: cjs | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Severity: major | Resolution: Keywords: NamedFieldPuns | Difficulty: Unknown Testcase: rename/should_compile/T3640 | Os: Linux Architecture: x86_64 (amd64) | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => rename/should_compile/T3640 * owner: simonpj => igloo * type: bug => merge Comment: Thank you for reporting this bug -- excellent catch. Fixed by {{{ Thu Nov 5 08:55:25 PST 2009 simonpj@microsoft.com * Fix Trac #3640, plus associated refactoring In fixing this bug (to do with record puns), I had the usual rush of blood to the head, and I did quite a bit of refactoring in the way that duplicate/shadowed names are reported. I think the result is shorter as well as clearer. In one place I found it convenient for the renamer to use the ErrCtxt carried in the monad. (The renamer used not to have such a context, but years ago the typechecker and renamer monads became one, so now it does.) So now it's availble if you want it in future. M ./compiler/rename/RnBinds.lhs -73 +50 M ./compiler/rename/RnEnv.lhs -48 +45 M ./compiler/rename/RnExpr.lhs -10 +9 M ./compiler/rename/RnPat.lhs -3 +1 M ./compiler/rename/RnSource.lhs -34 +29 M ./compiler/rename/RnTypes.lhs -1 +1 M ./compiler/typecheck/TcRnMonad.lhs -32 +47 }}} Ian, please merge this if it goes over smoothly, which I think it will. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 10:46:23 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 10:22:26 2009 Subject: [GHC] #2034: In FilePath, current directory should be ".", not "" In-Reply-To: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost> References: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost> Message-ID: <053.cb7027b7ec85384ad04c8bb62d86d211@localhost> #2034: In FilePath, current directory should be ".", not "" ----------------------------------+----------------------------------------- Reporter: igloo | Owner: neil Type: proposal | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by igloo): Note the patch was applied and rolled back, so darcs will think it's already applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 11:39:55 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 11:16:13 2009 Subject: [GHC] #3114: "ghc -shared --make" gives panic In-Reply-To: <052.079c60d812f2d30299cbb39a250d1778@localhost> References: <052.079c60d812f2d30299cbb39a250d1778@localhost> Message-ID: <061.dd9b6f5e900512968b24c1dece834024@localhost> #3114: "ghc -shared --make" gives panic ------------------------------------+--------------------------------------- Reporter: Mark_Spezzano | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: command line option | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: This was fixed: {{{ Wed Apr 22 21:19:37 BST 2009 y.zhuang5@lse.ac.uk * enable LinkDynLib in compilier phase }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 13:23:56 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 12:59:57 2009 Subject: [GHC] #3643: building heliumeditor Message-ID: <048.0d743250e4ce68e9e979f412d157febf@localhost> #3643: building heliumeditor ----------------------+----------------------------------------------------- Reporter: cyberpuff | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- :~/share/heliumEditor$ cabal configure Resolving dependencies... Binary: Int64 truncated to fit in 32 bit Int ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): Prelude.chr: bad argument Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug The system is i386 Xubuntu 9.10, installed from the alternate CD running as a VirtualBox VM guest under XP SP3. It don't happen if I do: cabal configure -fgui -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 13:33:20 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 13:09:23 2009 Subject: [GHC] #3439: Improve the setup for ticky In-Reply-To: <046.97ec1b5f2b20c06c8559b26055a95a61@localhost> References: <046.97ec1b5f2b20c06c8559b26055a95a61@localhost> Message-ID: <055.2bfd62b20391674c6b96cfb2357730d4@localhost> #3439: Improve the setup for ticky ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: All 3 patches are now in the 6.12 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 13:37:01 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 13:13:03 2009 Subject: [GHC] #3604: Use of template-haskell is broken with shared libraries In-Reply-To: <044.80a0861c1656d96474979b0b59adc47b@localhost> References: <044.80a0861c1656d96474979b0b59adc47b@localhost> Message-ID: <053.f7663fec4ef5d935c0e463ec13a78986@localhost> #3604: Use of template-haskell is broken with shared libraries ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 13:41:38 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 13:18:05 2009 Subject: [GHC] #3640: NamedFieldPuns broken in where clauses In-Reply-To: <042.e30183e327673937ec9a9f1dede6ed45@localhost> References: <042.e30183e327673937ec9a9f1dede6ed45@localhost> Message-ID: <051.0da813032ec72aec38cfb762c8639516@localhost> #3640: NamedFieldPuns broken in where clauses --------------------------------------------+------------------------------- Reporter: cjs | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Severity: major | Resolution: fixed Keywords: NamedFieldPuns | Difficulty: Unknown Testcase: rename/should_compile/T3640 | Os: Linux Architecture: x86_64 (amd64) | --------------------------------------------+------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 14:05:03 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 13:41:08 2009 Subject: [GHC] #3524: Add mfilter to Control.Monad In-Reply-To: <051.0391717d448955e9ccc2e936d0523bd6@localhost> References: <051.0391717d448955e9ccc2e936d0523bd6@localhost> Message-ID: <060.17a9f5571bc6c87521cf93978a59261e@localhost> #3524: Add mfilter to Control.Monad ---------------------------------+------------------------------------------ Reporter: JonFairbairn | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by JonFairbairn): No one opposed this, but I don't have permissions to commit the patch. Please can someone do it for me? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 16:03:59 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 15:40:11 2009 Subject: [GHC] #3637: ./configure doesn't understand Gentoo's build/host/target In-Reply-To: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> References: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> Message-ID: <056.7aa947a8570bf90b1af452798d3f47ae@localhost> #3637: ./configure doesn't understand Gentoo's build/host/target ---------------------------------+------------------------------------------ Reporter: kolmodin | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Severity: minor | Resolution: Keywords: regression | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: The way the build system now works, the build/host/target values must be known to the build system. They're normally extracted from the "ghc +RTS --info" output of the bootstrapping compiler, but you can give them as flags when necessary (e.g. when bootstrapping). So, I think we have 3 options: * Add normalisation back. This means we have to keep it up-to-date, so I would rather not do this * Close this as wont-fix * Ignore the `--{host,build,target}` flags, and use `--ghc-{host,build,target}` instead -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 16:42:11 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 16:18:13 2009 Subject: [GHC] #3624: Parse fails when foreign import declarations contain path information (like those generated by c2hs). In-Reply-To: <048.e18b59101dfab8616bf0f6866665ebfc@localhost> References: <048.e18b59101dfab8616bf0f6866665ebfc@localhost> Message-ID: <057.1b91fa4f21fb1856a32adddfe40bfa9c@localhost> #3624: Parse fails when foreign import declarations contain path information (like those generated by c2hs). ----------------------------------+----------------------------------------- Reporter: twadleigh | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler (Parser) | Version: 6.12.1 RC1 Severity: major | Resolution: fixed Keywords: FFI, c2hs | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.12 by: {{{ Fri Nov 6 10:23:19 GMT 2009 Simon Marlow * Accept any non-space characters in a header file (#3624) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 17:44:30 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 17:20:33 2009 Subject: [GHC] #3642: GHC does not build using the Haskell Platform on Windows In-Reply-To: <047.f7dc4955002df3f44f0e5e850b71a0c9@localhost> References: <047.f7dc4955002df3f44f0e5e850b71a0c9@localhost> Message-ID: <056.8cd60870ef675c537c5231830cc14425@localhost> #3642: GHC does not build using the Haskell Platform on Windows ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): I've merged those two to 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 6 18:01:21 2009 From: trac at galois.com (GHC) Date: Fri Nov 6 17:37:24 2009 Subject: [GHC] #3629: Code compiled WITHOUT profiling many times slower than compiled WITH profiling on In-Reply-To: <048.82a42937ecf77e5d0d0af3b5fdd87592@localhost> References: <048.82a42937ecf77e5d0d0af3b5fdd87592@localhost> Message-ID: <057.87ad2e90567a600199cdd1df0619a467@localhost> #3629: Code compiled WITHOUT profiling many times slower than compiled WITH profiling on ---------------------------------+------------------------------------------ Reporter: gchrupala | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.13 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report. There's 256k of code there; if you are able to boil it down to a smaller testcase then that would make it easier to investigate what's going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 05:46:08 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 05:22:08 2009 Subject: [GHC] #3644: ./configure fails while gcc version checking Message-ID: <045.3827bc27fa1ab647bb56cc021f95dbe9@localhost> #3644: ./configure fails while gcc version checking -------------------+-------------------------------------------------------- Reporter: tolysz | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.13 | Severity: critical Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- ./configure exits with an error 1 but commenting out lines 4115 - 4138 solves this problem i.e. {{{ >gcc --version gcc (Debian 4.3.4-6) 4.3.4 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. }}} {{{ >gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable- languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program- suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release --build=x86_64 -linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.4 (Debian 4.3.4-6) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 06:54:55 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 06:30:55 2009 Subject: [GHC] #3644: ./configure fails while gcc version checking In-Reply-To: <045.3827bc27fa1ab647bb56cc021f95dbe9@localhost> References: <045.3827bc27fa1ab647bb56cc021f95dbe9@localhost> Message-ID: <054.338a3d4d3427fe7e0b48ee11b3162353@localhost> #3644: ./configure fails while gcc version checking ---------------------------------+------------------------------------------ Reporter: tolysz | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.13 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: What's on those lines will depend on what version of autoconf you use. Can you paste them here please? Can you also attach the output of configure and the config.log file please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 07:34:49 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 07:10:54 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard In-Reply-To: <043.67172119f9bd273a2158fec836b33117@localhost> References: <043.67172119f9bd273a2158fec836b33117@localhost> Message-ID: <052.ea0cf735ea92a330a240259d271fbca5@localhost> #3530: GHCi does not work on Snow Leopard -------------------------+-------------------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.11 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by igloo): Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 07:40:23 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 07:16:21 2009 Subject: [GHC] #3645: Layout and pragmas Message-ID: <044.fddd9f8ae2f17ca6ebff5e268d132ce9@localhost> #3645: Layout and pragmas --------------------------------+------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Parser) | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------+------------------------------------------- With this module: {{{ {-# LANGUAGE DeriveDataTypeable, FlexibleContexts #-} module Foo where }}} GHC 6.12 says: {{{ Cannot parse LANGUAGE pragma Expecting comma-separated list of language options, each starting with a capital letter E.g. {-# LANGUAGE RecordPuns, Generics #-} }}} but this should probably be allowed. See #3519, #3616. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 07:40:53 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 07:16:51 2009 Subject: [GHC] #3519: ghc: panic! (the 'impossible' happened) In-Reply-To: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> References: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> Message-ID: <053.d401bf5a199dd9b9b5642699d3f4dff9@localhost> #3519: ghc: panic! (the 'impossible' happened) -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've created #3645. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 07:42:42 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 07:18:42 2009 Subject: [GHC] #3616: ghci crash from :l In-Reply-To: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> References: <047.24d1ad3dc7106d0841f03798edf8d963@localhost> Message-ID: <056.aa8e6e2effca4e21c4495c6d537b24db@localhost> #3616: ghci crash from :l --------------------------------+------------------------------------------- Reporter: eflister | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | --------------------------------+------------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: I've opened #3645 for the interaction of layout and pragmas. I'm not sure about the idea of allowing `-XFoo` in a pragma header, as the `-XFoo` flags are specific to GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 07:48:54 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 07:24:53 2009 Subject: [GHC] #3634: Add traceM, traceShowM and withTrace In-Reply-To: <060.9dd940925e454c846a3ca3a5aadefbb9@localhost> References: <060.9dd940925e454c846a3ca3a5aadefbb9@localhost> Message-ID: <069.c53f1662253bb5426590f08abeb66434@localhost> #3634: Add traceM, traceShowM and withTrace --------------------------------------+------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------+------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC Comment: I'm not sure the discussion has reached a conclusion yet, e.g. in http://article.gmane.org/gmane.comp.lang.haskell.libraries/12087 Simon Marlow asks if `traceShowM` is necessary. It might be better to send a current summary message to the list, and see if there are any more comments. If we do have a `traceShowM` then I would have thought {{{ traceShowM :: (Show a, Monad m) => String -> a -> m () traceShowM msg x = traceM (msg ++ show x) }}} to be more useful, similar to withTrace. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 07:51:39 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 07:27:52 2009 Subject: [GHC] #3636: ghc --make sends progress output to stderr In-Reply-To: <041.ed5db1080b9d405db642a9233ac01378@localhost> References: <041.ed5db1080b9d405db642a9233ac01378@localhost> Message-ID: <050.681367983bea551808396b26db46a909@localhost> #3636: ghc --make sends progress output to stderr ---------------------------------+------------------------------------------ Reporter: ab | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 08:08:58 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 07:45:03 2009 Subject: [GHC] #3524: Add mfilter to Control.Monad In-Reply-To: <051.0391717d448955e9ccc2e936d0523bd6@localhost> References: <051.0391717d448955e9ccc2e936d0523bd6@localhost> Message-ID: <060.72f42fe705fc278a13d91ee5be9b579b@localhost> #3524: Add mfilter to Control.Monad ---------------------------------+------------------------------------------ Reporter: JonFairbairn | Owner: Type: proposal | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: Not GHC => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 08:27:44 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 08:03:52 2009 Subject: [GHC] #3637: ./configure doesn't understand Gentoo's build/host/target In-Reply-To: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> References: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> Message-ID: <056.da5e7678cac9dcf819759e6de05b9e6f@localhost> #3637: ./configure doesn't understand Gentoo's build/host/target ---------------------------------+------------------------------------------ Reporter: kolmodin | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Severity: minor | Resolution: Keywords: regression | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by kolmodin): Right. Given the three options; I think these are the results from our perspective; * You do the normalisation, which means work for you to keep up * Close as wont-fix means that we have to do it instead. Or, we could hack the ebuilds not to use {{{econf}}} but rather call {{{./configure}}} ourselves. * Using {{{--ghc-{host,build,target}}}} would mean the problem goes away as far as I know I think option 2 and 3 looks most attractive. With option 3, what could the consequences be? Would things break for other people? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 10:01:22 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 09:37:22 2009 Subject: [GHC] #3646: Enforce requirement that our repos contains a subset of upstream's patches Message-ID: <044.3251c5b214325160caef2f0092388f6b@localhost> #3646: Enforce requirement that our repos contains a subset of upstream's patches -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Simon Marlow wrote this prehook script: {{{ #!/bin/sh -e # checkupstream.sh # Only allow applying of patches that are also in this upstream repository: UPSTREAM=$1 # echo DARCS_PATCHES_XML = $DARCS_PATCHES_XML # Take $DARCS_PATCHES_XML and turn it into a list of patch hashes # suitable for looping over. hashes=`echo $DARCS_PATCHES_XML | sed 's||\n|g' | sed -n '/hash/p' | sed "s|^.*hash='\([^']*\)'.*$|\1|"` # echo hashes: $hashes # For each patch, try pulling the patch from the upstream repo. If # the patch is not upstream, then fail. for p in $hashes; do if darcs pull --match="hash $p" $UPSTREAM --xml --dry-run | grep "$p" >/dev/null; then echo "Patch $p is upstream; ok" else echo "Patch $p is not upstream!" exit 1 fi done exit 0 }}} although this is not ideal, as what we really want is to abort the entire `darcs-all push`, not just the push to that repo. e.g. if you haven't pushed to the upstream Cabal repo yet, then you shouldn't push the accompanying patches to the ghc repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 10:13:29 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 09:49:27 2009 Subject: [GHC] #3646: Enforce requirement that our repos contains a subset of upstream's patches In-Reply-To: <044.3251c5b214325160caef2f0092388f6b@localhost> References: <044.3251c5b214325160caef2f0092388f6b@localhost> Message-ID: <053.4bb8cf4ab7a7ca04bc15b3e7e8cfdd12@localhost> #3646: Enforce requirement that our repos contains a subset of upstream's patches ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 11:12:47 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 10:48:47 2009 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> Message-ID: <055.caa5a0d6b6913e1a1499f3b4af986640@localhost> #3472: Porting through .hc files broken ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by ksf): We either have to come up with a solution for using hsc2hs (take the intermediate C files to the target and compile/run them?) or convert .hsc files to autoconf + CPP (yeuch). It's quite straight-forward to split up the %.hsc->%.hs rule in two, the first one generating %_hsc_make with a cross-compiler, the second one moving the binary over to the target, executing it and piping the result into %.hs. Compiling on the target is certainly feasible, too, but I happen to have a working cross-compiler. I am, however, stuck with make, in the area of separating the build directories into stage1/stage2 for the libraries as well as transferring ./configure output over from the target to the build platform, without having that trigger recompilation of stage1 (and the package info being a bit messed up wrt. -l flags, but that's a minor concern) Compiling the stage2 libraries with actual target info also opens up the issue that we can't use the native gcc as it's quite likely to fail, not so much while compiling (at least .hc), but linking: My linux doesn't come with libutil, for example. Both using a cross-gcc and replacing gcc with touch should work, I've not had much time to investigate this. The main issue, however, is that we're infecting perfectly cross-platform .hc with platform-specific information by preprocessing Haskell instead of C: It might be feasible to generate C stubs for all hsc2hs macros and calling them via the ffi, leaving resolving of platform-specific things until later. The whole build-process depending on .o s being generated even when all you want to have are .hc s isn't helping things. And then there's David's LLVM work... I'm currently slurping his thesis because porting via LLVM looks very, very, elegant and painless, at least from afar. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 11:44:08 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 11:20:08 2009 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> Message-ID: <055.8a2fb3ab7e0e62a63a9870d55b2ef9c6@localhost> #3472: Porting through .hc files broken ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): I'm not sure I follow; why do you need to have stage1 and stage2 library build directories? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 12:23:04 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 11:59:03 2009 Subject: [GHC] #3295: Null deref by threaded runtime scheduler In-Reply-To: <044.c2ef3bf0c2dff07fbe94ef6f704ea47f@localhost> References: <044.c2ef3bf0c2dff07fbe94ef6f704ea47f@localhost> Message-ID: <053.4aa5d44a6005da1209bf8d2d866c5ad8@localhost> #3295: Null deref by threaded runtime scheduler ---------------------------------------------------------+------------------ Reporter: A1kmm | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: major | Resolution: fixed Keywords: crash, nullderef, threaded, parallel, GC | Difficulty: Unknown Testcase: | Os: Linux Architecture: ia64 | ---------------------------------------------------------+------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: No response from submitter, so closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 12:58:29 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 12:34:29 2009 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@localhost> References: <045.f06a53427920f75d02000e2372e27573@localhost> Message-ID: <054.ca52d6c71d97032bd81e982817f28a57@localhost> #2301: Proper handling of SIGINT/SIGQUIT ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by diego): Replying to [comment:2 simonmar]: > > 1619: we now ignore SIGPIPE by default. Although POSIX says that a > SIGPIPE should terminate the process by default, I wonder if this > decision was made because many C applications failed to check the exit > code from write(). In Haskell a failed write due to a closed pipe > will generate an exception anyway, so the main difference is that we > now get a useful error message instead of silent program termination. > See #1619 for more discussion. > And when describing exec POSIX says: > Signals set to the default action (SIG_DFL) in the calling process image shall be set to the default action in the new process image. > Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling process image shall be set to be ignored by the new process image. > Signals set to be caught by the calling process image shall be set to the default action in the new process image (see ). Thus, to avoid breaking applications that rely on the the default handler of SIGPIPE the RTS should restore the handler before starting new processes. I can't say how many applications are affected by this nowadays. Simple applications may rely on default bahavior of signals. But it seems to be a minor issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 13:26:32 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 13:02:34 2009 Subject: [GHC] #3629: Code compiled WITHOUT profiling many times slower than compiled WITH profiling on In-Reply-To: <048.82a42937ecf77e5d0d0af3b5fdd87592@localhost> References: <048.82a42937ecf77e5d0d0af3b5fdd87592@localhost> Message-ID: <057.ea01ea1cae826afa7c6d08e4bdf136e9@localhost> #3629: Code compiled WITHOUT profiling many times slower than compiled WITH profiling on ---------------------------------+------------------------------------------ Reporter: gchrupala | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.13 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by gchrupala): Actually most of those bytes is a data file, but sure, I'll see if I can reduce the code more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 14:35:14 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 14:11:13 2009 Subject: [GHC] #3645: Layout and pragmas In-Reply-To: <044.fddd9f8ae2f17ca6ebff5e268d132ce9@localhost> References: <044.fddd9f8ae2f17ca6ebff5e268d132ce9@localhost> Message-ID: <053.fb4abc14e5ec0300b71f9452f911d677@localhost> #3645: Layout and pragmas ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Parser) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by eflister): just to be super pedantic, i want to make sure the following would be ok too. :) afaik, lots of people use this kind of layout to make toggling lines via comments as easy as possible. {{{ {-# LANGUAGE EmptyDataDecls , MultiParamTypeClasses #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 14:37:27 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 14:13:26 2009 Subject: [GHC] #3645: Layout and pragmas In-Reply-To: <044.fddd9f8ae2f17ca6ebff5e268d132ce9@localhost> References: <044.fddd9f8ae2f17ca6ebff5e268d132ce9@localhost> Message-ID: <053.7faf88593008b651c1c92589196dd6c8@localhost> #3645: Layout and pragmas ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Parser) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by eflister): whoops, to be really explicit, i should include a comment example: {{{ {-# LANGUAGE EmptyDataDecls , MultiParamTypeClasses -- , RecordPuns , Generics -- , DeriveDataTypeable , FlexibleContexts #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 15:03:41 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 14:39:40 2009 Subject: [GHC] #3645: Layout and pragmas In-Reply-To: <044.fddd9f8ae2f17ca6ebff5e268d132ce9@localhost> References: <044.fddd9f8ae2f17ca6ebff5e268d132ce9@localhost> Message-ID: <053.ecd3505c54ae882b79d73fef040e2ebe@localhost> #3645: Layout and pragmas ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Parser) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by eflister): * cc: erik.flister@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 15:19:08 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 14:55:07 2009 Subject: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions Message-ID: <047.73fc8cca3ba98859dc9d57483a25d637@localhost> #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions -------------------------------------------------------------+-------------- Reporter: eflister | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.10.4 | Severity: trivial Keywords: language pragma extensions error message warning | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------------------------------+-------------- it's easy to accidentally cut and paste a -XExtentionName from a ghc error message into one's {-#LANGUAGE ...#-} pragma, and then one has to track down the problem when that doesn't work. it would be nice if -XExtentionName were accepted in the pragma list. even though -X is ghc specific, i don't see that it hurts anything to be lenient in the pragma format accepted (a warning could be produced to indicate that the program will not be portable). also, the ghc error message indicating that an extension should be added should print out a message that would make for easy cut and paste without modification into *either* one's language pragma or command line -X extension args. see http://hackage.haskell.org/trac/ghc/ticket/3616#comment:8. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 16:08:40 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 15:44:43 2009 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> Message-ID: <055.1a830ee2f6d566a2f8fcb05c3a31c046@localhost> #3472: Porting through .hc files broken ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by ksf): Both the stage1 and stage2 compilers need the same libraries, stage1 needs .o files native to the build platform, stage2 ones native to the target platform, and make likes to re-built the stage1 compiler as soon as I've built a library for the target because it just depends on the resulting .a . I would compile them with -C, but that breaks make's notion of dependencies. The current build system, iirc, just compiles those libraries once and uses them for both stages. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 16:30:53 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 16:06:52 2009 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> Message-ID: <055.30ef24b2c3f563ce08e8fa8ace63acac@localhost> #3472: Porting through .hc files broken ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): stage1 should not need .o files native to the build platform (except for those built in dist-boot directories, which do not need to be used on the target platform). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 16:52:07 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 16:28:06 2009 Subject: [GHC] #3648: Release a new containers version Message-ID: <044.a62d7b1d53452135e5ca11272aa7e3e1@localhost> #3648: Release a new containers version -------------------------------+-------------------------------------------- Reporter: igloo | Owner: igloo Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- To include: {{{ Wed Oct 28 03:55:32 PDT 2009 Ross Paterson * doc bugfix: correct description of index argument }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 17:53:41 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 17:29:40 2009 Subject: [GHC] #3644: ./configure fails while gcc version checking In-Reply-To: <045.3827bc27fa1ab647bb56cc021f95dbe9@localhost> References: <045.3827bc27fa1ab647bb56cc021f95dbe9@localhost> Message-ID: <054.aab525d0eaa35f98b47c85e8240c8d8a@localhost> #3644: ./configure fails while gcc version checking ---------------------------------+------------------------------------------ Reporter: tolysz | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.13 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by tolysz): The ./configure from '''ghc-6.12.0.20091106''' is working fine. Only '''6.13''' is broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 7 19:58:13 2009 From: trac at galois.com (GHC) Date: Sat Nov 7 19:35:21 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.9e760c85ccdd0d5abbd2fecff73acea7@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Sat Nov 7 11:44:49 PST 2009 Ian Lynagh * Add C and linker flags to hsc2hs; fixes trac #3400 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 8 04:28:36 2009 From: trac at galois.com (GHC) Date: Sun Nov 8 04:05:43 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.f9f0fd4e884484d4f2086e585d09a77b@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by guest): It doesn't seem to allow linking with 64-bit OSX libraries like XLib (e.g. for xmonad). Am I right ? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 8 05:59:09 2009 From: trac at galois.com (GHC) Date: Sun Nov 8 05:35:05 2009 Subject: [GHC] #3598: ghc-stage2 binary name confusing for users In-Reply-To: <050.0c9e6d70bcb7f6d45f2e902acf2e7ba0@localhost> References: <050.0c9e6d70bcb7f6d45f2e902acf2e7ba0@localhost> Message-ID: <059.77274f043eb9328cda5061d9e12b1c9e@localhost> #3598: ghc-stage2 binary name confusing for users ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now fixed in 6.12 and HEAD: {{{ Sat Nov 7 18:36:14 GMT 2009 Ian Lynagh * ghc-stage2 is now renamed to ghc when it is installed This means that we get the right program name in error messages etc. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 8 06:05:10 2009 From: trac at galois.com (GHC) Date: Sun Nov 8 05:41:09 2009 Subject: [GHC] #3644: ./configure fails while gcc version checking In-Reply-To: <045.3827bc27fa1ab647bb56cc021f95dbe9@localhost> References: <045.3827bc27fa1ab647bb56cc021f95dbe9@localhost> Message-ID: <054.a248b92cdcd61d6d16e7696aaa7271db@localhost> #3644: ./configure fails while gcc version checking ---------------------------------+------------------------------------------ Reporter: tolysz | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.13 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Is this the latest HEAD? Do you have "set -e" in configure? The configure scripts in the 6.12 and 6.13 branches are currently identical apart from the version number. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 8 07:16:10 2009 From: trac at galois.com (GHC) Date: Sun Nov 8 06:52:09 2009 Subject: [GHC] #3644: ./configure fails while gcc version checking In-Reply-To: <045.3827bc27fa1ab647bb56cc021f95dbe9@localhost> References: <045.3827bc27fa1ab647bb56cc021f95dbe9@localhost> Message-ID: <054.28795957f96aac56fab3fe44b96f6ef4@localhost> #3644: ./configure fails while gcc version checking ---------------------------------+------------------------------------------ Reporter: tolysz | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.13 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by tolysz): Replying to [comment:3 igloo]: > Is this the latest HEAD? > > Do you have "set -e" in configure? > > The configure scripts in the 6.12 and 6.13 branches are currently identical apart from the version number. There was "set -e" in 6.13 it works now with this line(2472) being commented out. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 8 07:34:26 2009 From: trac at galois.com (GHC) Date: Sun Nov 8 07:10:24 2009 Subject: [GHC] #3644: ./configure fails while gcc version checking In-Reply-To: <045.3827bc27fa1ab647bb56cc021f95dbe9@localhost> References: <045.3827bc27fa1ab647bb56cc021f95dbe9@localhost> Message-ID: <054.9f1c3fc33d2604efe30cf25f442d04ee@localhost> #3644: ./configure fails while gcc version checking ---------------------------------+------------------------------------------ Reporter: tolysz | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.13 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: OK, thanks for the follow-up. It sounds like you have an old snapshot, so I'll close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 8 08:41:03 2009 From: trac at galois.com (GHC) Date: Sun Nov 8 08:17:06 2009 Subject: [GHC] #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? In-Reply-To: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> References: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> Message-ID: <055.9a55ea22d03af266d3b8b8fe129ce80c@localhost> #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? ------------------------------+--------------------------------------------- Reporter: Aviator | Owner: judah Type: bug | Status: assigned Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by Aviator): Also noticed that several other terminal control characters also don't work: Home, End. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 8 13:22:28 2009 From: trac at galois.com (GHC) Date: Sun Nov 8 12:58:29 2009 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> Message-ID: <055.69c5021de6893bbc18c2c5d9eccf60ee@localhost> #3472: Porting through .hc files broken ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by kili): For the primop stuff (and some other minor problems), please have a look at the documentation changes I did a few feeks ago: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting?action=diff&version=45&old_version=39 For some of the build problems on the target machine, I'll send some patches to cvs-ghc@ this day (actually the first one already sent). For the hsc2hs problem: no idea (yet), I'm still waiting for my testbuild to fail (or finish) at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 8 14:20:09 2009 From: trac at galois.com (GHC) Date: Sun Nov 8 13:56:26 2009 Subject: [GHC] #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES In-Reply-To: <043.f3ae9723755c0a36083ac743990981c8@localhost> References: <043.f3ae9723755c0a36083ac743990981c8@localhost> Message-ID: <052.d09afe09a1eda81a5efeeb244332f86e@localhost> #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES -----------------------------+---------------------------------------------- Reporter: donn | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: NetBSD Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This bug has been fixed by the above patch, and #3558 is a task for us to do it better in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 8 15:30:45 2009 From: trac at galois.com (GHC) Date: Sun Nov 8 15:06:41 2009 Subject: [GHC] #3635: base-3-compat with 6.12 won't load in GHCi, Template Haskell on Windows In-Reply-To: <044.df7c80f0816e4233c9d311717355b62b@localhost> References: <044.df7c80f0816e4233c9d311717355b62b@localhost> Message-ID: <053.bca594e2cd4990ee5d7d9f2e3d035ac4@localhost> #3635: base-3-compat with 6.12 won't load in GHCi, Template Haskell on Windows ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.12.1 RC1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report; fixed by {{{ Sun Nov 8 11:16:44 PST 2009 Ian Lynagh * Only define GHC.Handle.unlockFile on non-Windows; fixes trac #3635 M ./GHC/Handle.hs +5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 8 15:31:07 2009 From: trac at galois.com (GHC) Date: Sun Nov 8 15:07:03 2009 Subject: [GHC] #3610: Installer has hard-coded path /usr/bin/strip In-Reply-To: <047.497d60e15e84c11bbc4d65529d1dd7a9@localhost> References: <047.497d60e15e84c11bbc4d65529d1dd7a9@localhost> Message-ID: <056.8eb2a3df9dd4697d5137c21a9cc7c388@localhost> #3610: Installer has hard-coded path /usr/bin/strip ---------------------------------+------------------------------------------ Reporter: YitzGale | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.12 by: {{{ Sun Nov 8 12:02:04 GMT 2009 Ian Lynagh * Tell ghc-cabal what strip program to use }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 9 04:30:05 2009 From: trac at galois.com (GHC) Date: Mon Nov 9 04:06:01 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.3db7c139f85f9bcb2b63855bfd7b73a5@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by YitzGale): * cc: gale@sefer.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 9 04:55:52 2009 From: trac at galois.com (GHC) Date: Mon Nov 9 04:33:00 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.e0ff1f391b909d89ded5f239ea357594@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by chak): Replying to [comment:17 guest]: > It doesn't seem to allow linking with 64-bit OSX libraries like XLib (e.g. for xmonad). Am I right ? The libraries on Snow Leopard are shipped as universal binaries containing code for PPC, i386, and x86_64. When a 32-bit GHC invokes the linker, it will automatically pick the 32-bit version of the library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 9 06:45:47 2009 From: trac at galois.com (GHC) Date: Mon Nov 9 06:21:57 2009 Subject: [GHC] #3618: memory-leak detector in +RTS -DS fails to track allocations in constructors In-Reply-To: <044.ace7007dd565206bf92f9640eed34f4d@localhost> References: <044.ace7007dd565206bf92f9640eed34f4d@localhost> Message-ID: <053.27065c2dc5a9b626f52e5ba139f9a353@localhost> #3618: memory-leak detector in +RTS -DS fails to track allocations in constructors -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by augustss): I find it highly dubious to leave this unfixed. The ghc rts is called before it has been initialized, so I'd say that if it works it's more of a fluke than by design. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 9 07:04:34 2009 From: trac at galois.com (GHC) Date: Mon Nov 9 06:40:27 2009 Subject: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions In-Reply-To: <047.73fc8cca3ba98859dc9d57483a25d637@localhost> References: <047.73fc8cca3ba98859dc9d57483a25d637@localhost> Message-ID: <056.0afd9c6c0ff859ae0dc298f15192bf6c@localhost> #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions --------------------------------------------------------------+------------- Reporter: eflister | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Severity: trivial | Resolution: Keywords: language pragma extensions error message warning | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------------------------------+------------- Comment (by duncan): By all means improve the error message but please do not extend the LANGUAGE pragma syntax. It means every other compiler and tool that has to know about the pragma must also be extended (and in a rather quirky way). Standards are a good thing! :-) Perhaps we can get ghc's error messages to suggest LANGUAGE pragmas rather than the ghc -XBlah style. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 9 09:20:35 2009 From: trac at galois.com (GHC) Date: Mon Nov 9 08:56:30 2009 Subject: [GHC] #3643: building heliumeditor In-Reply-To: <048.0d743250e4ce68e9e979f412d157febf@localhost> References: <048.0d743250e4ce68e9e979f412d157febf@localhost> Message-ID: <057.b21124a9349acb91d80b9e04a090ce94@localhost> #3643: building heliumeditor ---------------------------------+------------------------------------------ Reporter: cyberpuff | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: This happens when the package author leaves some `.hi` files in the package. I believe GHC 6.12.1 should just ignore the invalid `.hi` files instead of giving this panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 9 09:40:57 2009 From: trac at galois.com (GHC) Date: Mon Nov 9 09:17:08 2009 Subject: [GHC] #3618: memory-leak detector in +RTS -DS fails to track allocations in constructors In-Reply-To: <044.ace7007dd565206bf92f9640eed34f4d@localhost> References: <044.ace7007dd565206bf92f9640eed34f4d@localhost> Message-ID: <053.a090e7867dd8b7f12122c207e6eff1dc@localhost> #3618: memory-leak detector in +RTS -DS fails to track allocations in constructors -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonmar): Replying to [comment:3 augustss]: > I find it highly dubious to leave this unfixed. The ghc rts is called before it has been initialized, so I'd say that if it works it's more of a fluke than by design. I'm sure it's safe: we're only calling the RTS in one way, `getStablePtr`, and we're careful to ensure that can be called before the RTS is initialised. It is also thread-safe. I just looked back through the commit logs and it seems that we switched to using constructors for registering foreign exports for binary size reasons (to eliminate the __stginit functions in the common case), but then we reinstated __stginit later. So perhaps the constructors aren't really helping. However, if we're going to redesign things here, I think we should look for a way to eliminate the need to call `hs_add_root` when initialising the RTS, which is both non-standard and annoying. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 9 11:55:05 2009 From: trac at galois.com (GHC) Date: Mon Nov 9 11:31:01 2009 Subject: [GHC] #3441: readProcess ... (exit 11): failed In-Reply-To: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> References: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> Message-ID: <054.ee473239e175b1e73e389b46957119cd@localhost> #3441: readProcess ... (exit 11): failed ------------------------------------+--------------------------------------- Reporter: Andriy | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/process | Version: 6.10.3 Severity: major | Resolution: Keywords: readProcess exit 11 | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------------------+--------------------------------------- Comment (by Andriy): You can download the core dump from http://www.4shared.com/file/149063065/6989f63d/core9885.html Yes, I use the 6.10.3 x86/Linux binary distribution I downloaded and set up manually. Unfortunately I could not find a reproducable test case. I did experiment with a toy long-running processes - no luck. After I submitted the bug report the problem started to happen very infrequently. This may something to do with the changes I made to the program. I'll update to a more recent version of ghc. > compile your program with -debug I run the program with runghc, without compiling it. I'll start passing -debug to GHC if I see the problem with the latest GHC. Andriy -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 9 12:16:39 2009 From: trac at galois.com (GHC) Date: Mon Nov 9 11:52:31 2009 Subject: [GHC] #3649: inconsistent exception between unix/windows for running non-existant program Message-ID: <045.38ca9e41e1ac2553ec6a5c6c46307813@localhost> #3649: inconsistent exception between unix/windows for running non-existant program -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- {{{ handle (print . isDoesNotExistError) $ do (_,_,_,hnd) <- createProcess (proc "foobar" []) print =<< waitForProcess hnd }}} On Windows this prints `True` since it throws a "does not exists" kind of IOException. On Unix instead the createProcess call succeeds and then waiting on the process claims it terminated with an exit code of 127. It is annoying that we need two different error handling mechanisms in this case. For example Cabal wants to know when it tries to run a program that cannot be found (eg when it tries to run sh.exe on Windows). It would be better if the behaviour was consistent. The behaviour on Windows seems to be the more sensible one. We should be able to make the Unix behaviour the same since the exceve call does indeed return an error code when loading the new executable image fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 9 13:29:44 2009 From: trac at galois.com (GHC) Date: Mon Nov 9 13:05:40 2009 Subject: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions In-Reply-To: <047.73fc8cca3ba98859dc9d57483a25d637@localhost> References: <047.73fc8cca3ba98859dc9d57483a25d637@localhost> Message-ID: <056.07ddd4b6e3ac2bc4910ad07b46931150@localhost> #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions --------------------------------------------------------------+------------- Reporter: eflister | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Severity: trivial | Resolution: Keywords: language pragma extensions error message warning | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------------------------------+------------- Comment (by eflister): not to be annoying, but i don't understand why it's not ok for ghc to accept (with a warning) a SUPERSET of the official syntax. that doesn't change the standard and it doesn't imply that any other compiler has to do anything different. a warning would be the best user interaction -- "i know what you meant to say, and i'm doing it, you should just know that what you said isn't portable, and here's how to fix it. would you like me to fix it for you?" -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 9 16:23:28 2009 From: trac at galois.com (GHC) Date: Mon Nov 9 15:59:21 2009 Subject: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions In-Reply-To: <047.73fc8cca3ba98859dc9d57483a25d637@localhost> References: <047.73fc8cca3ba98859dc9d57483a25d637@localhost> Message-ID: <056.73d772dc4e0bae884c290dff77879d19@localhost> #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions --------------------------------------------------------------+------------- Reporter: eflister | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Severity: trivial | Resolution: Keywords: language pragma extensions error message warning | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------------------------------+------------- Comment (by duncan): Replying to [comment:2 eflister]: > not to be annoying, but i don't understand why it's not ok for ghc to accept (with a warning) a SUPERSET of the official syntax. At first you'd expect that accepting a superset would not cause any problems. However what happens is that people will start using that new syntax and then suddenly those packages/programs cannot be used with the tools that stick to the official syntax. > that doesn't change the standard and it doesn't imply that any other compiler has to do anything different. It doesn't change the official standard but it does change the de-facto standard, and other compilers and tools will have to change to keep up so that they can continue to process all code that people write. > a warning would be the best user interaction -- "i know what you meant to say, and i'm doing it, you should just know that what you said isn't portable, and here's how to fix it. would you like me to fix it for you?" Certainly a nice error message is good however I would suggest that it be "i know what you meant to say, here's how to fix it." (and perhaps an IDE could also do "would you like me to fix it for you?"). Also accepting the program has a low benefit and a non-trivial cost. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 9 23:49:14 2009 From: trac at galois.com (GHC) Date: Mon Nov 9 23:25:26 2009 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> Message-ID: <060.e19ffd623d3ed7e3bf25d81be1ad274a@localhost> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by lambda_belka): * cc: lambda-belka@yandex.ru (added) Comment: This restriction was a very unpleasant surprise. Double maintenance problem. It's hard to believe, that the feature is so hard to enable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 10 00:34:43 2009 From: trac at galois.com (GHC) Date: Tue Nov 10 00:10:36 2009 Subject: [GHC] #3650: Add a Natural number type to the pre-defined basic types. Message-ID: <044.8f2b020c1c43231e9e02b324d5f95775@localhost> #3650: Add a Natural number type to the pre-defined basic types. -----------------------------+---------------------------------------------- Reporter: JohnD | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler (Type checker) Version: | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- See [http://hackage.haskell.org/trac/haskell-prime/wiki/Natural] concerning "Add a Natural number type to the pre-defined basic types." I will add a link from that page to this one. That was the Haskell prime wiki which is my understanding concerns discussions concerning the Haskell language in general. It seems conceivable that GHC may be uniquely positioned to address this problem. Haskell was designed to explorer a problem that is of academic interest. Why else is the language lazy and statically typed? It's all about purity. To provide a synopsis it dates back to the discovery that untyped lambda calculus is a model of computation and not that of logic. At first blush one might conclude that there is good reason why there is no natural number type. Natural numbers are problematic. For example, you can add them, but you cannot in general subtract them. In the general case subtraction yields an integer type, not a natural number type. This problem could be solved through duck typing, but that isn't what Haskell or ML is about. With duck typing you can compare two values at runtime to ensure that the result yields a natural number thus upholding the type system. Though duck typing is useful it is naturally off the table. A natural number type could be included in the language, but such an addition without the benefit of duck typing might be looked upon as ad hoc. You get the nat type for abbreviated natural number in proof assistants. Some proof assistants are built using the Haskell language in fact. It is my impression that ML has been around longer than Haskell; consequently, most proof assistants are built on ML and not Haskell. I recall that GHC has moved from System F to a subset of dependent types and can therefore handle some problems involving dependent types. Nat seems to me to potentially be such a problem. Dependent types and proof assistants are like bread and butter. You prove by semi-automated methods at compile time that one number is necessarily not less than another and thereby prove that the difference at runtime cannot be negative. A natural number is an integer that depends on a number, a lower bound, namely zero. As such it seems likely that natural numbers are a dependent type. I am not sufficiently familiar with GHC at the present time to assess whether or not if the natural number dependent type can be resolved automatically by GHC. It is, however, something I have wondered about and may be something worth considering. With the inclusion of a natural number type if it proves feasible suggests that interval types may also be possible. The Ada language has an interval type in that array bounds are made explicit. The point is there are special cases where such types can be resolved at compile time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 10 02:02:10 2009 From: trac at galois.com (GHC) Date: Tue Nov 10 01:39:02 2009 Subject: [GHC] #1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets In-Reply-To: <045.d93d26e0bae3aef3676683e1847e945d@localhost> References: <045.d93d26e0bae3aef3676683e1847e945d@localhost> Message-ID: <054.e98de44468a9d726cd1625c2db406671@localhost> #1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets ----------------------------------------+----------------------------------- Reporter: sorear | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.7 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by BenMoseley): * cc: ben@moseley.name (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 10 03:48:44 2009 From: trac at galois.com (GHC) Date: Tue Nov 10 03:24:40 2009 Subject: [GHC] #3651: GADT type checking too liberal Message-ID: <060.8d4fb310d54f3275d8ff7d8a2f64996f@localhost> #3651: GADT type checking too liberal ----------------------------------+----------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ----------------------------------+----------------------------------------- I would expect the following three functions to fail: {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} module Unsafe where data Z a where U :: Z () B :: Z Bool unsafe1 :: Z a -> Z a -> a unsafe1 B U = () unsafe2 :: a ~ b => Z b -> Z a -> a unsafe2 B U = () unsafe3 :: a ~ b => Z a -> Z b -> a unsafe3 B U = True }}} But they are all accepted. In unsafe1 it seems pattern matching on the second argument discards any information learned from pattern matching on the first, while in the other two functions it seems the equality constraints are not checked at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 10 05:49:29 2009 From: trac at galois.com (GHC) Date: Tue Nov 10 05:25:20 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.584a859ca82ddd72e0ef03d979a3e87b@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by shelbymoore3): * status: closed => reopened * resolution: wontfix => Comment: Replying to [comment:6 igloo]: > Thanks for the suggestion, but if you would like to propose changes to the libraries, please see: > http://www.haskell.org/haskellwiki/Library_submissions Thanks for the pointer very much. That sure seems like overkill in terms of someone who just wants to spend a few minutes to contribute an idea. Are you sure you want to squelch the ideas-only submissions? I think successful mainstream paradigms encourage participation. > However, a few things come to mind with your proposed change: > * If you did change the Prelude `iterate` rather than adding a new function, then you would probably break lots of code How so? I have overloaded `iterate` on input and output type. Thus my proposed function shouldn't even be selected by the compiler for use with existing usage of `iterate`. > * Your definition retains the whole list, so could cause space leaks That is the whole point. "space leak" means lazy evaluation cache, which is precisely what one wants sometimes, and when they don't want it, one should use another construct: http://www.coolpage.com/commentary/economic/shelby/Functional_Programming_Essence.html#Allocation_Size_Determinism > * `last` takes time linear in the length of its input, so performance where you want the last element (as current uses of `iterate` do) will not be good But of course this change has nothing to do with current uses of `iterate`. It is a new function which iterates on entire lists in "free point" style of functional composition. That is the whole point. Let's be careful to not jump too quickly to "won't fix" or "we don't accept ideas here". Sorry I am not yet knowledgeable about applying a patch to the source code of the libraries. I do not think that should be an impediment to submitting an idea. Why can't you have an area of this hackage of open suggestions for library enhancements, so that others can implement and apply the head patches at their leisure? Thanks for making those points, so I could clarify. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 10 06:28:07 2009 From: trac at galois.com (GHC) Date: Tue Nov 10 06:04:06 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.02d6086335f12730370fb91b2054fdf0@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by malcolm.wallace@cs.york.ac.uk): * status: reopened => closed * resolution: => wontfix Comment: Replying to [comment:7 shelbymoore3]: > > Thanks for the suggestion, but if you would like to propose changes to the libraries, please see: > > http://www.haskell.org/haskellwiki/Library_submissions > > Thanks for the pointer very much. That sure seems like overkill in terms of someone who just wants to spend a few minutes to contribute an idea. Are you sure you want to squelch the ideas-only submissions? I think successful mainstream paradigms encourage participation. It is exactly to encourage participation and consensus (rather than drive- by changes) that the Library submission guidelines exist. If you are not yet at a stage where you can create a patch yourself, then the best advice would be to post ideas on a mailing list like haskell-cafe@ or libraries@, in order to create discussion, gather support, and maybe persuade someone else to implement your idea as a patch. Posting ill-formed ideas to a bug-tracker (intended for a small number of core developers) is much less productive than using a dedicated discussion forum filled with many helpful users. > > * If you did change the Prelude `iterate` rather than adding a new function, then you would probably break lots of code > > How so? I have overloaded `iterate` on input and output type. Thus my proposed function shouldn't even be selected by the compiler for use with existing usage of `iterate`. The Prelude 'iterate' is not currently overloaded, so making it overloaded may force type-inference changes in many usage positions, some of which may now become ambiguous and hence be rejected. Furthermore, your proposed overloading is not parametric in a way that can easily be captured by type classes. What is the least generalisation of the the two signatures for iterate? {{{ iterate :: (a -> a) -> a -> [a] iterate :: ([a] -> [a]) -> [a] -> [a] }}} Hint: there isn't one. > But of course this change has nothing to do with current uses of `iterate`. It is a new function which iterates on entire lists in "free point" style of functional composition. That is the whole point. If it is a new function, unrelated to the existing one, then propose a new name for it, and you will likely find people more receptive to the suggestion. > Let's be careful to not jump too quickly to "won't fix" or "we don't accept ideas here". "Won't fix" is not a moral judgement - it is just a bug-tracker tag. It usually means the ticket is incomplete, or posted to the wrong place, or that a reported bug is not a bug at all. > Why can't you have an area of this hackage of open suggestions for library enhancements, so that others can implement and apply the head patches at their leisure? The bug-tracker is usually not the best place to post new ideas for feature requests, at least until they have been suggested and discussed in a open forum like a mailing list or IRC channel. Acceptance and refinement by the wider community is crucial. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 10 07:08:15 2009 From: trac at galois.com (GHC) Date: Tue Nov 10 06:44:15 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.02234d233cc6a4ac2528f739a0559f9a@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by shelbymoore3): Replying to [comment:8 malcolm.wallace@cs.york.ac.uk]: > It is exactly to encourage participation and consensus (rather than drive-by changes) that the Library submission guidelines exist. If you are not yet at a stage where you can create a patch yourself, then the best advice would be to post ideas on a mailing list like haskell-cafe@ or libraries@,... I didn't realize there was list specific to libraries. haskell-cafe@ would be much too noisy for such a small tweak change proposal as this. > ...in order to create discussion, gather support, and maybe persuade someone else to implement your idea as a patch. That is reasonable, except that small tweaks can be easily buried in a mailing list. I think a database format is preferable. I can't imagine the efficiency having my TODO list of ideas for some of the major projects I have worked on, being spread out in a mailing list. Also it is well known that consensus is not the way to write the best software. Small teams slaughter large monoliths. Perhaps libraries@ is focused enough. I am not going to bother, I was just passing along to remind you guys that you forgot to generalize `iterate` for lists. Aren't lists a very important fundamental data structure in Haskell that is covered by just about every other library function? But no big deal, I can write my own function. Why bother helping you by passing along the missing `iterate` for lists. > Posting ill-formed ideas to a bug-tracker (intended for a small number of core developers) is much less productive than using a dedicated discussion forum filled with many helpful users. This idea is not ill-formed. > > > * If you did change the Prelude `iterate` rather than adding a new function, then you would probably break lots of code > > > > How so? I have overloaded `iterate` on input and output type. Thus my proposed function shouldn't even be selected by the compiler for use with existing usage of `iterate`. > > The Prelude 'iterate' is not currently overloaded, so making it overloaded may force type-inference changes in many usage positions, some of which may now become ambiguous and hence be rejected. Perhaps that is because type inference doesn't scale and should be avoided entirely, except for local usage: http://lambda-the-ultimate.org/node/1277 (see slide #67) Any one who relies on type inference globally can except such domino cascades generally. > Furthermore, your proposed overloading is not parametric in a way that can easily be captured by type classes. What is the least generalisation of the the two signatures for iterate? > > {{{ > iterate :: (a -> a) -> a -> [a] > iterate :: ([a] -> [a]) -> [a] -> [a] > }}} > > Hint: there isn't one. If I am not mistake, a type class can specify the signature that it expects. > If it is a new function, unrelated to the existing one, then propose a new name for it, and you will likely find people more receptive to the suggestion. The name of a function implies its general semantics (function/purpose), and the type signature further narrows the semantics. > "Won't fix" is not a moral judgement - it is just a bug-tracker tag. It usually means the ticket is incomplete, or posted to the wrong place, or that a reported bug is not a bug at all. Incomplete would be a more accurate tag than "won't fix". You do not know you won't end up fixing this when someone completes the library patch, or if you do, then your suggestion to me above was to waste my time. > The bug-tracker is usually not the best place to post new ideas for feature requests, at least until they have been suggested and discussed in a open forum like a mailing list or IRC channel. Acceptance and refinement by the wider community is crucial. Yeah and it only took 20 years for Haskell to get here. It is not totally unreasonable, except it doesn't scale. You are going to have adjust if Haskell is going to move out of the research and into mainstream, then busy business people are going to come and make quick inputs, and if you shut them out, then you are shooting yourself in the foot. We do not have time to go figure out all the little nuances of where you do you "consensus" communications on the side. Becoming a tenured member of the community should not be a requirement, because it does not scale. You are really intelligient, but please do not forget the exponential function and the concept of scale. Best regards. I did not modify the ticket status. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 10 07:40:54 2009 From: trac at galois.com (GHC) Date: Tue Nov 10 07:16:54 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.ee3f5118f9818469d0684a806b523dee@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by shelbymoore3): Replying to [comment:9 shelbymoore3]: > Any one who relies on type inference globally can except such domino cascades generally. Typo 'except' to 'expects'. > > Furthermore, your proposed overloading is not parametric in a way that can easily be captured by type classes. What is the least generalisation of the the two signatures for iterate? > > > > {{{ > > iterate :: (a -> a) -> a -> [a] > > iterate :: ([a] -> [a]) -> [a] -> [a] > > }}} > > > > Hint: there isn't one. > > > If I am not mistake, a type class can specify the signature that it expects. I do assume above that Haskell will not allow a type '[a]' where a type 'a' is expected. If type inference is allowing lists of types to be assumed where only a type was expected, then IMHO that was a mistake that opened a very big can of worms. Perhaps I am unaware of some usage that could not be accomplished otherwise, but it sure seems intuitive to me that conflation inference in that way would kill scale. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 10 09:25:23 2009 From: trac at galois.com (GHC) Date: Tue Nov 10 09:01:31 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.814a06e970dfe0b988c3ee5b889581ac@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by malcolm.wallace@cs.york.ac.uk): Replying to [comment:9 shelbymoore3]: > That is reasonable, except that small tweaks can be easily buried in a mailing list. I agree that sometimes they get lost - but that can also be a sign of lack of support within the community. If a proposed change cannot gather an enthusiastic crowd who want it implemented, then the idea just isn't worth the effort of changing all the consequentially-impacted software etc to support it. > Also it is well known that consensus is not the way to write the best software. Small teams slaughter large monoliths. The Haskell community values consensus, especially on standard and far- reaching components like the Prelude. > This idea is not ill-formed. Has anyone pointed out yet that your 'iterate' function is non- terminating? Each recursive call builds a larger data structure (or rather, a thunk for it), but there is no base-case to the recursion, so no value is ever returned to the caller. This is the kind of beginner's mistake that is posted (and ironed out) every day on haskell-cafe@, or beginners@. The input of the community really can help you write better (working) code. > Perhaps that is because type inference doesn't scale and should be avoided entirely, except for local usage: You will find it hard to convince anyone in the Haskell community that type inference is a bad idea. :-) > It is not totally unreasonable, except it doesn't scale. You are going to have adjust if Haskell is going to move out of the research and into mainstream, then busy business people are going to come and make quick inputs, and if you shut them out, then you are shooting yourself in the foot. Letting any beginner who has studied Haskell for one week, modify the Prelude that is used by every Haskell programmer everywhere, without discussion and consensus, is what does not scale. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 10 10:59:06 2009 From: trac at galois.com (GHC) Date: Tue Nov 10 10:35:09 2009 Subject: [GHC] #3652: Gettting error while running configure Message-ID: <045.eff9bb915ab699f8c1f45362bb86aacf@localhost> #3652: Gettting error while running configure -------------------+-------------------------------------------------------- Reporter: cheram | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.4 | Severity: major Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- HI, While i run the configure i am getting the following error. Please suggest me how to overcome. x86_32/bin:/arm/tools/arm/lyra-pkg/2.01/common:/arm/tools/arm/depot- build/2.01/common/bin:/arm/tools/arm/depot- build/2.01/rhe4-x86_32/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Which we'll further canonicalise into: i386-unknown-linux checking for path to top of build tree... pwd: timer_create: Invalid argument configure: error: cannot determine current directory tmk: child process exited abnormally tmk: tmk: exiting. tmk: exiting. while executing "error "${::__OutputPrefix} exiting."" invoked from within "if $::__DbgLevel { Thanks, Chetan -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 10 12:15:22 2009 From: trac at galois.com (GHC) Date: Tue Nov 10 11:51:22 2009 Subject: [GHC] #3605: Dll's freeze with -threaded In-Reply-To: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> References: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> Message-ID: <060.d7074d3a6e7bdead7df891a68e17870d@localhost> #3605: Dll's freeze with -threaded ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by NeilMitchell): I suggest the docs are rewritten to tell people never use DllMain, and just say that "calling either hs_init or hs_exit from DllMain may lead to program freezes - don't do it". That section also has two examples - one calling from C, and one from VBA. I suggest a complete rewrite showing how to create a single unified example DLL, then how to call it from both VBA and C++, never using DllMain in either case. If that sounds satisfactory, I'll make the changes to the docs and send a patch in. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 10 19:14:34 2009 From: trac at galois.com (GHC) Date: Tue Nov 10 18:50:23 2009 Subject: [GHC] #3653: "Missing header file: HsDirectory.h" with old kernel/glibc Message-ID: <045.922678c7ce1ad1539e29e51bb27ac78c@localhost> #3653: "Missing header file: HsDirectory.h" with old kernel/glibc -----------------------------+---------------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Component: libraries/directory Version: 6.12.1 RC1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Configuring ghc-6.12.1rc1 on a machine with linux kernel 2.6.9 and glibc 2.3.4 gives: {{{ $ ./configure [...] Configuring directory-1.0.1.0... [...] configure: creating ./config.status config.status: creating include/HsDirectoryConfig.h ghc-cabal: Missing dependency on a foreign library: * Missing header file: HsDirectory.h [...] }}} The file {{{HsDirectory.h}}} is actually there, but it fails to compile. {{{ $ cd libraries/directory $ runhaskell Setup configure -v3 [...] include/HsDirectory.h:58: error: syntax error before "__hscore_S_IRUSR" include/HsDirectory.h:59: error: syntax error before "__hscore_S_IWUSR" include/HsDirectory.h:60: error: syntax error before "__hscore_S_IXUSR" include/HsDirectory.h:61: error: syntax error before "__hscore_S_IFDIR" [...] }}} The problem can be fixed by adding {{{#include }}} at the beginning of {{{HsDirectory.h}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 00:50:26 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 00:26:19 2009 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries Message-ID: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> #3654: Mach-O GHCi linker lacks support for a range of relocation entries --------------------+------------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.13 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- The Mach-O code of the GHCi linker `rts/Linker.c` lacks support for a range of relocation entries. It used to silently ignore many of them. The following patch makes it barf() when it encounters an unsupported entry: {{{ Wed Nov 11 13:07:12 EST 2009 Manuel M T Chakravarty * Barf on unhandled Mach-O relocations in the ghci linker - It might be worthwhile to MERGE this to 6.12, BUT somebody should validate it on PPC/Mac OS X first. }}} Moreover, at least one entry type ?i.e., `GENERIC_RELOC_LOCAL_SECTDIFF`? is not correctly implemented. This is an unsatisfactory situation as the transition from Mac OS X 10.5 (Leopard) to 10.6 (Snow Leopard) showed. In that case, changes in `ld` suddenly created a so far unsupported entry type. This was before the above patch; so, the ignored entry led to an incorrectly relocated image, which crashed GHCi with a SIGBUS. Instead of trying to improve the dynamic linker, IMHO, GHC should use dynamic libraries with `dlopen()` and leave the implementation of dynamic linking to the OS vendor. This has a number of advantages: * The RTS gets smaller & simpler, and we eliminate a whole category of potentially tricky bugs. * Dynamically loaded code can use dtrace probes (and other features requiring linker trickery). * Packages that GHC links to, don't need to be in memory twice (once statically and once dynamically linked). * Potential performance advantage due to optimisations in the OS' dynamic linker. The main obstacle with using dynamic libraries and `dlopen()` appears to be the required on-the-fly conversion of GHC-generated object files into dynamic libraries. Otherwise, SimonM says that it is already possible to compile GHC itself dynamically-linked at the moment that the linker will then use `dlopen()` for loading packages. More details are in the following thread on `cvs-ghc@haskell.org`: [http://www.haskell.org/pipermail/cvs-ghc/2009-November/050941.html] [http://www.haskell.org/pipermail/cvs-ghc/2009-October/050893.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 01:57:38 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 01:33:40 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.4f70410a31cb5cae68a910cd8df6e623@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by shelbymoore3): Replying to [comment:11 malcolm.wallace@cs.york.ac.uk]: > Replying to [comment:9 shelbymoore3]: > > That is reasonable, except that small tweaks can be easily buried in a mailing list. > > I agree that sometimes they get lost - but that can also be a sign of lack of support within the community. If a proposed change cannot gather an enthusiastic crowd who want it implemented, then the idea just isn't worth the effort of changing all the consequentially-impacted software etc to support it. That is what I now call the Obama illogic. Here is a story about the wisdom (mass delusion) of crowds from 4000 years ago: http://goldwetrust.up-with.com/biblical-f3/god-s-governance-t129.htm#2313 Or perhaps you prefer the more scientific version: http://esr.ibiblio.org/?p=984 > > > Also it is well known that consensus is not the way to write the best software. Small teams slaughter large monoliths. > > The Haskell community values consensus, especially on standard and far- reaching components like the Prelude. By you own (il)logic, you must cite a consensus on that before you autonomously attempt such a proclamation. ;) How dare you try to cut corners and be efficient (joke)! ...the socialist dog chases his tail... I never proposed that my change be accepted without review of the community. I was only proposing that I be able to post my vote/suggestion efficiently (geez I really didn't want to diatribe you) and in an organized database. I take it that efficiency is too much to ask, unless you have tenure, then it is not. I didn't run my software projects this way when I was the lead developer or a key one interfacing with QA. I do not understand what is gained by discouraging input, other than laziness to add an 'incomplete' tag. The size of the database costs you nearly nothing. If you are saying the time to read, consider and tag the input is too costly, I can argue you are never going to stop that (especially as something becomes more mainstream), unless you restrict access. In that case, you lose informational input also. There is no free lunch in the free market. Generally I think flattening the model is best (hierarchies do not scale well, they are brittle and rigid forming), and be clever about efficiency. Often a clever `RegEx` is enough to work wonders on productivity. > > This idea is not ill-formed. > > Has anyone pointed out yet that your 'iterate' function is non- terminating? The standard Prelude function does not "terminate" either (is infinitely recursive): http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC- List.html#iterate That is the whole point of the function! It is taking advantage of lazy evaluation caching, so the infinite list is only recursed as far as is needed by the usage the function. In my example use case, e.g. `fibs !! index`. > Each recursive call builds a larger data structure (or rather, a thunk for it), but there is no base-case to the recursion, so no value is ever returned to the caller. This is the kind of beginner's mistake that is posted (and ironed out) every day on haskell-cafe@, or beginners@. The input of the community really can help you write better (working) code. So you are saying the standard Prelude was writting by beginners? ;) Seems in one week I am somewhat ahead of your understanding, or am I somehow missing your point entirely? > > Perhaps that is because type inference doesn't scale and should be avoided entirely, except for local usage: > > You will find it hard to convince anyone in the Haskell community that type inference is a bad idea. :-) If adding one overload to standard library function can break massive amounts of code, I do not need to convince anyone. The market will prove it. Socialists do not understand the power of the market. They have to re-learn the lessons of 4000 years ago, infinite times repeated (or maybe not, if you believe in an end time). > > It is not totally unreasonable, except it doesn't scale. You are going to have adjust if Haskell is going to move out of the research and into mainstream, then busy business people are going to come and make quick inputs, and if you shut them out, then you are shooting yourself in the foot. > > Letting any beginner who has studied Haskell for one week, modify the Prelude that is used by every Haskell programmer everywhere, without discussion and consensus, is what does not scale. I did not modify the Prelude with this feature suggestion. I am only suggesting (not demanding) this suggestion be marked incomplete instead of "won't fix", and be entered into the database of things people can search for in future when looking for something to work on or explore. And so far, looks like this beginner has made a reasonable strong case ;) Or at least not "ill formed". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 04:50:04 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 04:26:04 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.ffddfa97e7e2d5a646194d8cab18304f@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by shelbymoore3): > > Has anyone pointed out yet that your 'iterate' function is non- terminating? Ah, I see your point now. I had a typo in my function, here is the obvious correction: {{{ iterate f x = x ++ iterate f (x ++ (f x)) }}} I thought you meant that it was infinitely recursive (which obviously standard Prelude is also), then I realized you meant that the function never returned a list. I wish you would have said that. Actually I should modify the proposal and my usage to be more consistent with the current Prelude `iterate` and for maximum generality: {{{ iterate f x = x ++ iterate f (f x) }}} Then my usage example changes to: {{{ fibs = iterate (\x -> x ++ [last x + last init x]) [ 0 : 1 ] where }}} Actually I think the way to solve the collision with standard Prelude is to make an overload of `iterate` that is even more general (but then this requires the dreaded type inference or `a` meaning also `[a]`), so thus I don't recommend this: {{{ iterate :: (a -> a -> [a]) -> (a -> a) -> a -> [a] iterate op f x = x 'op' iterate f (f x) }}} {{{ fibs = iterate (++) (\x -> x ++ [last x + last init x]) [ 0 : 1 ] where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 05:04:15 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 04:40:13 2009 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> Message-ID: <050.abec0ee2cc60ddf626558ab0cb5d49dd@localhost> #2721: Newtype deriving doesn't work with type families -------------------------------------------+-------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2721 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by test): * cc: tom.schrijvers@cs.kuleuven.be (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 05:27:36 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 05:03:31 2009 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries In-Reply-To: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> References: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> Message-ID: <052.79316452a8a719772b24140526013ca1@localhost> #3654: Mach-O GHCi linker lacks support for a range of relocation entries ----------------------------+----------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.13 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple ----------------------------+----------------------------------------------- Changes (by mnislaih): * cc: mnislaih@gmail.com (added) Comment: I really hope this gets fixed for 6.12 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 05:34:27 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 05:10:21 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.c12f67a8016b61547135917da1508009@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by shelbymoore3): Actually none of that above works, we need instead an accumulator argument for the list, which solves the collision problem with standard Prelude `iterate` also: {{{ iterate :: ([a] -> [a]) -> [a] -> [a] -> [a] iterate f x y = y ++ iterate f (x ++ (f (x ++ y))) (f (x ++ y)) }}} {{{ fibs = 0 : 1 : iterate (\x -> [last x + last init x]) [ 0 : 1 ] [] where }}} IMHO, it is not most productive to mark useful input as "Won't fix", and have it disappear into a black-hole. It is more productive to mark as "Incomplete" and let people apply their effort later to make it complete, as has now been done. "Won't fix" should apply to something that should not be fixed (an entirely erroneous report with no chance of being ever fixed), not to something that is in a useful direction, but incomplete. "Won't fix" is effectually little different than a moral judgment, because it is a black hole. It is analogous to telling someone sorry you were misclassified on the "do not fly list" and are spending the rest of your vacation in a DHS holding area, but be comforted that it was not a moral mis-classification. Who cares. Give me back my vacation and my wasted time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 05:47:18 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 05:23:08 2009 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> Message-ID: <052.940bf476ea633efa3b5d82a46e4903e1@localhost> #2289: Needless reboxing of values when returning from a tight loop -------------------------------------------+-------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: boxing, loops, performance | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Comment (by simonmar): I believe this example fits into the same category. We have a recursive tree traversal in the `ST` monad that returns an `Int`, and we want the `Int` unboxed. Here's the complete code, both the version that doesn't optimise as well as we'd like, and the hand-optimised version: {{{ {-# LANGUAGE BangPatterns, UnboxedTuples, MagicHash #-} module Test where import Data.Array.ST import Control.Monad.ST import Data.Array.Base import GHC.ST import GHC.Exts data Tree = Nil | Node {-#UNPACK#-} !Int !Tree !Tree {-#UNPACK#-} !Int #if 0 -- The code we want to write traverse :: Tree -> STUArray s Int Int -> ST s Int traverse Nil !arr = return 0 traverse (Node item child alt w) !arr = do childw <- traverse child arr altw <- traverse alt arr itemw <- unsafeRead arr item unsafeWrite arr item (itemw + childw + w) return $! childw + w + altw #else -- The code we have to write traverse :: Tree -> STUArray s Int Int -> ST s Int traverse tree arr = ST $ \s -> case traverse' tree arr s of { (# s', i #) -> (# s', I# i #) } where traverse' Nil !arr s = (# s, 0# #) traverse' (Node item child alt w@(I# w#)) !arr s0 = case traverse' child arr s0 of { (# s1, childw #) -> case traverse' alt arr s1 of { (# s2, altw #) -> case unsafeRead arr item of { ST f -> case f s2 of { (# s3, I# itemw #) -> case unsafeWrite arr item (I# itemw + I# childw + w) of { ST f -> case f s2 of { (# s4, _ #) -> (# s4, childw +# w# +# altw #) }}}}}} #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 05:55:57 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 05:31:55 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.a576c93b50b209e2319e6d0bd0502dd2@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by shelbymoore3): Better: {{{ fibs = iterate (\x -> [last x + last init x]) [] [ 0 : 1 ] where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 06:06:55 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 05:42:42 2009 Subject: [GHC] #3655: Performance regression relative to 6.10 Message-ID: <047.de41e91ed6bceb6d2068db2adb01f317@localhost> #3655: Performance regression relative to 6.10 ---------------------------------------+------------------------------------ Reporter: simonmar | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ The attached program runs more slowly when compiled with 6.12 compared to 6.10. The current HEAD is also worse than 6.10, but not as bad as 6.12. The results are below, on x86-64/Linux, first with -O: {{{ time allocation 6.10.2 9.6s 6.5GB 6.12.20091011 11.0s 7.5GB 6.13.20091111 10.2s 6.2GB }}} Interestingly, `-O2` makes things even worse with 6.12, but makes things slightly better with both 6.10 and 6.13: {{{ time allocation 6.10.2 9.5s 6.5GB 6.12.20091011 11.8s 7.5GB 6.13.20091111 10.1s 6.2GB }}} It may be that there is some degradation due to the new IO library, since the program generates a fair amount of output. That may account for some of the difference between 6.10.2 and 6.12/6.13, but it doesn't account for the difference between 6.12 and 6.13, which are both using the new IO library. The program is in one module, compile with no special options. To run it: {{{ ./pHlcm mushroom.dat 100 >/dev/null +RTS -s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 06:33:26 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 06:09:21 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.51cda63fe6bf37356c2a5c096ddd0e41@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by shelbymoore3): Correction: {{{ iterate f x y = y ++ iterate f (x ++ (f x)) (f x) }}} {{{ fibs = 0 : 1 : iterate (\x -> [last x + last init x]) [ 0 : 1 ] [] where }}} Alternative (IMHO the best): {{{ iterate f x = x ++ iterate' f x [] where iterate' f x y = y ++ iterate' f (x ++ (f x)) (f x) }}} {{{ fibs = iterate (\x -> [last x + last init x]) [ 0 : 1 ] where }}} Alternative (less general): {{{ iterate :: ([a] -> a) -> [a] -> a -> [a] iterate f x y = y : iterate f (x ++ [(f x)]) (f x) }}} {{{ fibs = 0 : iterate (\x -> last x + last init x) [0] 1 where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 06:59:17 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 06:35:15 2009 Subject: [GHC] #3631: Overload the Prelude iterate to support list input In-Reply-To: <051.646cea9a90aceb1e42e96d631b059b64@localhost> References: <051.646cea9a90aceb1e42e96d631b059b64@localhost> Message-ID: <060.44fbf50e966a7dd97e1531f9a85b7588@localhost> #3631: Overload the Prelude iterate to support list input ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Can we have an end to this please? Shelby, please take the discussion to the libraries list as Malcolm has already suggested. Clearly you're new to the community, please take the time to acquaint yourself with our working practices. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 07:08:57 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 06:44:48 2009 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries In-Reply-To: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> References: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> Message-ID: <052.f2548068bf28ea8a1591952eb058d663@localhost> #3654: Mach-O GHCi linker lacks support for a range of relocation entries ---------------------------------+------------------------------------------ Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.12 branch Comment: This ticket goes off topic a bit. Is it a report about the lack of support for certain relocations, or a feature request for the use of the system dynamic linker in GHCi? Regarding the latter, I think we should move the discussion elsewhere (cvs-ghc or glasgow-haskell-users). Let's leave this ticket for the lack of support for relocations, which may be subsumed by dynamic linking if that happens. Replying to [comment:1 mnislaih]: > I really hope this gets fixed for 6.12 I'm not sure which part of the ticket you're referring to: using the system dynamic linker is definitely not going to happen for 6.12, and the missing relocation types almost certainly aren't affecting you, are they? If they are affecting you, we should make this bug a high prio. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 07:10:30 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 06:46:19 2009 Subject: [GHC] #3653: "Missing header file: HsDirectory.h" with old kernel/glibc In-Reply-To: <045.922678c7ce1ad1539e29e51bb27ac78c@localhost> References: <045.922678c7ce1ad1539e29e51bb27ac78c@localhost> Message-ID: <054.95e1ed66895191ec79be8e1d799516b8@localhost> #3653: "Missing header file: HsDirectory.h" with old kernel/glibc ------------------------------------+--------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/directory | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: easily fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 07:11:31 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 06:47:28 2009 Subject: [GHC] #3605: Dll's freeze with -threaded In-Reply-To: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> References: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> Message-ID: <060.915ae357b283e4d0e6230765fb766d28@localhost> #3605: Dll's freeze with -threaded ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Sounds great to me. Thanks for offering to do this Neil! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 07:31:06 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 07:06:55 2009 Subject: [GHC] #3630: Suggested algorithm to control upper bound of space "leaks" In-Reply-To: <051.72af98bc6de8e1372fe3431e4a8c348a@localhost> References: <051.72af98bc6de8e1372fe3431e4a8c348a@localhost> Message-ID: <060.7a132a9cf5a0b20c4a255382603a53b9@localhost> #3630: Suggested algorithm to control upper bound of space "leaks" ---------------------------------+------------------------------------------ Reporter: shelbymoore3 | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * type: proposal => feature request * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 08:07:31 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 07:43:26 2009 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries In-Reply-To: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> References: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> Message-ID: <052.f72da07884e6357bfa3e55e4ea9a4701@localhost> #3654: Mach-O GHCi linker lacks support for a range of relocation entries ---------------------------------+------------------------------------------ Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by mnislaih): Replying to [comment:2 simonmar]: > Replying to [comment:1 mnislaih]: > > I really hope this gets fixed for 6.12 > > I'm not sure which part of the ticket you're referring to: using the system dynamic linker is definitely not going to happen for 6.12, and the missing relocation types almost certainly aren't affecting you, are they? If they are affecting you, we should make this bug a high prio. Nevermind. I just wanted to show my support to ghci 6.12 working on Snow Leopard, which as I understood after a quick read, motivated this ticket. But on a second read I see that the new unsupported entry type has been implemented, and ghci will continue working in snow leopard. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 08:13:48 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 07:50:31 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.7e37729fde1d9ecf849c436cc2609688@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by galdor): * cc: khaelin@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 10:12:56 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 09:48:44 2009 Subject: [GHC] #3586: Initialisation of unboxed arrays is too slow In-Reply-To: <046.d37b803347b32ce78018550b0e0c0244@localhost> References: <046.d37b803347b32ce78018550b0e0c0244@localhost> Message-ID: <055.685865f6667e3542e935a80361d9c520@localhost> #3586: Initialisation of unboxed arrays is too slow -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: simonmar Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I have verified that 6.13.20091111 doesn't have this bug, and I'm testing a patch for 6.12.1 to work around it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 11:12:26 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 10:48:15 2009 Subject: [GHC] #3656: ghci leaves /tmp/ghc* directory if killed by signal Message-ID: <042.d95f8802b8c0b09855d12a49e63b7a91@localhost> #3656: ghci leaves /tmp/ghc* directory if killed by signal -----------------------------+---------------------------------------------- Reporter: vvv | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I was wondering where do numerous /tmp/ghc${PID}_0 directories come from. And noticed that they are not removed when I kill (close) '*haskell*' Emacs buffer instead of typing ':q' in ghci prompt... I've investigated this problem down to ghci: when ghci has an .hs file `:load`-ed and is killed with SIGHUP or SIGTERM signal, it leaves /tmp/ghc${PID}_0 directory. {{{ $ ls -d /tmp/ghc* ls: cannot access /tmp/ghc*: No such file or directory $ ghci *.hs & [1] 26384 $ GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( proxy-POC.hs, interpreted ) Ok, modules loaded: Main. *Main> $ ls -d /tmp/ghc* /tmp/ghc26384_0 [1]+ Stopped ghci *.hs $ kill -HUP %% [1]+ Stopped ghci *.hs $ ls -d /tmp/ghc* /tmp/ghc26384_0 [1]+ Hangup ghci *.hs $ ls -d /tmp/ghc* /tmp/ghc26384_0 $ pgrep ghc $ ps 26384 PID TTY STAT TIME COMMAND }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 16:23:48 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 15:59:39 2009 Subject: [GHC] #3472: Porting through .hc files broken In-Reply-To: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> References: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> Message-ID: <055.f9734aaaf724b060ad1ccdcced66a72f@localhost> #3472: Porting through .hc files broken ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by marco.comini): * cc: marco.comini@dimi.uniud.it (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 16:25:18 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 16:02:16 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.a008d9ae38491ce0e32163c3a662f765@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by marco.comini): * cc: marco.comini@dimi.uniud.it (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 17:25:16 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 17:01:02 2009 Subject: [GHC] #3657: fff-1.0 causes panic in 6.12.20091010 Message-ID: <045.b9b668a0e35a678f68b5b35dd98d4aba@localhost> #3657: fff-1.0 causes panic in 6.12.20091010 -----------------------+---------------------------------------------------- Reporter: tobsan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -----------------------+---------------------------------------------------- After upgrading GHC to 6.12, any Haskell file I try to compile yields this result:[[BR]] {{{ tobsan@magrathea ~/programming/HQmpd/src $ ghci Test.hs GHCi, version 6.12.0.20091010: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ghc-stage2: This ELF file contains no symtab Loading package ffi-1.0 ... ghc-stage2: panic! (the 'impossible' happened) (GHC version 6.12.0.20091010 for x86_64-unknown-linux): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{ tobsan@magrathea ~/programming/HQmpd/src $ cat Test.hs module Test where hej = print "Hej" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 17:45:25 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 17:21:12 2009 Subject: [GHC] #3657: ffi-1.0 causes panic in 6.12.20091010 In-Reply-To: <045.b9b668a0e35a678f68b5b35dd98d4aba@localhost> References: <045.b9b668a0e35a678f68b5b35dd98d4aba@localhost> Message-ID: <054.2eae2440bca3989815ed8b0a9eb1d9a1@localhost> #3657: ffi-1.0 causes panic in 6.12.20091010 ----------------------+----------------------------------------------------- Reporter: tobsan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Changes (by tobsan): * summary: fff-1.0 causes panic in 6.12.20091010 => ffi-1.0 causes panic in 6.12.20091010 Comment: Noticed that it's called FFI and not FFF -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 18:41:07 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 18:16:57 2009 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries In-Reply-To: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> References: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> Message-ID: <052.3aff2d04b7e9bea3df351bba024a57bd@localhost> #3654: Mach-O GHCi linker lacks support for a range of relocation entries ---------------------------------+------------------------------------------ Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by chak): Replying to [comment:2 simonmar]: > This ticket goes off topic a bit. Is it a report about the lack of support for certain relocations, or a feature request for the use of the system dynamic linker in GHCi? Regarding the latter, I think we should move the discussion elsewhere (cvs-ghc or glasgow-haskell-users). Let's leave this ticket for the lack of support for relocations, which may be subsumed by dynamic linking if that happens. Yes, the ticket is about the unsupported relocations and other bugs in the dynamic linker for Mach-O. But IMHO using the system linker is the best way to fix those bugs. (At least, I'd be surprised if anybody would sit down and implement the missing pieces. Personally, I certainly would rather invest the time moving towards using the system linker.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 11 18:58:38 2009 From: trac at galois.com (GHC) Date: Wed Nov 11 18:34:30 2009 Subject: [GHC] #3654: Mach-O GHCi linker lacks support for a range of relocation entries In-Reply-To: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> References: <043.db5a4c9ebf484eb57b87a6d38bef8362@localhost> Message-ID: <052.86e1419eefb803006dcd0fe3c22833b0@localhost> #3654: Mach-O GHCi linker lacks support for a range of relocation entries ---------------------------------+------------------------------------------ Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by chak): Replying to [comment:3 mnislaih]: > Never mind. I just wanted to show my support to ghci 6.12 working on Snow Leopard, which as I understood after a quick read, motivated this ticket. But on a second read I see that the new unsupported entry type has been implemented, and ghci will continue working in snow leopard. I implemented ''one'' of the missing relocations, which prevented GHCi to work on Snow Leopard at all (as it was triggered when loading `integer- gmp`). However, there are more relocations missing. And, to be honest, I didn't even implement the one that I did add properly. To do it, one would need to implement coalesced sections, which AFAIK are completely ignored at the moment. The Mach-O ABI reference has the following to say: >These are important static-linking variants of the symbol type and attributes: > '''Regular sections.''' In a regular section, only one definition of an external symbol may exist in intermediate object files. The static linker returns an error if it finds any duplicate external symbol definitions. > '''Coalesced sections.''' In the final product, the static linker retains only one instance of each symbol defined in coalesced sections. To support complex language features (such as C++ vtables and RTTI) the compiler may create a definition of a particular symbol in every intermediate object file. The static linker and the dynamic linker would then reduce the duplicate definitions to the single definition used by the program. >'''Coalesced sections with weak definitions''' Weak symbol definitions may appear only in coalesced sections. When the static linker finds duplicate definitions for a symbol, it discards any coalesced symbol definition that has the weak definition attribute set (see nlist). If there are no non-weak definitions, the first weak definition is used instead. This feature is designed to support C++ templates; it allows explicit template instantiations to override implicit ones. The C++ compiler places explicit definitions in a regular section, and it places implicit definitions in a coalesced section, marked as weak definitions. Intermediate object files (and thus static archive libraries) built with weak definitions can be used only with the static linker in Mac OS X v10.2 and later. Final products (applications and shared libraries) should not contain weak definitions if they are expected to be used on earlier versions of Mac OS X. I guess we haven't run into problems with that yet only because few people load packages binding to C++ code into GHCi (on Mac OS X). Coalesced sections and the relocations types that are still missing will definitely not be in 6.12 and as I mentioned above, I believe we should work on using the system linker, instead of wasting time on replicating its functionality in subsequent releases. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 05:47:38 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 05:23:23 2009 Subject: [GHC] #3658: Dynamically link GHCi on platforms that support it Message-ID: <047.129d39e2608fc274aa7ba90c094c6a82@localhost> #3658: Dynamically link GHCi on platforms that support it -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- In 6.14.1 we should switch to shipping a dynamically linked GHCi binary, on those platforms for which dynamic linking is supported (currently Linux; MacOS X and Windows support is in progress). == Advantages == * The GHCi binary is smaller * some packages don't need to be loaded on startup: lower memory use * GHCi startup might be quicker (or it might not) * some hacks due to having two copies of the base package are not necessary (see `rts/Globals.c`) * We might save some space in the distributions. * It takes us a step closer to not needing the RTS linker at all * It takes us a step closer to using dynamic linking by default, which is where we want to go ultimately == Potential Issues == * Do we run into any problems with GHCi and the user program sharing the same stdin/stdout/stderr handles? Do we need to virtualise these explicitly in the GHCi front end? * We cannot revert CAFs in packages that are shared by GHC and the user program. There are some old non-working hacks related to reverting CAFs when GHCi is dynamically linked (see `KeepCAFsForGHCi`) that need to be cleaned out. CAFs can only be reverted in code loaded by the RTS linker. We need to think about whether this is a necessary feature or not: we have never supported CAF reverting for interpreted code anyway. One reason to have it was so that you can recover after saying `getContents` at the GHCi prompt, but we can provide other ways to work around that. * There will be installation/binary-dist issues to resolve; currently we don't install any dynamically-linked binaries. == Open questions == * Whether we continue to use the same binary for GHC and GHCi is an open question: it would be possible to provide a separate statically-linked GHC binary if performance of the dynamically-linked version was an issue. * We might as well dynamically-link Haddock, and the other tools that come with GHC too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 07:10:15 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 06:46:01 2009 Subject: [GHC] #3643: building heliumeditor In-Reply-To: <048.0d743250e4ce68e9e979f412d157febf@localhost> References: <048.0d743250e4ce68e9e979f412d157febf@localhost> Message-ID: <057.24887aa17439d380ea1f34f8337ba6fa@localhost> #3643: building heliumeditor ---------------------------------+------------------------------------------ Reporter: cyberpuff | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Right. I believe that 6.12 will indeed ignore bad .hi files rather than panicing. Cf #3535 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 08:03:59 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 07:39:46 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.20c996d0f5cf0adb2537be7cbb018681@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * owner: simonmar => igloo * type: bug => merge Comment: Fixed, eventually. Patches to GHC: {{{ Wed Nov 11 14:28:22 GMT 2009 Simon Marlow * Second attempt to fix #1185 (forkProcess and -threaded) Patch 1/2: second part of the patch is to libraries/base This time without dynamic linker hacks, instead I've expanded the existing rts/Globals.c to cache more CAFs, specifically those in GHC.Conc. We were already using this trick for signal handlers, I should have realised before. It's still quite unsavoury, but we can do away with rts/Globals.c in the future when we switch to a dynamically-linked GHCi. Thu Nov 12 12:58:53 GMT 2009 Simon Marlow * Windows-specific fix for #1185 patch }}} and for libraries/base: {{{ Wed Nov 11 15:19:15 GMT 2009 Simon Marlow * Second attempt to fix #1185 (forkProcess and -threaded) }}} We should merge this into 6.12.1, partly because there is a lot of demand for `forkProcess`, and also because it fixes an infelicity in GHCi whereby a new IO manager thread was being created for each `:load/:reload`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 11:43:28 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 11:19:13 2009 Subject: [GHC] #3659: two-dimensional PArrays in data parallel code Message-ID: <042.8324de31085b57dee762ee81f38b0402@localhost> #3659: two-dimensional PArrays in data parallel code -----------------------------+---------------------------------------------- Reporter: ams | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Hi -- Is it possible to create two-dimensional PArrays? It seems like an expression like {{{ fromList [fromList [1]] }}} would do it (where fromList is from Data.Array.Parallel.Prelude), but a type class constraint seems not to be matched here: {{{ No instance for (Elt (PArray Int)) arising from a use of `fromList' at Main.hs:8:16-42 Possible fix: add an instance declaration for (Elt (PArray Int)) }}} (Details below.) Are there any other ways? Thanks -- Adam Shaw {{{ $ cat Main.hs import Data.Array.Parallel.PArray as P main :: IO () main = do let v2D = P.fromList [P.fromList [1::Int]] print v2D $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.13.20090929 $ ghc -fdph-seq Main.hs Main.hs:6:16: No instance for (Elt (PArray Int)) arising from a use of `fromList' at Main.hs:6:16-47 Possible fix: add an instance declaration for (Elt (PArray Int)) In the expression: fromList [fromList [1 :: Int]] In the definition of `v2D': v2D = fromList [fromList [1 :: Int]] In the expression: do { let v2D = fromList ...; print v2D } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 13:21:23 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 12:57:17 2009 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.66572d9fbaf1cd3dc567f5023cbf11e0@localhost> #2615: ghci doesn't play nice with linker scripts ---------------------------------+------------------------------------------ Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by hgolden): At least on Gentoo, I think this can be dealt with as follows: 1. In Linker.c if dlopen fails, search the file with a regular expression that would recognize "GROUP ( ... )" where ... is the important part. In Gentoo, when a .so file contains a linker script, the actual file is specified by the GROUP ( ... ). 1. If this is found, try the dlopen again using the filename. 1. If this fails, report an error. I'm not familiar with debian or debian-based distros. Do they use a similar approach? If so, a regular expression search for their filename in the script could be added as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 13:25:56 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 13:01:40 2009 Subject: [GHC] #3660: "Var.tcTyVarDetails" exception w/ Assoc. Datatypes and Monad Transformers Message-ID: <047.e6899d40ad37a1c55c469f50fa464e53@localhost> #3660: "Var.tcTyVarDetails" exception w/ Assoc. Datatypes and Monad Transformers -----------------------------------------------------+---------------------- Reporter: jfredett | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: minor Keywords: Monad Transformers, Associated Datatypes | Testcase: Os: Linux | Architecture: x86 -----------------------------------------------------+---------------------- Summary: When trying to build a monad stack which involves a state transformer with a constrained state, the newtype which constrains said state (below, it is the `Filter` newtype) cannot seem to derive something within the list of things it's intended to derive. After some testing I found that changing the `MonadState Bool` part of the `deriving` clause to `MonadState t` (in line with the actual state parameter) made everything work. The Type of `Email` doesn't matter, I've tested to this effect (replacing `Email` with `data Email = Email` and not importing the real version, it still compiles fine in the fixed case, and does not compile in the broken case). I have not tested on GHC 6.12 yet, I'm still trying to install it. All other system information at the bottom. By the looks of it, this is a case of GHC not noticing I'm doing something silly, and not reporting something along the lines of the "This isn't polymorphic enough" error. Broken Code: {{{ type Context = ReaderT Email type Match t = StateT t IO type ContextMatch t a = Context (Match t) a newtype FilterState t => Filter t a = Filter (ContextMatch t a) deriving (Functor, Monad, MonadReader Email, MonadState Bool, MonadIO) class FilterState t where data FState t deliver :: FState t -> IO () }}} Error: {{{ [1 of 3] Compiling Network.HackMail.Email.ParseEmail ( Network/HackMail/Email/ParseEmail.hs, interpreted ) [2 of 3] Compiling Network.HackMail.Email.Email ( Network/HackMail/Email/Email.hs, interpreted ) [3 of 3] Compiling Network.HackMail.Filter.Filter ( Network/HackMail/Filter/Filter.hs, interpreted ) *** Exception: No match in record selector Var.tcTyVarDetails }}} Fixed Code: {{{ type Context = ReaderT Email type Match t = StateT t IO type ContextMatch t a = Context (Match t) a -- changed `Bool` to `t`. newtype FilterState t => Filter t a = Filter (ContextMatch t a) deriving (Functor, Monad, MonadReader Email, MonadState t, MonadIO) class FilterState t where data FState t deliver :: FState t -> IO () }}} System Info: {{{ [jfredett@Erdos]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 [jfredett@Erdos]$ uname -a Linux Erdos 2.6.31-ARCH #1 SMP PREEMPT Fri Oct 23 11:12:58 CEST 2009 i686 Intel(R) Celeron(R) CPU 3.06GHz GenuineIntel GNU/Linux }}} (Possibly) Related Tickets include: 3621, 3422 and 2714 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 21:28:39 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 21:04:27 2009 Subject: [GHC] #3661: Profiling GHC HEAD broken under OSX. Message-ID: <043.560ca39f817b07eb47a88350bdc7c055@localhost> #3661: Profiling GHC HEAD broken under OSX. --------------------+------------------------------------------------------- Reporter: pejo | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.13 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- If I pull latest HEAD, with the following contents in build.mk: {{{ BuildFlavour = prof }}} and then build under OSX it errors out with: {{{ "inplace/bin/ghc-stage1" -prof -H32m -O -package-name ghc-6.13.20091112 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/../libffi/build/include -Icompiler/stage2 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.8.0 -package array-0.3.0.0 -package base-4.2.0.0 -package bin-package- db-0.0.0.0 -package bytestring-0.9.1.5 -package containers-0.3.0.0 -package directory-1.0.1.0 -package filepath-1.1.0.3 -package hpc-0.5.0.4 -package old-time-1.0.0.3 -package process-1.0.1.2 -package template- haskell-2.4.0.0 -package unix-2.4.0.0 -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -hisuf p_hi -osuf p_o -hcsuf p_hc -c compiler/main/Finder.lhs -o compiler/stage2/build/Finder.p_o Undefined symbols: "_CCCS", referenced from: _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[1]: *** [utils/runghc/dist/build/tmp/runghc] Error 1 make[1]: *** Waiting for unfinished jobs.... Undefined symbols: "_CCCS", referenced from: _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 Undefined symbols: "_CCCS", referenced from: _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[1]: *** [utils/hpc/dist/build/tmp/hpc] Error 1 Undefined symbols: "_CCCS", referenced from: _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word2Integerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_int64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_word64ToIntegerzh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) _integer_cmm_decodeDoublezh in libHSinteger-gmp-0.2.0.0.a(gmp- wrappers.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[1]: *** [utils/ghc-pkg/dist-install/build/tmp/ghc-pkg] Error 1 make: *** [all] Error 2 }}} This does not happen to me with the build.mk without profiling from the developers wiki. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 23:19:48 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 22:55:37 2009 Subject: [GHC] #3659: two-dimensional PArrays in data parallel code In-Reply-To: <042.8324de31085b57dee762ee81f38b0402@localhost> References: <042.8324de31085b57dee762ee81f38b0402@localhost> Message-ID: <051.9bede27b5c4ac8d16c785f15abbefef4@localhost> #3659: two-dimensional PArrays in data parallel code ------------------------------+--------------------------------------------- Reporter: ams | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by chak): * cc: rl@cse.unsw.edu.au (added) Comment: The function `fromList` doesn't currently work on lists of parallel arrays. It arguably should, though. From what you are writing, I am not sure whether you want to work explicitly with `PArray`s or whether you want to work with `[:t:]` types. In the former case, you can use `nestUSegdPA` to construct a nested array. In the latter case, you currently probably have to use a combination of `singletonP` and `(+:+)` to first create singleton nested arrays from all your subarrays and then concatenate them. I notice that you are calling the nested array a ''two-dimensional array''. If your aim is to have subarrays of the same size and to operate in a regular manner on the nested array (e.g., implementing ''dense'' matrix operations), you will probably find that the performance isn't great and the code is a bit awkward. The reason is that the current system is biased towards nested, irregular arrays. We are currently working on complementing the existing API with explicit support for regular, multi-dimensional arrays to address this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 23:25:08 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 23:01:05 2009 Subject: [GHC] #2813: Create a utf8 bytestring-a-like In-Reply-To: <044.ad636022be236bf694f594b538272960@localhost> References: <044.ad636022be236bf694f594b538272960@localhost> Message-ID: <053.ef22a5dd29fb3a0fd1607ef5412841c9@localhost> #2813: Create a utf8 bytestring-a-like ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by bos): * status: new => closed * resolution: => wontfix Comment: I think that it makes some sense to close this bug, since it's really not the job of GHC to be shipping a text library, I believe. I'll add I/O capabilities to the text library soonish. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 23:30:46 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 23:06:28 2009 Subject: [GHC] #3662: Don't know how to install documentation Message-ID: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> #3662: Don't know how to install documentation -----------------------------+---------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Severity: blocker Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Following the changes to the build system that got merged in earlier this year, it's no longer obvious (or documented, as far as I can tell) how to either build or install documentation. The procedure that used to work for 6.10 was {{{make install-docs}}}, but the {{{Makefile}}}s in the {{{docs}}} and {{{docs/man}}} directories have bit-rotted, and the {{{install-docs}}} target has vanished from the top- level {{{Makefile}}} too. If I knew how to build the documentation, I'd send in a patch, as I think it's important that this be fixed before 6.12.1 goes final, so that platform packagers like myself can figure out how to easily build and install the documentation. Unfortunately, I'm not even sure what needs fixing in the new build world. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 23:32:42 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 23:08:34 2009 Subject: [GHC] #3659: two-dimensional PArrays in data parallel code In-Reply-To: <042.8324de31085b57dee762ee81f38b0402@localhost> References: <042.8324de31085b57dee762ee81f38b0402@localhost> Message-ID: <051.f275b1aa56e59dfaedd6e6b366978d67@localhost> #3659: two-dimensional PArrays in data parallel code ------------------------------+--------------------------------------------- Reporter: ams | Owner: rl Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by rl): * owner: => rl -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 12 23:49:45 2009 From: trac at galois.com (GHC) Date: Thu Nov 12 23:25:34 2009 Subject: [GHC] #3659: two-dimensional PArrays in data parallel code In-Reply-To: <042.8324de31085b57dee762ee81f38b0402@localhost> References: <042.8324de31085b57dee762ee81f38b0402@localhost> Message-ID: <051.8a15ece166e791fdcb93f32b7f493693@localhost> #3659: two-dimensional PArrays in data parallel code ------------------------------+--------------------------------------------- Reporter: ams | Owner: rl Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: worksforme Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by rl): * status: new => closed * resolution: => worksforme Comment: In the HEAD, `fromList` hast this type: {{{ fromList :: PA a => [a] -> PArray a }}} That said, the type `PArray` is internal to DPH and in theory shouldn't be used outside of the library. You have to use it at the moment when interfacing non-vectorised with vectorised code but I'm in the process of fixing that. Once I'm done, you'll be able to use `[:a:]` everywhere and DPH won't expose module outside of the (temporary) `Data.Array.Parallel.Prelude` hierarchy. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 03:33:03 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 03:08:44 2009 Subject: [GHC] #3660: "Var.tcTyVarDetails" exception w/ Assoc. Datatypes and Monad Transformers In-Reply-To: <047.e6899d40ad37a1c55c469f50fa464e53@localhost> References: <047.e6899d40ad37a1c55c469f50fa464e53@localhost> Message-ID: <056.15722c43cd097bf763a151a672b4442f@localhost> #3660: "Var.tcTyVarDetails" exception w/ Assoc. Datatypes and Monad Transformers ---------------------------------------------------------+------------------ Reporter: jfredett | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: fixed Keywords: Monad Transformers, Associated Datatypes | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------+------------------ Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks. I had to add some imports thus: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-} module Foo where import Control.Monad.State import Control.Monad.Reader data Email = Email type Context = ReaderT Email type Match t = StateT t IO type ContextMatch t a = Context (Match t) a newtype FilterState t => Filter t a = Filter (ContextMatch t a) deriving (Functor, Monad, MonadReader Email, MonadState Bool, MonadIO) class FilterState t where data FState t deliver :: FState t -> IO () }}} Happily this works ok in 6.12, and HEAD, saying {{{ Foo.hs:12:51: Couldn't match expected type `Bool' against inferred type `t' `t' is a rigid type variable bound by the instance declaration at Foo.hs:11:32 When using functional dependencies to combine MonadState s (StateT s m), arising from the dependency `m -> s' in the instance declaration at MonadState Bool (StateT t IO), arising from the instance declaration at Foo.hs:12:51-65 When checking the super-classes of an instance declaration In the instance declaration for `MonadState Bool (Filter t)' }}} So I'll close the bug as fixed. Thank you for boiling it down. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 04:25:19 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 04:01:01 2009 Subject: [GHC] #3663: Unreg build fails when haddocking dph-seq Message-ID: <047.753dc5c1ddc55b022018cd683d7020f4@localhost> #3663: Unreg build fails when haddocking dph-seq -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The unregisterised HEAD build is failing thus: {{{ "inplace/bin/ghc-cabal" haddock dist-install libraries/dph/dph-seq --with- haddock=/64playpen/buildbot/x86_64-linux-head- unreg/build/inplace/bin/haddock --with-ghc=/64playpen/buildbot/x86_64 -linux-head-unreg/build/inplace/bin/ghc-stage2 --hyperlink-source Running Haddock for dph-seq-0.4.0... Preprocessing library dph-seq-0.4.0... Running hscolour for dph-seq-0.4.0... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: ffi-1.0, rts-1.0 haddock: panic! (the 'impossible' happened) (GHC version 6.13.20091112 for x86_64-unknown-linux): This compiler was built without a native code generator Use -fvia-C instead Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Presumably because dph-seq needs to do some dynamic compilation for its annotations, so Haddock tells it to use -fasm, but there's no native code generator. Not clear whether this is a Haddock problem or something we need to fix in the GHC API (probably both). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 04:45:54 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 04:21:38 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) Message-ID: <045.0f6b0943402daeb82291512e1fe74507@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) -----------------------+---------------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -----------------------+---------------------------------------------------- Tried to build '''highlighting-kate-0.2.5''' from hackage with ghc-6.12rc1 and could not wait build result. Ghc ate 2.5BG of ram in 6 minutes, then I stopped it as machine swapped horribly. {{{ $ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("Project version","6.12.0.20091010") ,("Booter version","6.10.4") ,("Stage","2") ,("Have interpreter","YES") ,("Object splitting","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("Win32 DLLs","") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib64/ghc-6.12.0.20091010") }}} {{{ * Using cabal-1.8.0. [1 of 1] Compiling Main ( /tmp/paludis/dev-haskell- highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.lhs, /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting- kate-0.2.5/Setup.o ) Linking setup ... Configuring highlighting-kate-0.2.5... Flags chosen: executable=True, splitbase=True Dependency base >=3 && <5: using base-4.2.0.0 Dependency containers -any: using containers-0.3.0.0 Dependency filepath -any: using filepath-1.1.0.3 Dependency parsec <3: using parsec-2.1.0.1 Dependency pcre-light -any: using pcre-light-0.3.1 Dependency xhtml -any: using xhtml-3000.2.0.1 Using Cabal-1.8.0 compiled by ghc-6.12 Using compiler: ghc-6.12.0.20091010 }}} ... {{{ /usr/bin/gcc /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064.c -o /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064 -D__GLASGOW_HASKELL__=612 -I. -O0 -O0 -I/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5/include -I/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0/include -I/usr/lib64/ghc-6.12.0.20091010/include -I/usr/lib64/ghc-6.12.0.20091010/include -L/usr/lib64/xhtml-3000.2.0.1/ghc-6.12.0.20091010 -L/usr/lib64/pcre- light-0.3.1/ghc-6.12.0.20091010 -L/usr/lib64/parsec-2.1.0.1/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010/filepath-1.1.0.3 -L/usr/lib64/ghc-6.12.0.20091010/containers-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5 -L/usr/lib64/ghc-6.12.0.20091010/array-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/integer-gmp-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/ghc-prim-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010 Preprocessing library highlighting-kate-0.2.5... Preprocessing executables for highlighting-kate-0.2.5... Building highlighting-kate-0.2.5... }}} ... {{{ [41 of 61] Compiling Text.Highlighting.Kate.Syntax.Php ( Text/Highlighting/Kate/Syntax/Php.hs, dist/build/Text/Highlighting/Kate/Syntax/Php.p_o ) Ctrl+C VIRT: 2.5G RAM, RSS 1.2G RAM, swap activity is large. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 05:00:15 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 04:35:56 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) In-Reply-To: <045.0f6b0943402daeb82291512e1fe74507@localhost> References: <045.0f6b0943402daeb82291512e1fe74507@localhost> Message-ID: <054.d5f0db438244db5f40ffd494696a4a43@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) ----------------------+----------------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------+----------------------------------------------------- Comment (by slyfox): Note: during nonprofiled build of this package memory consumtion holds at the level of 400 Megabytes -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 07:36:17 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 07:12:05 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.4b1ef77072696478489ee381c746b7d6@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): One more patch {{{ Fri Nov 13 02:45:18 PST 2009 Simon Marlow * The rest of the #1185 patch (forkProcess and -threaded) Ignore-this: fef0329743c91910dcd38734bb502649 Due to darcs confusion, I managed to leave out part of the patch for #1185. This should make 1185(threaded1) go through now. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 11:37:08 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 11:12:50 2009 Subject: [GHC] #3655: Performance regression relative to 6.10 In-Reply-To: <047.de41e91ed6bceb6d2068db2adb01f317@localhost> References: <047.de41e91ed6bceb6d2068db2adb01f317@localhost> Message-ID: <056.1585b48774c3460a8e1808d1fa69154d@localhost> #3655: Performance regression relative to 6.10 -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: run-time performance bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonmar): Strange things are afoot. With the STABLE buildbot build, this program only allocates 3.5GB and runs in 8.5s. Simon PJ's HEAD build has similar behaviour, but none of the other HEAD builds I have tried do - they all behave similarly to the 6.13 results above. We continue to investigate with `-ticky`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 12:56:06 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 12:31:47 2009 Subject: [GHC] #3458: Allocation where none should happen In-Reply-To: <044.0be4f1c62ed65da810608cbf23db2085@localhost> References: <044.0be4f1c62ed65da810608cbf23db2085@localhost> Message-ID: <053.141f23e9cbaa19175ea43b75202276ab@localhost> #3458: Allocation where none should happen -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonpj): I've had a look at this. I ran it with {{{ ./runST 100000 > /dev/null }}} Interesting. The allocation you are concerned about arises from the local 'loop' function in 'pick'. GHC allocates a function closure for it, once per call of 'pick', which isn't really necessary. There are two ways to stop this happening. One way is to make 'loop' a top level function like this {{{ pick (c,p) r = myloop c p r 0 myloop c p r i = if r < unsafeAt p i then fromIntegral $ unsafeAt c i :: Word8 else myloop c p r (i+1) }}} This reduces allocation from 35Mbytes to 3Mbytes, by getting rid of those loop closures. But this is not very cool. In fact 'loop' is totally tail-recursive, and should never be heap allocated. It's very nearly a let-no-escape thing but not quite. Here is a smaller example: {{{ f x = let g y = if y then x else g y in g x }}} If you compile with -ddump-stg you'll see that `g` gets the "let-no- escape" property, which means that it doesn't get a heap closure allocated for it. But if you make this little change: {{{ f x = let g y = if y then x else g y in case g x of True -> False False -> True }}} then `g` doesn't get the let-no-escape property. And for good reason: you can't just adjust the stack pointer and jump to g. But you ''could'' do so if the 'let' was floated inwards, just before core-to-stg, thus: {{{ f x = case let g y = if y then x else g y in g x of True -> False False -> True }}} Now it has the let-no-escape property again. I'd never really thought of that. Food for thought here. (These remarks are intended mainly for me and other over-interested parties. As a workaround to get your performance up, try the lambda- lifting thing I show first.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 13:00:36 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 12:36:15 2009 Subject: [GHC] #3526: Inliner behaviour with instances is confusing In-Reply-To: <042.8258495ea2dc159620716346effd3b92@localhost> References: <042.8258495ea2dc159620716346effd3b92@localhost> Message-ID: <051.a1705a52e31d1e64d3b5e5d8b11c5d88@localhost> #3526: Inliner behaviour with instances is confusing ---------------------------------+------------------------------------------ Reporter: bos | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Bryan You don't actually give a reproducible test case, so I can't test this. Nevertheless I believe I have fixed the problem. You should be able to write the straightforward instance, and it should work. Can you try, and let me know? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 13:24:33 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 13:00:13 2009 Subject: [GHC] #3303: Allow multi-line deprecation messages. In-Reply-To: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> References: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> Message-ID: <054.daea327603a886eb2e8d3c027e1e320f@localhost> #3303: Allow multi-line deprecation messages. ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by duncan): * status: closed => reopened * resolution: fixed => Comment: The formatting of deprecation pragmas now accidentally includes Haskell list syntax. This pragma {{{ module Foo {-# DEPRECATED ["You are using the old package `base' version 3.x." ,"Future GHC versions will not support base version 3.x. You" ,"should update your code to use the new base version 4.x."] #-} where }}} gives this warning message: {{{ Bar.hs:1:0: Warning: Module `Foo' is deprecated: [You are using the old package `base' version 3.x., Future GHC versions will not support base version 3.x. You, should update your code to use the new base version 4.x.] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 13:49:35 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 13:25:15 2009 Subject: [GHC] #3665: Add whole-package deprecation warnings Message-ID: <045.b5f8edc411a6fdd1d799c2489f96cbc0@localhost> #3665: Add whole-package deprecation warnings -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- With GHC-6.12 if you use base 3 you get: {{{ Warning: Module `Prelude' is deprecated: [You are using an old version of base. Future GHC versions will not support this version, so you need to update your code to use the new base version.] }}} This is initially a somewhat confusing warning. We're not really deprecating the Prelude! It would be much nicer if it told us: {{{ Warning: Package `base-3.0.3.2' is deprecated: [You are using an old version of base. Future GHC versions will not support this version, so you need to update your code to use the new base version.] }}} The message itself could be formatted more nicely too. Patch attached for that. Note the current spurious list syntax in the deprecation message. I've re- opened #3303 about that. As for the syntax for package deprecations, how about just {{{ module Foo {-# DEPRECATED package "the message" #-} (..) where }}} For the behaviour, how about making them behave just like module- deprecation messages in that one attaches them to a module header and they are only triggered if you import that module. The only change would be in how the message is reported; instead of saying the module is deprecated it'd give the package (including the full version). I know this is a feature request, which usually we'd want to put off for the next major version, but since this one is all about helping maintainers and users of 6.12.1 and .2, I hope that we consider looking at it for an early 6.12 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 14:31:52 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 14:07:32 2009 Subject: [GHC] #3526: Inliner behaviour with instances is confusing In-Reply-To: <042.8258495ea2dc159620716346effd3b92@localhost> References: <042.8258495ea2dc159620716346effd3b92@localhost> Message-ID: <051.6247b3a26bbab722b7784d886d4e275d@localhost> #3526: Inliner behaviour with instances is confusing ---------------------------------+------------------------------------------ Reporter: bos | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by bos): Thanks, Simon; I'll take a look this weekend and close this bug out if all is now well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 15:00:57 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 14:36:36 2009 Subject: [GHC] #3666: Binary: Int64 truncated to fit in 32 bit Int Message-ID: <044.25821ed0d94577e2ff2415f756eb327b@localhost> #3666: Binary: Int64 truncated to fit in 32 bit Int -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- I'm a complete Haskell noob, but code that I wrote and loaded and ran in GHCI fine didn't compile with ghc --make: {{{ $ ghc --make test.hs Binary: Int64 truncated to fit in 32 bit Int ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): Prelude.chr: bad argument Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 13 17:05:36 2009 From: trac at galois.com (GHC) Date: Fri Nov 13 16:41:16 2009 Subject: [GHC] #3662: Don't know how to install documentation In-Reply-To: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> References: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> Message-ID: <051.3551989c3ecb15743915da0b82496e56@localhost> #3662: Don't know how to install documentation ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by bos): Thanks, Simon! It's actually just fine that docs get built and installed by default, so no worries there. The last remaining piece of the puzzle is that the man page doesn't seem to get built any more either, at least not as of the current HEAD that I have locally (which I just pulled). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 14 19:29:02 2009 From: trac at galois.com (GHC) Date: Sat Nov 14 19:04:39 2009 Subject: [GHC] #3667: Overly specific type inference. Message-ID: <056.46fe4a7ed0d04333f3b907915c2b4a02@localhost> #3667: Overly specific type inference. ------------------------------+--------------------------------------------- Reporter: Sean Erle Johnson | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- The inferred type for perms in the following code is too specific: {{{ import Data.List main = print $ perms 4 [1..4] test = perms 4 ['1'..'4'] perms = combBase delete combBase :: (a -> [a] -> [a]) -> Int -> [a] -> [[a]] combBase next = worker where worker 0 _ = [[]] worker _ [] = [[]] worker l xs = concatMap (\x -> map (x:) (worker (l-1) (next x xs))) xs }}} Compiling with ghc (with the --make switch) yields: {{{ TypeInferenceBug.hs:3:24: No instance for (Num Char) arising from the literal `1' at TypeInferenceBug.hs:3:24 Possible fix: add an instance declaration for (Num Char) In the expression: 1 In the second argument of `perms', namely `[1 .. 4]' In the second argument of `($)', namely `perms 4 ([1 .. 4])' }}} Typing ":t perms" into ghci gives the following signature (after the main function is commented out): {{{ perms :: Int -> [Char] -> [[Char]] }}} Compiling occurs without complaint when perms is given the explicit (and more general) type signature and ghci reports the correct type signature: {{{ perms :: Eq a => Int -> [a] -> [[a]] perms = combBase delete }}} The type is correctly inferred for combBase regardless of if it has an explicit type signature or not. I tested this on Windows but not on Linux yet, though I suspect that this problem is architecture-independent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 14 19:29:02 2009 From: trac at galois.com (GHC) Date: Sat Nov 14 19:06:04 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.41bf6c85f8adc7a9132df77e1f5cf89a@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by korpios): * cc: korpios@korpios.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 15 09:40:48 2009 From: trac at galois.com (GHC) Date: Sun Nov 15 09:16:25 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. Message-ID: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> #3668: PIE-enabled hardened gcc might broke GHC. -------------------------+-------------------------------------------------- Reporter: secludedsage | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------------+-------------------------------------------------- emerge --info: Portage 2.1.7.4 (hardened/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r0, 2.6.31-11-generic i686) ================================================================= System uname: Linux-2.6.31-11-generic-i686-Genuine_Intel-R-_CPU_T2050_@_1 .60GHz-with-gentoo-2.0.1 Timestamp of tree: Sat, 14 Nov 2009 05:45:01 +0000 app-shells/bash: 4.0_p35 dev-lang/python: 2.6.4, 3.1.1-r1 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.5.2-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.30-r1 CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="*" MAKEOPTS="-j3" While I am building yi-editor, I get: Building yi-0.6.1... [ 1 of 119] Compiling System.FriendlyPath ( System/FriendlyPath.hs, dist/build/System/FriendlyPath.o ) [ 2 of 119] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs, dist/build/Shim/ProjectContent.o ) [ 3 of 119] Compiling Parser.Incremental ( Parser/Incremental.hs, dist/build/Parser/Incremental.o ) [ 4 of 119] Compiling Data.Trie ( Data/Trie.hs, dist/build/Data/Trie.o ) [ 5 of 119] Compiling Data.DelayList ( Data/DelayList.hs, dist/build/Data/DelayList.o ) [ 6 of 119] Compiling Data.Rope ( Data/Rope.hs, dist/build/Data/Rope.o ) [ 7 of 119] Compiling Data.Prototype ( Data/Prototype.hs, dist/build/Data/Prototype.o ) [ 8 of 119] Compiling HConf.Utils ( HConf/Utils.hs, dist/build/HConf/Utils.o ) [ 9 of 119] Compiling HConf.Paths ( HConf/Paths.hs, dist/build/HConf/Paths.o ) [ 10 of 119] Compiling Paths_yi ( dist/build/autogen/Paths_yi.hs, dist/build/Paths_yi.o ) [ 11 of 119] Compiling HConf ( HConf.hs, dist/build/HConf.o ) [ 12 of 119] Compiling Yi.Char.Unicode ( Yi/Char/Unicode.hs, dist/build/Yi/Char/Unicode.o ) [ 13 of 119] Compiling Yi.UI.Common[boot] ( Yi/UI/Common.hs-boot, dist/build/Yi/UI/Common.o-boot ) [ 14 of 119] Compiling Yi.String ( Yi/String.hs, dist/build/Yi/String.o ) [ 15 of 119] Compiling Yi.Monad ( Yi/Monad.hs, dist/build/Yi/Monad.o ) [ 16 of 119] Compiling Yi.Keymap.Completion ( Yi/Keymap/Completion.hs, dist/build/Yi/Keymap/Completion.o ) [ 17 of 119] Compiling Yi.Editor[boot] ( Yi/Editor.hs-boot, dist/build/Yi/Editor.o-boot ) [ 18 of 119] Compiling Yi.Debug ( Yi/Debug.hs, dist/build/Yi/Debug.o ) [ 19 of 119] Compiling Yi.Prelude ( Yi/Prelude.hs, dist/build/Yi/Prelude.o ) [ 20 of 119] Compiling Yi.Dynamic ( Yi/Dynamic.hs, dist/build/Yi/Dynamic.o ) [ 21 of 119] Compiling Yi.Event ( Yi/Event.hs, dist/build/Yi/Event.o ) [ 22 of 119] Compiling Yi.Interact ( Yi/Interact.hs, dist/build/Yi/Interact.o ) [ 23 of 119] Compiling Yi.Keymap[boot] ( Yi/Keymap.hs-boot, dist/build/Yi/Keymap.o-boot ) [ 24 of 119] Compiling Yi.Style ( Yi/Style.hs, dist/build/Yi/Style.o ) [ 25 of 119] Compiling Yi.Style.Library ( Yi/Style/Library.hs, dist/build/Yi/Style/Library.o ) [ 26 of 119] Compiling Yi.Interpreter ( Yi/Interpreter.hs, dist/build/Yi/Interpreter.o ) [ 27 of 119] Compiling Shim.Utils ( Shim/Utils.hs, dist/build/Shim/Utils.o ) [ 28 of 119] Compiling Shim.CabalInfo ( Shim/CabalInfo.hs, dist/build/Shim/CabalInfo.o ) [ 29 of 119] Compiling Yi.Buffer.Misc[boot] ( Yi/Buffer/Misc.hs-boot, dist/build/Yi/Buffer/Misc.o-boot ) [ 30 of 119] Compiling Yi.Buffer.Basic ( Yi/Buffer/Basic.hs, dist/build/Yi/Buffer/Basic.o ) ghc: /usr/lib/ghc-6.10.4/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o: unknown symbol `_GLOBAL_OFFSET_TABLE_' Loading package ghc-prim ... linking ... ghc: unable to load package `ghc- prim' mk/build.mk: # Gentoo changes docdir = /usr/share/doc/ghc-6.10.4 htmldir = /usr/share/doc/ghc-6.10.4 SRC_HC_OPTS+= -optc-march=native -opta-march=native -optc-nopie -optl- nopie -optc-fno-PIE -opta-Wa,--noexecstack SRC_CC_OPTS+=-O2 -march=native -pipe -nopie -Wa,--noexecstack XMLDocWays= HADDOCK_DOCS=NO SRC_HC_OPTS+=-w -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 15 09:42:38 2009 From: trac at galois.com (GHC) Date: Sun Nov 15 09:18:13 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.d38f9a7a60cc9b76810ec2e0f7f124ea@localhost> #3668: PIE-enabled hardened gcc might broke GHC. --------------------------+------------------------------------------------- Reporter: secludedsage | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------------+------------------------------------------------- Comment (by secludedsage): gcc -dumpspecs: *asm: %{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*} *asm_debug: %{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}} %{fdebug-prefix-map =*:--debug-prefix-map %*} *asm_final: *asm_options: %{--target-help:%:print-asm-header()} %a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O} *invoke_as: %{!S:-o %|.s | as %(asm_options) %|.s %A } *cpp: %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} *cpp_options: %(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*} %{w} %{f*} %{g*:%{!g0:%{!fno-working-directory:-fworking-directory}}} %{O*} %{undef} %{save-temps:-fpch-preprocess} *cpp_debug_options: %{d*} *cpp_unique_options: %{C|CC:%{!E:%eGCC does not support -C or -CC without -E}} %{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ %*}}}}}}} %{remap} %{g3|ggdb3|gstabs3|gcoff3|gxcoff3|gvms3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP -D_MUDFLAPTH -include mf-runtime.h} %{!D_FORTIFY_SOURCE:%{!D_FORTIFY_SOURCE=*:%{!U_FORTIFY_SOURCE:-D_FORTIFY_SOURCE=2}}} %{E|M|MM:%W{o*}} *trad_capable_cpp: cc1 -E %{traditional|ftraditional|traditional-cpp:-traditional-cpp} *cc1: %(cc1_cpu) %{profile:-p}%{!D__KERNEL__: %(cc1_pie) %(cc1_ssp) } %(cc1_strict) *cc1_options: %{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %{shared:%{static|pie|fPIE|fpie|fno-PIC|fno-pic:%e-shared and -static|pie|fPIE|fpie|fno-PIC|fno-pic are incompatible}} %{pie:%{static|pg|p|profile:%e-pie and -static|pg|p|profile are incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*} %{c|S:%{o *:-auxbase-strip %*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase %b}} %{g*} %{O*} %{W*&pedantic*} %{w} %{std*&ansi&trigraphs} %{v:-version} %{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{--help:--help} %{--target-help:--target- help} %{--help=*:--help=%(VALUE)} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*} %{fmudflap|fmudflapth:-fno- builtin -fno-merge-constants} %{coverage:-fprofile-arcs -ftest-coverage} *cc1plus: *link_gcc_c_sequence: %{static:--start-group} %G %L %{static:--end-group}%{!static:%G} *link_ssp: %{fstack-protector:} *endfile: %{ffast-math|funsafe-math-optimizations:crtfastmath.o%s} %{mpc32:crtprec32.o%s} %{mpc64:crtprec64.o%s} %{mpc80:crtprec80.o%s} %(endfile_pie_gen) crtn.o%s *link: %{!static:--eh-frame-hdr} -m %(link_emulation) %{shared:-shared} %{!shared: %{!ibcs: %{!static: %{rdynamic:-export-dynamic} %{!dynamic-linker:-dynamic-linker %(dynamic_linker)}} %{static:-static}}} *lib: %{pthread:-lpthread} %{shared:-lc} %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}} *mfwrap: %{static: %{fmudflap|fmudflapth: --wrap=malloc --wrap=free --wrap=calloc --wrap=realloc --wrap=mmap --wrap=munmap --wrap=alloca} %{fmudflapth: --wrap=pthread_create}} %{fmudflap|fmudflapth: --wrap=main} *mflib: %{fmudflap|fmudflapth: -export-dynamic} *link_gomp: *libgcc: %{static|static-libgcc:-lgcc -lgcc_eh}%{!static:%{!static-libgcc :%{!shared-libgcc:-lgcc --as-needed -lgcc_s --no-as-needed}%{shared- libgcc:-lgcc_s%{!shared: -lgcc}}}} *startfile: %(ld_pie_crtfile_gen) crti.o%s %(startfile_pie_t_gen) *switches_need_spaces: *cross_compile: 0 *version: 4.3.4 *multilib: . ; *multilib_defaults: *multilib_extra: *multilib_matches: *multilib_exclusions: *multilib_options: *linker: collect2 *link_libgcc: %D *md_exec_prefix: *md_startfile_prefix: *md_startfile_prefix_1: *startfile_prefix_spec: *sysroot_spec: --sysroot=%R *sysroot_suffix_spec: *sysroot_hdrs_suffix_spec: *asm_pie: %{pie:-K PIC} *ld_pie_crtfile_gen: %(crtfile_pie_gen) *crtfile_gen: %{!shared: %{pg|p|profile:gcrt1.o%s;:crt1.o%s}} *crtfile_pie_gen: %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s} } *startfile_pie_t_gen: %{shared|pie:crtbeginS.o%s;static:crtbeginT.o%s;:crtbegin.o%s} *startfile_pie_gen: %{shared|pie:crtbeginS.o%s;:crtbegin.o%s} *endfile_pie_gen: %{shared|pie:crtendS.o%s;:crtend.o%s} *cc1_ssp: *cc1_ssp_all: *cc1_pie: %{pie:-fPIE} *cc1_strict: *link_now: *link_pie: %{pie:-pie} *cc1_cpu: %{mcpu=*:-mtune=%* %n`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead. } % GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 15 09:45:26 2009 From: trac at galois.com (GHC) Date: Sun Nov 15 09:21:01 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.b3df7db2f461734978bc942e3f909ae6@localhost> #3668: PIE-enabled hardened gcc might broke GHC. --------------------------+------------------------------------------------- Reporter: secludedsage | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------------+------------------------------------------------- Comment (by secludedsage): I am sorry that I pasted so much since I do not know how to organise these information. I am using Hardened Gentoo and going to try yi-editor. However, I got the error pasted above while compiling yi-editor. While talking on IRC (#gentoo-haskell and #haskell) I was told that this might be caused by a broken toolchain. Since ebuild write -nopie to mk/build.mk, personally I think PIE things should be avoided. But the result is at least ghc-prim is still built with PIE enabled. Thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 15 14:07:59 2009 From: trac at galois.com (GHC) Date: Sun Nov 15 13:43:44 2009 Subject: [GHC] #3667: Overly specific type inference. In-Reply-To: <056.46fe4a7ed0d04333f3b907915c2b4a02@localhost> References: <056.46fe4a7ed0d04333f3b907915c2b4a02@localhost> Message-ID: <065.34499e91eee75d2404747a0ae56682b3@localhost> #3667: Overly specific type inference. -------------------------------+-------------------------------------------- Reporter: Sean Erle Johnson | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by augustss): * status: new => closed * resolution: => invalid Comment: It's not a bug, it's a feature. It's the monomorphism restriction and it is well documented. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 15 15:40:55 2009 From: trac at galois.com (GHC) Date: Sun Nov 15 15:16:30 2009 Subject: [GHC] #3661: Profiling GHC HEAD broken under OSX. In-Reply-To: <043.560ca39f817b07eb47a88350bdc7c055@localhost> References: <043.560ca39f817b07eb47a88350bdc7c055@localhost> Message-ID: <052.dfa66247e13761131909764b04e96455@localhost> #3661: Profiling GHC HEAD broken under OSX. ---------------------------------+------------------------------------------ Reporter: pejo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Comment: Thanks for the report; can you please paste the entire `mk/build.mk` contents for the build that doesn't work? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 15 15:52:04 2009 From: trac at galois.com (GHC) Date: Sun Nov 15 15:27:38 2009 Subject: [GHC] #3662: Don't know how to install documentation In-Reply-To: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> References: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> Message-ID: <051.4275911cd4696b9c0413374be9c720ea@localhost> #3662: Don't know how to install documentation ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): I'd have thought an `install-docs` target (which actually installs the docs) would cause more problems than it solves. I think everyone who's asked about it is a packager, because they have build scripts that expect `install` to install one set of things, and `install-docs` to install another set. Wouldn't we be better off with an `install-docs` target that just prints a message explaining the change in behaviour and then fails? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 15 20:02:17 2009 From: trac at galois.com (GHC) Date: Sun Nov 15 19:37:51 2009 Subject: [GHC] #3303: Allow multi-line deprecation messages. In-Reply-To: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> References: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> Message-ID: <054.c38ed15446f4c0bfac13e6a0ad318ff0@localhost> #3303: Allow multi-line deprecation messages. ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): With the attached patch it looks like: {{{ Foo.hs:1:0: Warning: Module `Prelude' is deprecated: You are using the old package `base' version 3.x. Future GHC versions will not support base version 3.x. You should update your code to use the new base version 4.x. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 00:40:16 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 00:15:49 2009 Subject: [GHC] #3661: Profiling GHC HEAD broken under OSX. In-Reply-To: <043.560ca39f817b07eb47a88350bdc7c055@localhost> References: <043.560ca39f817b07eb47a88350bdc7c055@localhost> Message-ID: <052.d2dc7bffa1120dbbdc20ffd03c1087bb@localhost> #3661: Profiling GHC HEAD broken under OSX. ---------------------------------+------------------------------------------ Reporter: pejo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.13 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by pejo): Replying to [comment:1 igloo]: Here's the complete non-working build.mk: {{{ BuildFlavour = prof }}} I initially tried the following diff to my working build.mk, but that gave the same error: {{{ -GhcLibWays = v +GhcLibWays = v p GhcProfiled = YES }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 03:36:23 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 03:11:56 2009 Subject: [GHC] #3665: Add whole-package deprecation warnings In-Reply-To: <045.b5f8edc411a6fdd1d799c2489f96cbc0@localhost> References: <045.b5f8edc411a6fdd1d799c2489f96cbc0@localhost> Message-ID: <054.06742a2f5e0a104e3f236fa68a8230f5@localhost> #3665: Add whole-package deprecation warnings ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Is the module itself the right place for such a message? After all, if you deprecate a package you probably deprecate all the exposed modules in the package, so it's a bit tedious to have to do that module by module. Moreover, the identical code might appear in an updated version of the package, so it's not really that ''code'' that's deprecated; it's the context in which it appears. Isn't the `.cabal` file the right place to deprecate a package? After all, that's where all its metadata is given. And Cabal itself might like to know about deprecations during its ruminations, not just GHC. So I'm unconvinced. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 03:40:47 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 03:16:19 2009 Subject: [GHC] #3666: Binary: Int64 truncated to fit in 32 bit Int In-Reply-To: <044.25821ed0d94577e2ff2415f756eb327b@localhost> References: <044.25821ed0d94577e2ff2415f756eb327b@localhost> Message-ID: <053.6aa59f0bb1d9757b9754ab99938fcf7e@localhost> #3666: Binary: Int64 truncated to fit in 32 bit Int -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for reporting this, but it saves work for you (uploading a test case) if you search Trac first for dups: in this case #3643, #3635, #3611, #3477 etc. It's certainly a bug (GHC should never crash), but fixed in 6.12. Meanwhile rm *.hi Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 03:42:32 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 03:18:04 2009 Subject: [GHC] #3303: Allow multi-line deprecation messages. In-Reply-To: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> References: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> Message-ID: <054.f12c48f409f3e0979f14347c92d24b4c@localhost> #3303: Allow multi-line deprecation messages. ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Thanks! I'm validating now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 04:59:17 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 04:34:54 2009 Subject: [GHC] #2978: Add support for more characters to UnicodeSyntax In-Reply-To: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> References: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> Message-ID: <054.1e07ae1d52f82553ca32147396a210c2@localhost> #2978: Add support for more characters to UnicodeSyntax ---------------------------------+------------------------------------------ Reporter: porges | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:00:19 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 04:35:53 2009 Subject: [GHC] #2442: Heuristics to improve error messages for badly referenced things In-Reply-To: <053.d96b74737451be892238b37815ca44b6@localhost> References: <053.d96b74737451be892238b37815ca44b6@localhost> Message-ID: <062.7284bcb6a5d3902a6e2282c16bbb12d1@localhost> #2442: Heuristics to improve error messages for badly referenced things ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: high | Milestone: 6.14 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:02:00 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 04:37:33 2009 Subject: [GHC] #2451: New signal-handling API In-Reply-To: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> References: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> Message-ID: <056.ebaf8b2785af7a0900c40a7f2b2d4d7b@localhost> #2451: New signal-handling API ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: proposal | Status: new Priority: high | Milestone: 6.14 branch Component: libraries/unix | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:06:47 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 04:42:21 2009 Subject: [GHC] #666: Collection hierarchy proposal In-Reply-To: <049.738afcfb1e1f2b92048ebcd3e6bd99db@localhost> References: <049.738afcfb1e1f2b92048ebcd3e6bd99db@localhost> Message-ID: <058.c52d9a6edb3cb8d87f3dc99159e6f694@localhost> #666: Collection hierarchy proposal ---------------------------------+------------------------------------------ Reporter: jpbernardy | Owner: jpbernardy Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: Data collections | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:07:53 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 04:43:28 2009 Subject: [GHC] #728: switch to compacting collection when swapping occurs In-Reply-To: <047.d71284f919c6246c824e6f6eb3e3cecf@localhost> References: <047.d71284f919c6246c824e6f6eb3e3cecf@localhost> Message-ID: <056.1d534c46cc4dafc8ffbc1c4d7e53b302@localhost> #728: switch to compacting collection when swapping occurs ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Severity: major | Resolution: Keywords: compacting | Difficulty: Moderate (1 day) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:09:45 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 04:45:18 2009 Subject: [GHC] #881: Improve space profiling for references In-Reply-To: <046.89fda28d10e4c9bf9885adf9e31162cb@localhost> References: <046.89fda28d10e4c9bf9885adf9e31162cb@localhost> Message-ID: <055.97419a68e724f06b84ec49190d778488@localhost> #881: Improve space profiling for references ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Profiling | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:11:06 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 04:47:00 2009 Subject: [GHC] #960: Lexical call site string In-Reply-To: <057.da5a7918d3a237f53bbf07bfe2771af6@localhost> References: <057.da5a7918d3a237f53bbf07bfe2771af6@localhost> Message-ID: <066.7b030ef40c3396861b0fec3ef800a647@localhost> #960: Lexical call site string -----------------------------------+---------------------------------------- Reporter: paul@cogito.org.uk | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:12:48 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 04:48:22 2009 Subject: [GHC] #1380: Safe Haskell In-Reply-To: <044.3b0885c88c35a1aacdb90750c7783a3a@localhost> References: <044.3b0885c88c35a1aacdb90750c7783a3a@localhost> Message-ID: <053.da262cde4cadb4aa08321e03af58f765@localhost> #1380: Safe Haskell ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:24:29 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 05:00:02 2009 Subject: [GHC] #605: Optimisation: strict enumerations In-Reply-To: <047.930f12dd9816334e7bac59b319734f38@localhost> References: <047.930f12dd9816334e7bac59b319734f38@localhost> Message-ID: <056.199da5ccb6e22a0aecd9c0cc12c54c11@localhost> #605: Optimisation: strict enumerations ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: normal | Resolution: None Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:25:52 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 05:01:27 2009 Subject: [GHC] #701: Better CSE optimisation In-Reply-To: <047.e2c9c1769e87443e2852b517c052804c@localhost> References: <047.e2c9c1769e87443e2852b517c052804c@localhost> Message-ID: <056.febae0d361308c6bcbf01405e714f829@localhost> #701: Better CSE optimisation ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:27:29 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 05:03:02 2009 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@localhost> References: <047.6bf35585590f6b4632c8ba79805f0623@localhost> Message-ID: <056.149fd776ccf65e7f39d95b4d0d9af85e@localhost> #1600: Optimisation: CPR the results of IO ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:30:00 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 05:05:39 2009 Subject: [GHC] #1405: Make ghc (stage1) be compilable by non-GHC In-Reply-To: <051.fdfe73ce3bd8dfdeb8a04e3a7bade7ab@localhost> References: <051.fdfe73ce3bd8dfdeb8a04e3a7bade7ab@localhost> Message-ID: <060.d94332698998eb4f10e8facbf585eae4@localhost> #1405: Make ghc (stage1) be compilable by non-GHC ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:31:15 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 05:06:46 2009 Subject: [GHC] #3303: Allow multi-line deprecation messages. In-Reply-To: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> References: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> Message-ID: <054.1d7749f377dc3e1bd11edf5fdaf4f4a5@localhost> #3303: Allow multi-line deprecation messages. ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * priority: normal => high * status: reopened => new * type: bug => merge Comment: I've pushed the patch. Ian pls merge Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 05:35:49 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 05:11:21 2009 Subject: [GHC] #3669: haddock: internal Haddock or GHC error: Win32-version:: openBinaryFile: invalid argument (Invalid argument) Message-ID: <044.70edc156bbd5a808fbee0fac2c67b568@localhost> #3669: haddock: internal Haddock or GHC error: Win32-version:: openBinaryFile: invalid argument (Invalid argument) -------------------------------+-------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- This change to `gen_contents_index`: {{{ VERSION=`grep -i '^version:' $LIBPATH/$NAME.cabal | sed 's/.*[ \t]//'` }}} looks like it has caused this problem for SPJ on MSYS: {{{ cd libraries && sh gen_contents_index --inplace haddock: internal Haddock or GHC error: Win32-version:: openBinaryFile: invalid argument (Invalid argument) make[1]: *** [libraries/index.html] Error 1 make: *** [all] Error 2 sh-3.1$ }}} Presumably the problem is that the sed didn't remove what it was meant to, presumably because the '\t' didn't end up matching the tab character in the file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 07:02:04 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 06:37:40 2009 Subject: [GHC] #3662: Don't know how to install documentation In-Reply-To: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> References: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> Message-ID: <051.7ea2f4ac39ee9ce42e6937e7cacea235@localhost> #3662: Don't know how to install documentation ---------------------------------+------------------------------------------ Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar Comment: Replying to [comment:3 igloo]: > Wouldn't we be better off with an `install-docs` target that just prints a message explaining the change in behaviour and then fails? Good point - I'll do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 07:03:16 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 06:38:47 2009 Subject: [GHC] #3670: Allow RULES for higher-ranked terms Message-ID: <041.aeabb46c1a24d91fe9a4aa4c22f11019@localhost> #3670: Allow RULES for higher-ranked terms -----------------------------+---------------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.13 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Here is a small code sample: {{{ foo :: (forall m. m a -> m b) -> m a -> m b foo f = f bar :: (forall m. m a -> m a) -> m a -> m a bar f = f }}} I'd like to specialise `foo` to `bar` whenever possible but there seems to be no way of doing so. This doesn't work: {{{ {-# RULES "foo/bar" foo = bar #-} }}} GHC complains: {{{ Cannot match a monotype with `(forall (m1 :: * -> *). m1 a -> m1 b) -> m a -> m b' }}} Adding a signature to the rhs of the rule doesn't help. GHC doesn't accept signatures in the lhs. The following works, of course, but it's not as general: {{{ {-# RULES "foo/bar" forall (f :: (forall m. m a -> m a)). foo f = bar f #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 07:06:53 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 06:42:29 2009 Subject: [GHC] #2600: Bind type variables in RULES In-Reply-To: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> References: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> Message-ID: <055.892f920ae4c59420131c8709c203b66c@localhost> #2600: Bind type variables in RULES ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by rl): I'd like to resurrect this ticket. I think prefixing every type binder with `type` is ok, i.e., let's go with {{{ forall (type a :: *) (type b :: *) (f :: a->b). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 13:04:06 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 12:39:40 2009 Subject: [GHC] #3662: Don't know how to install documentation In-Reply-To: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> References: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> Message-ID: <051.ea59548ea26427e18b3eff184fd83f63@localhost> #3662: Don't know how to install documentation ---------------------------+------------------------------------------------ Reporter: bos | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by bos): * failure: => None/Unknown Comment: That would certainly be fine. My real problem wasn't that there was no way to install docs (apart from the man page, which is still a mystery), but that there wasn't a documented way to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 14:35:58 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 14:11:38 2009 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> References: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> Message-ID: <051.c536738d1e1c1b936a72035ef465622d@localhost> #2530: deriving Show adds extra parens for constructor with record syntax ---------------------------+------------------------------------------------ Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by spl): * failure: => None/Unknown * os: MacOS X => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: In the spirit of BugSweep, this bug should probably be closed easily. The two options proposed are: 1. Do nothing. This suits SPJ's style. 1. Change by removing parentheses. This agrees with Hugs and NM. I think it would be nice to do 2, but I don't feel that strongly about it. There do not seem to be many interested parties in this issue, and it is quite minor. Perhaps the default action should be to do nothing -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 15:22:46 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 14:58:22 2009 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> References: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> Message-ID: <051.05ab2ca00527f08ffb4c4732feecfacc@localhost> #2530: deriving Show adds extra parens for constructor with record syntax ---------------------------+------------------------------------------------ Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by igloo): I'm interested in the report and all the implementations agreeing on what the answer is. I think that the discussion to determine what that answer should be would be better held on a mailing list, and we can resolve this ticket once that is done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 16:15:23 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 15:50:56 2009 Subject: [GHC] #3583: Default view patterns In-Reply-To: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> References: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> Message-ID: <051.db68f8e36981e03c0eef5060fc2195a0@localhost> #3583: Default view patterns -----------------------------------------+---------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by NeilMitchell): * failure: => None/Unknown Comment: I think that totally implicit view patterns, as suggested by the original poster, is probably a bad idea. Are tickets left open for feature suggestions that the GHC developers don't consider to be a good idea? It gives the impression that the GHC team supports the feature, and if the idea really is a bad one, then the bug will be open forever. I do think the signalled view patterns would be quite nice - I've written up my thoughts on view patterns here: http://neilmitchell.blogspot.com/2009/11/reviewing-view-patterns.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 17:54:49 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 17:30:20 2009 Subject: [GHC] #1811: liberate case needs an independent threshold In-Reply-To: <047.1be3df80e1950b8bf84aedd7dcf27549@localhost> References: <047.1be3df80e1950b8bf84aedd7dcf27549@localhost> Message-ID: <056.8f06fa7bcb43985f473de30720792090@localhost> #1811: liberate case needs an independent threshold --------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8 Resolution: fixed | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by rl): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: I just noticed this ticket. As a matter of fact, liberate case has had an independent threshold for 2 years now: {{{ Fri Dec 14 11:27:19 EST 2007 Roman Leshchinskiy * Separate and optional size thresholds for SpecConstr and LiberateCase }}} The default is still 200, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 20:03:52 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 19:39:26 2009 Subject: [GHC] #1102: Lambda unicode character lex In-Reply-To: <047.3274cd2b53d69d61deb3dee313b1b3f5@localhost> References: <047.3274cd2b53d69d61deb3dee313b1b3f5@localhost> Message-ID: <056.c5d5d8880d2257e14b8a94ce4584de51@localhost> #1102: Lambda unicode character lex --------------------------------------+------------------------------------- Reporter: humasect | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.6.1 Component: Compiler (Parser) | Version: 6.6 Resolution: | Keywords: lambda unicode lexical parse ? Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by porges): * failure: => None/Unknown * type: bug => feature request Comment: I've been thinking that maybe even another arrow might work here, so that we have something like: {{{ map (x ? f x) ys }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 21:42:36 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 21:18:07 2009 Subject: [GHC] #2984: Vectorized dph code doesn't terminate In-Reply-To: <042.776c42012cc46c4d8dc7e12433e5e6d8@localhost> References: <042.776c42012cc46c4d8dc7e12433e5e6d8@localhost> Message-ID: <051.6c690ac3229b68214cb42b2f54ef6510@localhost> #2984: Vectorized dph code doesn't terminate ------------------------------------+--------------------------------------- Reporter: fre | Owner: rl Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Data Parallel Haskell | Version: 6.13 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------------+--------------------------------------- Changes (by rl): * failure: => None/Unknown * version: 6.10.1 => 6.13 Comment: With the current HEAD, the code works fine with -O0. However, the simplifier loops with -Odph. I'm investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 16 22:28:24 2009 From: trac at galois.com (GHC) Date: Mon Nov 16 22:03:55 2009 Subject: [GHC] #17: Separate warnings for unused local and top-level bindings In-Reply-To: <047.fe4cdb312b5d86f34d27df1115f2c91a@localhost> References: <047.fe4cdb312b5d86f34d27df1115f2c91a@localhost> Message-ID: <056.3265308c4692cc055f80e80fd6266b98@localhost> #17: Separate warnings for unused local and top-level bindings ------------------------------+--------------------------------------------- Reporter: magunter | Owner: Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: -fwarn-unused-binds Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by byorgey): * failure: => None/Unknown * summary: RFE:Separate unused-binds local/top-level => Separate warnings for unused local and top-level bindings Comment: Would any developers care to guess at the difficulty of this feature? Could this make a good project for someone just starting to get their feet wet hacking on ghc? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 04:45:43 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 04:21:15 2009 Subject: [GHC] #29: Check for exhaustive patterns is broken In-Reply-To: <045.9dc542783fd9cde38eba0be02a5527cd@localhost> References: <045.9dc542783fd9cde38eba0be02a5527cd@localhost> Message-ID: <054.02375f4ffa5fe85791b5f921800b5696@localhost> #29: Check for exhaustive patterns is broken ---------------------------+------------------------------------------------ Reporter: nobody | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 5.02 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by ganesh): * failure: => None/Unknown Comment: This is an unsolvable issue. Consider this simplified example: {{{ foo x | x == 0 = 0 | x /= 0 = 0 }}} For "correct" Eq implementations these patterns are indeed exhaustive. But (a) GHC has no evidence that all Eq implementations are "correct", and (b) in general it would be undecidable to check whether arbitrary guards are exhaustive or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 05:48:04 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 05:23:33 2009 Subject: [GHC] #3645: Layout and pragmas In-Reply-To: <044.fddd9f8ae2f17ca6ebff5e268d132ce9@localhost> References: <044.fddd9f8ae2f17ca6ebff5e268d132ce9@localhost> Message-ID: <053.d8167294855185df74bf6b1a9236b137@localhost> #3645: Layout and pragmas --------------------------------+------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Parser) | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by guest): * failure: => None/Unknown * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 06:03:50 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 05:39:20 2009 Subject: [GHC] #29: Check for exhaustive patterns is broken In-Reply-To: <045.9dc542783fd9cde38eba0be02a5527cd@localhost> References: <045.9dc542783fd9cde38eba0be02a5527cd@localhost> Message-ID: <054.ea46b1d83b3b59cffff9c0b7c6668b62@localhost> #29: Check for exhaustive patterns is broken ---------------------------+------------------------------------------------ Reporter: nobody | Owner: Type: bug | Status: closed Priority: lowest | Milestone: _|_ Component: Compiler | Version: 5.02 Resolution: invalid | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by ganesh): * status: new => closed * resolution: None => invalid Comment: Closing this with the approval of the GHC team (http://www.haskell.org/pipermail/glasgow-haskell- users/2009-November/018017.html) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 07:25:56 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 07:01:27 2009 Subject: [GHC] #68: Warnings for unitialized fields In-Reply-To: <045.557e7250f2a1db18e5acbe51a391714e@localhost> References: <045.557e7250f2a1db18e5acbe51a391714e@localhost> Message-ID: <054.9e3e8696939203080a699422c0c5f277@localhost> #68: Warnings for unitialized fields --------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: warnings Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * failure: => None/Unknown Old description: > {{{ > Hello. > > Would it be possible to add flag to disable warnings for > unitialized fields just when using constructor with > zero fields? I mean, if I use > > Foo {} > > to construct empty record, it is a bit unpleasant that > I get flooded by dozens of useless warnings; but I don't > want to disable them -- they are useful when I forget > to initialize some field(s). > > Zdenek Dvorak > > }}} New description: Would it be possible to add flag to disable warnings for unitialized fields just when using constructor with zero fields? I mean, if I use {{{ Foo {} }}} to construct empty record, it is a bit unpleasant that I get flooded by dozens of useless warnings; but I don't want to disable them -- they are useful when I forget to initialize some field(s). Zdenek Dvorak Comment: Not clear if this is a good idea, but we'll leave it here anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 07:34:08 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 07:09:37 2009 Subject: [GHC] #95: GHCi :edit command should jump to the the last error In-Reply-To: <052.52d2f4855a60cbba938e5d2b851635de@localhost> References: <052.52d2f4855a60cbba938e5d2b851635de@localhost> Message-ID: <061.9f892337e461f921579d57fdbb736e21@localhost> #95: GHCi :edit command should jump to the the last error --------------------------------------+------------------------------------- Reporter: martijnislief | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: None Resolution: None | Keywords: Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * failure: => None/Unknown * summary: GHCi editor binding with ":e" => GHCi :edit command should jump to the the last error * milestone: 6.12 branch => _|_ Old description: > {{{ > For me, a very useful feature of Hugs is the ":e" command, > allowing to jump directly to the file and line number that > contain the first error. > > I'd be very happy if GHCi supported this feature. > }}} New description: GHCi has a `:edit` command for editing the current source file. Hugs's command of the same name automatically jumps the editor to the location of the last error; it would be nice if GHCi's did the same. Comment: You can define it yourself, but it's a bit hacky and it would clearly be better to have it built-in. This is also a small self-contained task (limited to the GHCi front end) that a new contributor could take on. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 07:54:32 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 07:30:01 2009 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@localhost> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@localhost> Message-ID: <054.9a439b469238811cd3d04daef9b29a99@localhost> #229: Integer overflow in array allocation -----------------------------+---------------------------------------------- Reporter: josefs | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by StefanWehr): * failure: => None/Unknown Comment: With ghci 6.10.4 on Linux the problem no longer occurs. (You get an "Exception: Error in array index" instead of a core dump.) The bug seems to be fixed but I did not dare to change the status. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 07:58:33 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 07:34:01 2009 Subject: [GHC] #3670: Allow RULES for higher-ranked terms In-Reply-To: <041.aeabb46c1a24d91fe9a4aa4c22f11019@localhost> References: <041.aeabb46c1a24d91fe9a4aa4c22f11019@localhost> Message-ID: <050.e13e74e4c4978a892b5b66917048c73a@localhost> #3670: Allow RULES for higher-ranked terms ------------------------------------------------+--------------------------- Reporter: rl | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: simplCore/should_compile/rule2.hs | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------------------------+--------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/rule2.hs * difficulty: => * status: new => closed * resolution: => fixed * failure: => None/Unknown Comment: Good idea. Fixed by {{{ Tue Nov 17 12:54:17 GMT 2009 simonpj@microsoft.com * Improvement to typecheck higher-rank rules better See Note [Typechecking rules] in TcRules. Suggested by Roman M ./compiler/typecheck/TcRules.lhs -5 +20 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 08:45:13 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 08:20:41 2009 Subject: [GHC] #3671: Add partitioning functions to Data.List Message-ID: <047.97ceba79bfaf5cc5b24cb90720e1b14e@localhost> #3671: Add partitioning functions to Data.List ---------------------------------+------------------------------------------ Reporter: holzensp | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.12.1 RC1 | Keywords: Data.List Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ The functions `take` and `span` have recursive equivalents `takeRec` and `spanRec` that apply the same function to the remainder, i.e. {{{ takeRec i xs = let (hs,ts) = splitAt i xs in hs : takeRec i xs spanRec p xs = let (hs,ts) = span p xs in hs : spanRec p xs }}} and the more generic version of `take`: {{{ genericTakeRec i xs = let (hs,ts) = genericSplitAt i xs in hs : genericTakeRec i xs }}} These functions, to me, are in the same league as `partition` and `group`, can be added with little chance of nameclashes on functions with a different meaning and are not named compositions. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 08:49:44 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 08:25:12 2009 Subject: [GHC] #3671: Add partitioning functions to Data.List In-Reply-To: <047.97ceba79bfaf5cc5b24cb90720e1b14e@localhost> References: <047.97ceba79bfaf5cc5b24cb90720e1b14e@localhost> Message-ID: <056.a2d15ae2ec9adf66fa8670d6a4ae226e@localhost> #3671: Add partitioning functions to Data.List ---------------------------------+------------------------------------------ Reporter: holzensp | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.12.1 RC1 Resolution: | Keywords: Data.List Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment (by holzensp): Correction, obviously: {{{ takeRec i xs = let (hs,ts) = splitAt i xs in hs : takeRec i ts spanRec p xs = let (hs,ts) = span p xs in hs : spanRec p ts genericTakeRec i xs = let (hs,ts) = genericSplitAt i xs in hs : genericTakeRec i ts }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 08:59:01 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 08:34:31 2009 Subject: [GHC] #17: Separate warnings for unused local and top-level bindings In-Reply-To: <047.fe4cdb312b5d86f34d27df1115f2c91a@localhost> References: <047.fe4cdb312b5d86f34d27df1115f2c91a@localhost> Message-ID: <056.5eb212d6157a45cf9a3d516a66bf7757@localhost> #17: Separate warnings for unused local and top-level bindings ------------------------------+--------------------------------------------- Reporter: magunter | Owner: Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: -fwarn-unused-binds Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by mboes): * cc: mboes@lix.polytechnique.fr (added) Comment: I doubt the usefulness of this feature since any top-level function that is mentioned in the export list of the module won't trigger a warning. It is confusing to see dead code in a module and so top-level functions that aren't used should probably just be commented out. However, this feature does come handy when using records: it often happens that a field name isn't used in a module, hence triggering a warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 09:06:29 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 08:41:57 2009 Subject: [GHC] #3671: Add partitioning functions to Data.List In-Reply-To: <047.97ceba79bfaf5cc5b24cb90720e1b14e@localhost> References: <047.97ceba79bfaf5cc5b24cb90720e1b14e@localhost> Message-ID: <056.ce6890fb914f1be2694f05f8070f9040@localhost> #3671: Add partitioning functions to Data.List ---------------------------------+------------------------------------------ Reporter: holzensp | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.12.1 RC1 Resolution: | Keywords: Data.List Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Comment (by holzensp): Oh my, so sloppy; forgot base cases. Last try. {{{ takeRec :: Int -> [a] -> [[a]] takeRec = genericTakeRec genericTakeRec :: (Integral a) => a -> [b] -> [[b]] genericTakeRec n _ | n <= 0 = [] genericTakeRec _ [] = [] genericTakeRec i xs = let (hs,ts) = genericSplitAt i xs in hs : genericTakeRec i ts spanRec :: (a -> Bool) -> [a] -> [[a]] spanRec _ [] = [] spanRec p xs = let (hs,ts) = span p xs in hs : spanRec p ts }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 09:40:45 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 09:16:17 2009 Subject: [GHC] #3672: Let Linker.c know about stg_arg_bitmaps Message-ID: <044.9478d419ceaff4352f148c46bb1abb99@localhost> #3672: Let Linker.c know about stg_arg_bitmaps ---------------------------------+------------------------------------------ Reporter: int-e | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.13 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ stg_args_bitmaps is useful to make sense of AP and PAP closures on the heap, i.e. for heap inspecting code. So it would be nice if code other than the RTS that uses it worked in ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 10:31:32 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 10:07:03 2009 Subject: [GHC] #3655: Performance regression relative to 6.10 In-Reply-To: <047.de41e91ed6bceb6d2068db2adb01f317@localhost> References: <047.de41e91ed6bceb6d2068db2adb01f317@localhost> Message-ID: <056.5c35742861d12bfeff625bf04e76b2a3@localhost> #3655: Performance regression relative to 6.10 --------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonmar): We tracked it down to `sequence_` not fusing with `map` in a couple of places, due to `sequence_` not having arity 2 which was preventing a partially-applied call being inlined, which meant that the rule didn't fire. Simon PJ is going to investigate further. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 10:37:48 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 10:13:17 2009 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@localhost> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@localhost> Message-ID: <054.81b37b86c09b8ddc6f731639c84c73b1@localhost> #229: Integer overflow in array allocation -----------------------------+---------------------------------------------- Reporter: josefs | Owner: Type: bug | Status: closed Priority: low | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: None => fixed Comment: Thanks Stefan! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 10:43:28 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 10:18:58 2009 Subject: [GHC] #3583: Default view patterns In-Reply-To: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> References: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> Message-ID: <051.1ae4ac1015bbf546b789ef3b9f284fc7@localhost> #3583: Default view patterns -----------------------------------------+---------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Comment (by simonmar): On the policy issue: if it's clear an idea is bad, then we should close the ticket, yes. On this particular issue it looks like there is some support for the idea, if not in the exact form suggested by the original submitter. Could someone familiar with the details update the ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 11:10:25 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 10:45:53 2009 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@localhost> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@localhost> Message-ID: <054.4d5385ac7831eb30a5a3773dfb766d0a@localhost> #229: Integer overflow in array allocation -----------------------------+---------------------------------------------- Reporter: josefs | Owner: Type: bug | Status: closed Priority: low | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Old description: > {{{ > When asked to create a sufficiently large array ghci > coredumps. > > \begin{code} > import Data.Array.ST > import Control.Monad.ST > import GHC.Base > > example = runST (do arr <- newArray (minInt,maxInt) > False > go arr) > where go :: STArray s Int Bool -> ST s Bool > go arr = readArray arr 3 > \end{code} > > Load this into ghci and type 'example'. > }}} New description: When asked to create a sufficiently large array ghci coredumps. {{{ \begin{code} import Data.Array.ST import Control.Monad.ST import GHC.Base example = runST (do arr <- newArray (minInt,maxInt) False go arr) where go :: STArray s Int Bool -> ST s Bool go arr = readArray arr 3 \end{code} }}} Load this into ghci and type 'example'. Comment (by josef): Using the bounds (minInt,maxInt) was probably the wrong thing todo. My concern when filing the bug report was not the arithmetic overflow but the fact that ghci crashes when it tries to allocate a too large an array. It is still possible to provoke a crash if you change the array bounds to, say, (2,maxInt). Should I open a new ticket or reopen this one? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 11:11:14 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 10:46:43 2009 Subject: [GHC] #2439: Missed optimisation with dictionaries and loops In-Reply-To: <041.4a9e022e22f0d06a0023c060ae99c7bb@localhost> References: <041.4a9e022e22f0d06a0023c060ae99c7bb@localhost> Message-ID: <050.3171b7af59038005f6902eb4864e0ab3@localhost> #2439: Missed optimisation with dictionaries and loops --------------------------------------+------------------------------------- Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by rl): I'm not sure how this translates to the new inliner. This is code that is generated now: {{{ Foo.sum' = \ (@ a_aj6) ($dNum_aje :: GHC.Num.Num a_aj6) -> let { lit_skO [Dmd=Just L] :: a_aj6 [LclId, Str=DmdType] lit_skO = GHC.Num.fromInteger @ a_aj6 $dNum_aje Foo.sum'1 } in letrec { loop_skM [Occ=LoopBreaker] :: a_aj6 -> [a_aj6] -> a_aj6 [LclId, Arity=2, Str=DmdType SS] loop_skM = \ (z_afp :: a_aj6) (ds_djs :: [a_aj6]) -> case z_afp of z1_XfG { __DEFAULT -> case ds_djs of _ { [] -> z1_XfG; : x_afr xs_afs -> loop_skM (GHC.Num.+ @ a_aj6 $dNum_aje z1_XfG x_afr) xs_afs } }; } in \ (xs_afu :: [a_aj6]) -> loop_skM lit_skO xs_afu }}} Instead of scrutinising the dictionary, we are now calling the method selector in every iteration. Is this even worse than before? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 11:15:24 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 10:50:53 2009 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@localhost> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@localhost> Message-ID: <054.dda3030061920096b377fcde411d7ab4@localhost> #229: Integer overflow in array allocation -----------------------------+---------------------------------------------- Reporter: josefs | Owner: Type: bug | Status: reopened Priority: low | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: fixed => Comment: Ok, re-opening. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 11:20:29 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 10:55:58 2009 Subject: [GHC] #565: overlapping instances & fundeps broken In-Reply-To: <047.be51df89a55fc16684527ec6b862b817@localhost> References: <047.be51df89a55fc16684527ec6b862b817@localhost> Message-ID: <056.cffdf80ea3697edfe77ea07ae834e4bb@localhost> #565: overlapping instances & fundeps broken --------------------------------------+------------------------------------- Reporter: ashley-y | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler (Type checker) | Version: 5.00 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by ganesh): * failure: => None/Unknown Comment: The problem with all these examples is that someone (in another module) add {{{instance Num Bool}}}, and now the instances really do overlap, and the fundep is violated. So I think this bug should be closed as invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 11:45:20 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 11:20:48 2009 Subject: [GHC] #2439: Missed optimisation with dictionaries and loops In-Reply-To: <041.4a9e022e22f0d06a0023c060ae99c7bb@localhost> References: <041.4a9e022e22f0d06a0023c060ae99c7bb@localhost> Message-ID: <050.b885a53a64061801724fa09dc9942a34@localhost> #2439: Missed optimisation with dictionaries and loops --------------------------------------+------------------------------------- Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Comment (by simonpj): I think the underling issue hasn't changed. The only difference is that before we inlined the method selector and now we don't. (Deliberately -- little is gained by doing so.) So it's more or less the same with new and old inliner. I think that strict dictionaries are still the answer here. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 12:23:08 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 11:58:37 2009 Subject: [GHC] #110: Cygwin binaries In-Reply-To: <046.e27078d66dc3ce56ae08f6163d6a3403@localhost> References: <046.e27078d66dc3ce56ae08f6163d6a3403@localhost> Message-ID: <055.f25994ed5f9e4d8a44fe7d2aef05e959@localhost> #110: Cygwin binaries ------------------------------+--------------------------------------------- Reporter: fizzgig | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: None Resolution: None | Keywords: Difficulty: Unknown | Os: Windows Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by yairchu): * failure: => None/Unknown * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 12:55:42 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 12:31:11 2009 Subject: [GHC] #3303: Allow multi-line deprecation messages. In-Reply-To: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> References: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> Message-ID: <054.508b639d218b60b90366fa1dce8bd24f@localhost> #3303: Allow multi-line deprecation messages. ---------------------------+------------------------------------------------ Reporter: duncan | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: Merged: {{{ Sun Nov 15 15:56:17 GMT 2009 Duncan Coutts * Fix formatting of module deprecation/warning messages Ignore-this: a41444bdda003aee4412eb56a0e7d052 It was accidentally using list syntax. Fixes #3303 again. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 13:00:10 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 12:35:38 2009 Subject: [GHC] #3532: haddock should support content indexing of versioned package dirs In-Reply-To: <050.349010e190ff2a924354f840d1a8ec2b@localhost> References: <050.349010e190ff2a924354f840d1a8ec2b@localhost> Message-ID: <059.021d5509137a149701f6a9309794c77a@localhost> #3532: haddock should support content indexing of versioned package dirs ----------------------------+----------------------------------------------- Reporter: juhpetersen | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: Fixed in HEAD and 6.12 by: {{{ Sun Nov 8 21:07:01 GMT 2009 Ian Lynagh * Put docs into versioned directory names; fixes trac #3532 You can now have multiple versions of a package installed, and gen_contents_index will do the right thing. Tue Nov 10 22:36:32 GMT 2009 Ian Lynagh * Use relative paths for haddockHTMLs in the inplace package.conf This means that the docs get built with the correct relative paths. When installing, the absolute path will still be used. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 13:13:22 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 12:48:51 2009 Subject: [GHC] #565: overlapping instances & fundeps broken In-Reply-To: <047.be51df89a55fc16684527ec6b862b817@localhost> References: <047.be51df89a55fc16684527ec6b862b817@localhost> Message-ID: <056.17e3f71065ceab5fe0727d8d8d1a809f@localhost> #565: overlapping instances & fundeps broken --------------------------------------+------------------------------------- Reporter: ashley-y | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler (Type checker) | Version: 5.00 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * owner: => simonpj Comment: I agree; Simon, can you confirm and close it, please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 14:22:35 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 13:58:13 2009 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.f4b5c156433828b9eaae2eb84a70dd09@localhost> #2615: ghci doesn't play nice with linker scripts ---------------------------+------------------------------------------------ Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by slyfox): * cc: slyfox (added) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 17:20:43 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 16:56:17 2009 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.5020a4092d7aa1c9e5f1e260ff3d48aa@localhost> #1185: can't do I/O in the child of forkProcess with -threaded -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.6 Resolution: fixed | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: The "One more patch" seems to already be applied, but I've merged the rest and the test now passes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 18:59:36 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 18:35:02 2009 Subject: [GHC] #3669: haddock: internal Haddock or GHC error: Win32-version:: openBinaryFile: invalid argument (Invalid argument) In-Reply-To: <044.70edc156bbd5a808fbee0fac2c67b568@localhost> References: <044.70edc156bbd5a808fbee0fac2c67b568@localhost> Message-ID: <053.a7aca5bd3aabe0435f15a34ff32b39a4@localhost> #3669: haddock: internal Haddock or GHC error: Win32-version:: openBinaryFile: invalid argument (Invalid argument) ---------------------------+------------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: Fixed in HEAD and 6.12 by: {{{ Tue Nov 17 22:35:56 GMT 2009 Ian Lynagh * Fix gen_contents_index on MSYS On MSYS sed 's/.*[ \t]//' wasn't matching version:1.0 so I've switched to 's/.*[[:space:]]//' which works on Linux, cygwin and MSYS. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 20:40:26 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 20:15:55 2009 Subject: [GHC] #1117: [2,4..10] is not a good list producer In-Reply-To: <058.fec7922295918bad47fc72cb2c7643ce@localhost> References: <058.fec7922295918bad47fc72cb2c7643ce@localhost> Message-ID: <067.7d9ae61b2b251d959edc295fc1f2df83@localhost> #1117: [2,4..10] is not a good list producer --------------------------------------+------------------------------------- Reporter: br1@internet.com.uy | Owner: Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.6 Resolution: | Keywords: rewrite rules Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by daniel.is.fischer): * failure: => None/Unknown Comment: Seems fixed. Timings with 6.10.3: fastest 2.55s, fast 2.64s, slow 2.71s on average. I think that's good enough, suggest closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 21:59:00 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 21:34:36 2009 Subject: [GHC] #3671: Add partitioning functions to Data.List In-Reply-To: <047.97ceba79bfaf5cc5b24cb90720e1b14e@localhost> References: <047.97ceba79bfaf5cc5b24cb90720e1b14e@localhost> Message-ID: <056.a22702b3ab896ca144e0091e01996572@localhost> #3671: Add partitioning functions to Data.List -----------------------------+---------------------------------------------- Reporter: holzensp | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.12.1 RC1 Resolution: | Keywords: Data.List Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by malcolm.wallace@cs.york.ac.uk): * difficulty: => Comment: Although your recursive 'takeRec' makes some sense, the recursive 'spanRec' is more dubious. {{{ spanRec p xs = let (hs,ts) = span p xs in hs : spanRec p ts }}} By the definition of 'span', the first element of 'ts' satisfies the predicate p. Thus, in the first recursive call, 'span' will split the remaining list into [] and ts, the second recursive call likewise, and so on ad infinitum. {{{ spanRec (==0) [1,2,3,0,4,5,6] = [1,2,3]:[]:[]:[]:[]... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 17 23:29:49 2009 From: trac at galois.com (GHC) Date: Tue Nov 17 23:05:22 2009 Subject: [GHC] #1216: indexing 2d arrays is slow and leaky. why? In-Reply-To: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> References: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> Message-ID: <053.c44f9d014fd86f1215f16b052b3d1ab5@localhost> #1216: indexing 2d arrays is slow and leaky. why? --------------------------------------+------------------------------------- Reporter: claus | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.6 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by daniel.is.fischer): * cc: daniel.is.fischer@web.de (added) Comment: Still slow and also overallocating in 6.10.3: {{{ ./indexL 100000 +RTS -sstderr array (1,40) [snip] 7,132,475,396 bytes allocated in the heap 935,808 bytes copied during GC 31,748 bytes maximum residency (1 sample(s)) 22,992 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 13604 collections, 0 parallel, 0.20s, 0.16s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 11.34s ( 11.42s elapsed) GC time 0.20s ( 0.16s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 11.55s ( 11.58s elapsed) %GC time 1.8% (1.4% elapsed) Alloc rate 628,705,232 bytes per MUT second Productivity 98.2% of total user, 97.9% of total elapsed dafis@linux-mkk1:~/Haskell/CafeTesting> ./indexH +RTS -sstderr -RTS 100000 ./indexH 100000 +RTS -sstderr array (1,40) [snip] 9,800,880 bytes allocated in the heap 11,908 bytes copied during GC 31,696 bytes maximum residency (1 sample(s)) 22,992 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 18 collections, 0 parallel, 0.00s, 0.00s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 3.80s ( 3.80s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 3.80s ( 3.80s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 2,581,735 bytes per MUT second Productivity 100.0% of total user, 100.0% of total elapsed }}} Both compiled with -O2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 04:05:13 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 03:40:47 2009 Subject: [GHC] #3671: Add partitioning functions to Data.List In-Reply-To: <047.97ceba79bfaf5cc5b24cb90720e1b14e@localhost> References: <047.97ceba79bfaf5cc5b24cb90720e1b14e@localhost> Message-ID: <056.a49be7ff53b82feb02b44797ee3faf60@localhost> #3671: Add partitioning functions to Data.List -----------------------------+---------------------------------------------- Reporter: holzensp | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.12.1 RC1 Resolution: | Keywords: Data.List Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Comment (by holzensp): Ian remarked the same oversight: http://old.nabble.com/Proposal-(Trac-ticket--3671):-Add-takeRec ,-genericTakeRec-and-spanRec-to-Data.List-td26390220.html New suggestion (with other names as suggested in the same mail thread): {{{ splitAts :: Int -> [a] -> [[a]] splitAts = genericSplitAts genericSplitAts :: (Integral a) => a -> [b] -> [[b]] genericSplitAts n _ | n <= 0 = [] genericSplitAts _ [] = [] genericSplitAts i xs = let (hs,ts) = genericSplitAt i xs in hs : genericSplitAts i ts spans :: (a -> Bool) -> [a] -> [[a]] spans _ [] = [] spans p xs = let (hs,ts) = span p xs in hs : breaks p ts breaks :: (a -> Bool) -> [a] -> [[a]] breaks _ [] = [] breaks p xs = let (hs,ts) = break p xs in hs : spans p ts }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 04:08:50 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 03:44:16 2009 Subject: [GHC] #3673: ghc-6.12.0 does not include ghc-tarballs/ for libffi? Message-ID: <050.b68394efb988a73847ccbb048b04c166@localhost> #3673: ghc-6.12.0 does not include ghc-tarballs/ for libffi? ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.1 RC1 | Keywords: Os: Linux | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ When I try to build latest ghc-6.12.0 nightly snapshots I get: {{{ cp rts/sm/Scav.c rts/dist/build/sm/Scav_thr.c "rm" -f -r libffi/build cd libffi && /bin/gtar -zxf ../ghc-tarballs/libffi/libffi*.tar.gz done. "inplace/bin/mkdirhier" bootstrapping "inplace/bin/mkdirhier" utils/ghc-cabal/dist/build/tmp/ /bin/gtar: ../ghc-tarballs/libffi/libffi*.tar.gz: Cannot open: No such file or directory /bin/gtar: Error is not recoverable: exiting now /bin/gtar: Child returned status 2 /bin/gtar: Exiting with failure status due to previous errors make[2]: *** [libffi/stamp.ffi.configure-shared] Error 2 }}} A workaround seems to be: mkdir ghc-tarballs ; ln -s ../libffi/tarball ghc-tarballs/libffi I see there is http://darcs.haskell.org/ghc-tarballs/ but not in the ghc tarball. Is there supposed to be another tarball for that or better still can system libffi be used? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 06:31:56 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 06:07:24 2009 Subject: [GHC] #1117: [2,4..10] is not a good list producer In-Reply-To: <058.fec7922295918bad47fc72cb2c7643ce@localhost> References: <058.fec7922295918bad47fc72cb2c7643ce@localhost> Message-ID: <067.e7a99a7e3bac16f8149cf9bd8980d30c@localhost> #1117: [2,4..10] is not a good list producer --------------------------------------+------------------------------------- Reporter: br1@internet.com.uy | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.6 Resolution: fixed | Keywords: rewrite rules Difficulty: Easy (less than 1 hour) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * failure: None/Unknown => Runtime performance bug * resolution: => fixed Comment: Indeed, looks like efdtInt now has a RULE. Thanks Daniel! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 06:42:17 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 06:17:48 2009 Subject: [GHC] #284: RPM doesn't support --prefix In-Reply-To: <046.1144a6291b544d9e99e352d8d1860ffd@localhost> References: <046.1144a6291b544d9e99e352d8d1860ffd@localhost> Message-ID: <055.3668d7f6c8b129b54f804eee1649a05f@localhost> #284: RPM doesn't support --prefix ------------------------------+--------------------------------------------- Reporter: skaller | Owner: juhp Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: None Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by simonmar): * cc: bos@serpentine.com (added) * failure: => None/Unknown Comment: Bryan: this is an old bug against GHC. Is it worth keeping around, do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 08:06:33 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 07:42:01 2009 Subject: [GHC] #3583: Default view patterns In-Reply-To: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> References: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> Message-ID: <051.4eb13b309cacc951ef3ce049296e4a4a@localhost> #3583: Default view patterns -----------------------------------------+---------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Comment (by ksf): Well, I think that totally implicit view patterns are probably a very good idea, because they reduce the syntactic overhead of abstraction (I'm going to pretend to be able to override (:) for the sake of argument): {{{ foo (x:xs) = x + length xs vs. foo (-> (x:xs)) = x + length' xs vs. foo xs = head' xs + length' (tail' xs) }}} Consider parsing libraries: Only uu-parsinglib and Parsec (>=3) support matching on arbitrary left-disectable sequences, while certainly every parsing library could do that. I think the main reason for this is the clarity and ease of matching on (:). While # 2 does certainly look more idiomatic than # 3, I fear it would still not be enough to foster wide- spread adoption of such abstraction. Even now, uu-parsinglib and Parsec3 come with separate uncons classes. The same argument applies to [Char] vs. ByteString vs. Data.Text vs. Seq Char: gazillions of functions could work on all of them, and most likely being made to work (with a bit of luck) just by adding an -X flag (I'm in the "safe Haskell by throwing typeclasses at it"-camp). As I can't see any instance where # 1 and # 2 would differ in anything but how often the method "view" can be captured, I certainly prefer the # 1 for its clarity: Providing two language options -- e.g. -XViewPatters and -XImplicitViews -- might not only help avoiding Wadler's Law and offload the discussion to what's common usage after some time, but also provide a graceful update path for code that already has "view" in scope: -XViewPatters would only capture it with explitit -> Syntax, -XImplicitViews always. In any case, if things won't work out, you'll get a type error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 09:13:42 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 08:49:09 2009 Subject: [GHC] #3674: Recognise language pragmas generated by custom pre-processors (run with -F) Message-ID: <047.f133953f7994cae1dfd3e6f2c8e5d7e7@localhost> #3674: Recognise language pragmas generated by custom pre-processors (run with -F) ---------------------------------+------------------------------------------ Reporter: dorchard | Owner: dorchard Type: feature request | Status: new Priority: normal | Component: Compiler Version: | Keywords: customer pre-processor Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program ---------------------------------+------------------------------------------ A custom pre-processor might desugar terms into terms of a particular language extension, requiring a new language pragma. Currently, any language pragmas generated by a pre-processor will be ignored once the pre-processed file is picked up by GHC again. As a contrived example, consider foo.hs: {{{ {-# OPTIONS -F -pgmF ./preprocess.sh #-} data Foo a where MkFoo :: Foo a }}} where preprocess.sh: {{{ #!/bin/sh ( echo "{-# LANGUAGE GADTs #-}"; cat $2; ) > $3 }}} Currently we get this behaviour: {{{ bash-3.2$ ghc foo.hs /tmp/ghc7191_0/ghc7191_0.hspp:4:0: Illegal generalised algebraic data declaration for `Foo' (Use -XGADTs to allow GADTs) In the data type declaration for `Foo' bash-3.2$ ghc foo.hs -E bash-3.2$ cat foo.hspp {-# LANGUAGE GADTs #-} {-# OPTIONS -F -pgmF ./preprocess.sh #-} data Foo a where MkFoo :: Foo abash-3.2$ }}} It would be nice if GHC noticed the new pragmas, particularly language pragmas, although perhaps not all pragmas should be picked up (maybe not new OPTION pragmas). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 09:48:24 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 09:23:50 2009 Subject: [GHC] #565: overlapping instances & fundeps broken In-Reply-To: <047.be51df89a55fc16684527ec6b862b817@localhost> References: <047.be51df89a55fc16684527ec6b862b817@localhost> Message-ID: <056.350eec3c340bcfa29f6905e2a975743c@localhost> #565: overlapping instances & fundeps broken --------------------------------------+------------------------------------- Reporter: ashley-y | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler (Type checker) | Version: 5.00 Resolution: invalid | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: None => invalid Comment: I agree. And in any case we want to encourage people to move towards type functions, partly because questions like this are pretty tricky. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 10:28:58 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 10:04:35 2009 Subject: [GHC] #317: Simplifier doesn't preserve bottoms sometimes In-Reply-To: <047.130c185a0751065df2ec3070f89ac526@localhost> References: <047.130c185a0751065df2ec3070f89ac526@localhost> Message-ID: <056.cee676e684d68b609e00e980c27f11fd@localhost> #317: Simplifier doesn't preserve bottoms sometimes ---------------------------+------------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by judah): * status: new => closed * failure: => None/Unknown * resolution: None => fixed Comment: Both of the programs listed above loop forever with ghc-6.10.3 and ghc-6.13.2009-10-31; so it looks like this issue has been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 10:51:27 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 10:26:53 2009 Subject: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs In-Reply-To: <044.a73c522b97030f99c5fa39d521657f06@localhost> References: <044.a73c522b97030f99c5fa39d521657f06@localhost> Message-ID: <053.f1a776a9a8a701bf4fc37c8ea065ba2d@localhost> #781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.5 Resolution: | Keywords: getEnvironment Difficulty: Unknown | Os: Linux Testcase: getEnvironment01 | Architecture: x86_64 (amd64) Failure: GHCi crash | -------------------------------+-------------------------------------------- Changes (by simonmar): * failure: => GHCi crash -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 10:58:14 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 10:34:10 2009 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> Message-ID: <053.6a2bbc5bf062f63d9b0cf408b3fcda40@localhost> #2578: "ld: atom sorting error for ..." on OS X ------------------------------------------------+--------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Changes (by simonmar): * failure: => Incorrect warning at compile-time -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 11:00:27 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 10:35:56 2009 Subject: [GHC] #831: GHCi user interface bug In-Reply-To: <044.0baedce61839e3c7431c6b15fa012c5b@localhost> References: <044.0baedce61839e3c7431c6b15fa012c5b@localhost> Message-ID: <053.be13c5009949c2047edd17e6eec758ee@localhost> #831: GHCi user interface bug --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: low | Milestone: _|_ Component: GHCi | Version: 6.4.2 Resolution: fixed | Keywords: Difficulty: Easy (less than 1 hour) | Os: Windows Testcase: N/A | Architecture: x86 Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by judah): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: This behavior does not appear in ghc-6.10.3 or ghc-6.13.20090923. It was fixed by using Haskeline instead of the Windows console's unbuffered `getLine`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 11:00:35 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 10:36:03 2009 Subject: [GHC] #1605: hppa port -- gmp handed misaligned memory In-Reply-To: <044.7ca61f85138b90c0e193b83a232b3207@localhost> References: <044.7ca61f85138b90c0e193b83a232b3207@localhost> Message-ID: <053.e830ce78168029ba17ed142dd354cc8f@localhost> #1605: hppa port -- gmp handed misaligned memory --------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.6.1 Resolution: | Keywords: GMP Difficulty: Easy (less than 1 hour) | Os: HPUX Testcase: | Architecture: hppa Failure: Runtime crash | --------------------------------------+------------------------------------- Changes (by simonmar): * failure: => Runtime crash -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 11:56:44 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 11:32:10 2009 Subject: [GHC] #3675: load fails with Literate target contents Message-ID: <059.e4fb807f52838bcaa82d8c96f6c3158a@localhost> #3675: load fails with Literate target contents -------------------------------------+-------------------------------------- Reporter: JeanPhilippeMoresmau | Owner: Type: bug | Status: new Priority: normal | Component: GHC API Version: 6.10.4 | Keywords: preprocess Literate Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect warning at compile-time -------------------------------------+-------------------------------------- I am loading a target with actual contents (targetContents=Just (contents, time)). The contents are literate Haskell. I get compilation errors instead of the "preprocessing needed, interactive check disabled" error I should get. It works if I manually set the Phase to Unlit HsSrcFile, but the doc says it should guess it's literate from the file extension. I'm using 6.10.4 in Windows.[[BR]] GHC.hs line 2240: [[BR]] Nothing <- mb_phase, Unlit _ <- startPhase src_fn = True[[BR]] (src_fn is the file name, endings in .lhs in my case)[[BR]] DriverPhase.hs line 146:[[BR]] startPhase "lhs" = Unlit HsSrcFile[[BR]] Somewhere in there we forgot to move from "/drive/dir/foo.lhs" to "lhs". We need something like tail $ takeExtension $ src_fn, and handling gracefully the case where there is no extension.[[BR]] I can try to actually code the patch, but I've never tried to build GHC on my machine.... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 12:13:25 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 11:48:50 2009 Subject: [GHC] #3665: Add whole-package deprecation warnings In-Reply-To: <045.b5f8edc411a6fdd1d799c2489f96cbc0@localhost> References: <045.b5f8edc411a6fdd1d799c2489f96cbc0@localhost> Message-ID: <054.afe67d3ec0ea96f5687e3d7cc748aef0@localhost> #3665: Add whole-package deprecation warnings ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: I've applied the base3-deprecation-message in 6.12 (HEAD doesn't have base3-compat), and I agree that package-wide deprecation is really a Cabal or cabal-install feature request, not something we should do in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 12:28:47 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 12:04:13 2009 Subject: [GHC] #3457: Impossible to specify pragmas compatible with multiple ghc versions In-Reply-To: <045.b42d9302a58a1a0f28ab9ef59d342a90@localhost> References: <045.b42d9302a58a1a0f28ab9ef59d342a90@localhost> Message-ID: <054.e50bb71855479b0e37796ce532d6cd49@localhost> #3457: Impossible to specify pragmas compatible with multiple ghc versions -----------------------------------------+---------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Driver | Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | -----------------------------------------+---------------------------------- Changes (by duncan): * difficulty: Unknown => Moderate (less than a day) * failure: => GHC rejects valid program Comment: #3474 and #2464 are bugs with the same fix. The core of the problem is this: ghc --make reads the source file headers to chase imports. If it discovers the source file needs pre-processing, e.g. {{{ {-# OPTIONS -F -pgmF ./preprocess.sh #-} }}} or {{{ {-# LANGUAGE CPP #-} }}} then it runs the pre-processor. However, this is where it makes the mistake. When it re-reads the source after-preprocessing it retains all the information about which pragmas etc were in effect from when it looked at the original source file prior to pre-processing and uses this when it reads the new source file. This does not take account of the fact that this info could be changed by the pre- processor. If you run the pre-processor manually then of course ghc is forced to do the correct thing because then you do not give ghc the opportunity to remember any incorrect state (assuming the pre-processor strips out the pragam that instructs ghc to run the pre-processor!). The fix is simply to start from a clean slate after pre-processing and process the new source file without any presumptions. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 12:29:46 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 12:05:10 2009 Subject: [GHC] #3457: Impossible to specify pragmas compatible with multiple ghc versions In-Reply-To: <045.b42d9302a58a1a0f28ab9ef59d342a90@localhost> References: <045.b42d9302a58a1a0f28ab9ef59d342a90@localhost> Message-ID: <054.4893996a67a6b05b7e6ba2629bb7aeda@localhost> #3457: Impossible to specify pragmas compatible with multiple ghc versions -----------------------------------------+---------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Driver | Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | -----------------------------------------+---------------------------------- Comment (by duncan): Oops, I meant #3674. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 12:30:25 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 12:05:50 2009 Subject: [GHC] #3674: Recognise language pragmas generated by custom pre-processors (run with -F) In-Reply-To: <047.f133953f7994cae1dfd3e6f2c8e5d7e7@localhost> References: <047.f133953f7994cae1dfd3e6f2c8e5d7e7@localhost> Message-ID: <056.d2435fa6dae8e01f5dff3cacf7580452@localhost> #3674: Recognise language pragmas generated by custom pre-processors (run with -F) -----------------------------------------+---------------------------------- Reporter: dorchard | Owner: dorchard Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Driver | Version: Resolution: | Keywords: customer pre-processor Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | -----------------------------------------+---------------------------------- Changes (by duncan): * difficulty: => Moderate (less than a day) * type: feature request => bug * component: Compiler => Driver * milestone: => 6.14.1 Comment: #3457 and #2464 are bugs with the same fix. They are all instances of the same problem in the way ghc handles information gleaned from source files prior to pre-processing (with cpp or a custom pre-processor). See #3457 for a description. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 15:02:35 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 14:38:05 2009 Subject: [GHC] #3662: Don't know how to install documentation In-Reply-To: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> References: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> Message-ID: <051.345c4ea87892729f3287a7f4898e0056@localhost> #3662: Don't know how to install documentation ---------------------------+------------------------------------------------ Reporter: bos | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.12: {{{ Mon Nov 16 04:01:37 PST 2009 Simon Marlow * Add an install-docs target that emits a helpful diagnostic (#3662) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 17:53:55 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 17:29:51 2009 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> Message-ID: <053.66604734f8f2559eb4d38bbb9770b080@localhost> #2578: "ld: atom sorting error for ..." on OS X ------------------------------------------------+--------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Comment (by chak): FWIW, I don't think that I have seen this warning on Snow Leopard at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 20:15:57 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 19:51:21 2009 Subject: [GHC] #3673: ghc-6.12.0 does not include ghc-tarballs/ for libffi? In-Reply-To: <050.b68394efb988a73847ccbb048b04c166@localhost> References: <050.b68394efb988a73847ccbb048b04c166@localhost> Message-ID: <059.a111bee99f784440c8d57dbc1c6ecd70@localhost> #3673: ghc-6.12.0 does not include ghc-tarballs/ for libffi? ---------------------------+------------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => * resolution: => fixed Comment: Thanks for the report; fixed by {{{ Wed Nov 18 13:10:47 GMT 2009 Ian Lynagh * Add ghc-tarballs to the list of directories that go into an sdist }}} in HEAD and 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 21:56:12 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 21:31:37 2009 Subject: [GHC] #2143: Yhc's sort is faster than GHC's In-Reply-To: <051.957b307ec22b893e4ac872796076b55a@localhost> References: <051.957b307ec22b893e4ac872796076b55a@localhost> Message-ID: <060.27e03a1d80f7736b413e8a24a89b9e94@localhost> #2143: Yhc's sort is faster than GHC's -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: NeilMitchell Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by daniel.is.fischer): * failure: => None/Unknown Comment: The Yhc code doesn't seem to be in the library yet. If it's really faster, shouldn't it be included even if there's still room for improvement? I'll run a few benchmarks in the next days. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 18 22:46:43 2009 From: trac at galois.com (GHC) Date: Wed Nov 18 22:22:07 2009 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types Message-ID: <046.c71a4f69a48e7e64e18a56e29c643e03@localhost> #3676: realToFrac doesn't sanely convert between floating types ---------------------------------+------------------------------------------ Reporter: draconx | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown ---------------------------------+------------------------------------------ As far as I can tell, the only way to convert between floating types in Haskell is to use realToFrac. Unfortunately, this function does some insane mangling of values when converting. Some examples: realToFrac (0/0 :: Double) :: Double --> -Infinity realToFrac (-1/0 :: Float) :: Double --> -3.402823669209385e38 realToFrac (-0 :: Double) :: CDouble --> 0.0 The last item illustrates an important point: it is impossible to convert a value from Double to CDouble without potentially changing it. This makes it difficult or impossible to use the FFI to call any functions with floating point parameters/return values. Using a combination of unsafeCoerce (to shoehorn Double values in/out of CDoubles) and some functions written in C (to perform float<=>double), I was able to work around these problems, but that hardly seems like a nice solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 02:27:33 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 02:02:56 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF Message-ID: <043.bc40a075329f7b63a53340629e65db0f@localhost> #3677: Optimizer creates stack overflow on filtered CAF ------------------------+--------------------------------------------------- Reporter: jpet | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Windows | Testcase: Architecture: x86 | Failure: Runtime crash ------------------------+--------------------------------------------------- The following code creates a stack overflow at -O1 or -O2, when running with a moderately small stack (+RTS -K94k): import Data.Bits hmm :: [Integer] hmm = filter (\n -> (n .&. (n-1))==0) [1..] main = mapM_ print hmm The lambda just picks out powers of two, so that filter will skip increasingly long subsequences. It's the filter causing the overflow. Changing hmm to [Int], or to be let-bound, or compiling with -O0 makes the overflow go away. Using a 95k stack also makes the overflow go away. (Below 95k, stack usage is linear with the length of the filtered-out subsequence; then it seems to cap out.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 05:45:08 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 05:20:32 2009 Subject: [GHC] #3662: Don't know how to install documentation In-Reply-To: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> References: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> Message-ID: <051.c6a026501a86657f5057bac4f6ba0c9b@localhost> #3662: Don't know how to install documentation ---------------------------+------------------------------------------------ Reporter: bos | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by simonmar): Don't we still have a problem with the missing man page? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 07:51:44 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 07:27:08 2009 Subject: [GHC] #344: arrow notation: incorrect scope of existential dictionaries In-Reply-To: <045.6fa4f20d0985206ecf8719537b5ca060@localhost> References: <045.6fa4f20d0985206ecf8719537b5ca060@localhost> Message-ID: <054.d9fb2920a092926c196aac76b534abe3@localhost> #344: arrow notation: incorrect scope of existential dictionaries --------------------------------------+------------------------------------- Reporter: nobody | Owner: ross Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.4 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * failure: => None/Unknown Comment: To summarise, here's the program that fails core lint: {{{ {-# OPTIONS -farrows -fglasgow-exts -dcore-lint #-} module GHCbug where class Foo a where foo :: a -> () data Bar = forall a. Foo a => Bar a get :: Bar -> () get = proc x -> case x of Bar a -> do {y <- id -< a; id -< foo a} }}} Still failing in 6.12.1 RC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 07:52:34 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 07:27:58 2009 Subject: [GHC] #344: arrow notation: incorrect scope of existential dictionaries In-Reply-To: <045.6fa4f20d0985206ecf8719537b5ca060@localhost> References: <045.6fa4f20d0985206ecf8719537b5ca060@localhost> Message-ID: <054.ba91ba8f98ccb70f58879a6641f86585@localhost> #344: arrow notation: incorrect scope of existential dictionaries --------------------------------------+------------------------------------- Reporter: nobody | Owner: ross Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.4 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Compile-time crash | --------------------------------------+------------------------------------- Changes (by simonmar): * failure: None/Unknown => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 07:52:54 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 07:28:19 2009 Subject: [GHC] #3662: Don't know how to install documentation In-Reply-To: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> References: <042.a3d4432de1e3ad05fa96dc260f8cb5c0@localhost> Message-ID: <051.ec603bcdbbafc61eb8ce21a2fa138114@localhost> #3662: Don't know how to install documentation ---------------------------+------------------------------------------------ Reporter: bos | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by igloo): I'll fix that -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 07:53:28 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 07:28:58 2009 Subject: [GHC] #345: GADT - fundep interaction In-Reply-To: <044.866b79c0737f483f2c81dc73ce22f084@localhost> References: <044.866b79c0737f483f2c81dc73ce22f084@localhost> Message-ID: <053.65413b3af9768618dd638373f254a46c@localhost> #345: GADT - fundep interaction ----------------------------------------+----------------------------------- Reporter: bring | Owner: simonpj Type: bug | Status: assigned Priority: low | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.4 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: gadt-fd | Architecture: Unknown/Multiple Failure: GHC rejects valid program | ----------------------------------------+----------------------------------- Changes (by simonmar): * failure: => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 11:28:40 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 11:04:04 2009 Subject: [GHC] #3650: Add a Natural number type to the pre-defined basic types. In-Reply-To: <044.8f2b020c1c43231e9e02b324d5f95775@localhost> References: <044.8f2b020c1c43231e9e02b324d5f95775@localhost> Message-ID: <053.8a4eed8808f7edc244d5bbfe9d0dfec7@localhost> #3650: Add a Natural number type to the pre-defined basic types. --------------------------------------+------------------------------------- Reporter: JohnD | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Resolution: wontfix | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => * resolution: => wontfix * failure: => None/Unknown Comment: A Natural type that doesn't need compiler support could be implemented in a standalone package, and doesn't need to be part of the compiler (although it could be proposed to become part of the base package in the future). If what you want needs compiler support, then it would probably be best to discuss the design on the cvs-ghc mailing list, or perhaps to make a wiki page describing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 11:31:02 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 11:06:24 2009 Subject: [GHC] #3653: "Missing header file: HsDirectory.h" with old kernel/glibc In-Reply-To: <045.922678c7ce1ad1539e29e51bb27ac78c@localhost> References: <045.922678c7ce1ad1539e29e51bb27ac78c@localhost> Message-ID: <054.eb2e52b6c104c3b80e14c178d64fa76b@localhost> #3653: "Missing header file: HsDirectory.h" with old kernel/glibc ----------------------------------+----------------------------------------- Reporter: roland | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries/directory | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: Fixed in HEAD: {{{ Thu Nov 19 04:29:51 PST 2009 Ian Lynagh * Include sys/types.h in HsDirectory.h; fixes trac #3653 }}} and 6.12: {{{ Thu Nov 19 07:50:42 PST 2009 Ian Lynagh * Update the directory library tarball This now includes the fix: Thu Nov 19 04:29:51 PST 2009 Ian Lynagh * Include sys/types.h in HsDirectory.h; fixes trac #3653 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 11:31:25 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 11:06:46 2009 Subject: [GHC] #3648: Release a new containers version In-Reply-To: <044.a62d7b1d53452135e5ca11272aa7e3e1@localhost> References: <044.a62d7b1d53452135e5ca11272aa7e3e1@localhost> Message-ID: <053.d52b44b124aebb3e28e0c5386c80965d@localhost> #3648: Release a new containers version ---------------------------+------------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: Fixed: {{{ Thu Nov 19 07:52:18 PST 2009 Ian Lynagh * Update the containers library tarball It now includes: Wed Oct 28 03:55:32 PDT 2009 Ross Paterson * doc bugfix: correct description of index argument }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 12:32:00 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 12:07:29 2009 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> References: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> Message-ID: <051.bbe79965fca430c4fc4b1b59ba84fc77@localhost> #2530: deriving Show adds extra parens for constructor with record syntax ---------------------------+------------------------------------------------ Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by spl): For reference, there have been a few responses on [http://www.haskell.org//pipermail/haskell- cafe/2009-November/thread.html#69382 this Caf? thread]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 12:52:07 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 12:27:42 2009 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@localhost> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@localhost> Message-ID: <055.a8f2762c2bc4161b3aeae97ecabbb40c@localhost> #367: Infinite loops can hang Concurrent Haskell ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: scheduler allocation Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by igloo): * failure: => Incorrect result at runtime -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 16:23:43 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 15:59:06 2009 Subject: [GHC] #3583: Default view patterns In-Reply-To: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> References: <042.09c0286c1bb4575dcdfed8f2d7712a89@localhost> Message-ID: <051.f39c4208be518a06ee27b983bf6152de@localhost> #3583: Default view patterns -----------------------------------------+---------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Comment (by NeilMitchell): There is a design for ViewPatterns using the (-> ...) syntax, which has not yet been implemented. There is not a design for implicit view patterns. How do you declare what becomes an implicit view pattern? Do you declare them with the pattern keyword? Can you export/import/qualify them? Can you have higher-order patterns? Do they interact with typing? Can you add guards to these patterns? Can you overload these implicit patterns? Lots of decisions need to be made before people get to the implementation stage, so this isn't really a fixable ticket. [I'm not asking to answers for all these questions - that's not really the point, I'm more illustrating that it's probably not at the stage where this can be "fixed". I suggest discussing the options on haskell-cafe@ for a good long time first, then trying to tempt a compiler hacker.] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 21:17:46 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 20:53:07 2009 Subject: [GHC] #3556: Build the bootstrapping ghc-pkg with ghc-cabal In-Reply-To: <044.67ca5f0d38da2c2c1eba80992f3ceec9@localhost> References: <044.67ca5f0d38da2c2c1eba80992f3ceec9@localhost> Message-ID: <053.02edb4a2cd292b08cc46b00e261970c8@localhost> #3556: Build the bootstrapping ghc-pkg with ghc-cabal ---------------------------+------------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.14.1 Component: Build System | Version: 6.11 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * priority: normal => high * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 21:28:17 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 21:03:39 2009 Subject: [GHC] #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts Message-ID: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts ---------------------------------+------------------------------------------ Reporter: pejo | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.13 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ Build.mk: {{{ # My build settings for hacking on stage 2 SRC_HC_OPTS = -H32m -O -fasm -Rghc-timing GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O0 -DDEBUG -Wall -fexpose-all-unfoldings GhcLibHcOpts = -O -fasm -XGenerics GhcLibWays = v SplitObjs = NO GhcBootLibs = YES HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO }}} The build error: {{{ "inplace/bin/ghc-cabal" configure --with-ghc="/Volumes/OSXSSD/ghc/ghc .full-unfoldings/inplace/bin/dummy-ghc" --with-ghc- pkg="/Volumes/OSXSSD/ghc/ghc.full-unfoldings/inplace/bin/ghc-pkg" --with- gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --flags=stage2 --flags=ncg --flags=ghci --ghc- option=-DGHCI_TABLES_NEXT_TO_CODE --ghc-option=-DSTAGE=2 --ghc- options='-O0 -DDEBUG -Wall -fexpose-all-unfoldings' --configure- option=CFLAGS=" -m32 " --configure-option=LDFLAGS=" " -- stage2 compiler Configuring ghc-6.13.20091119... Warning: 'include-dirs: ../libffi/build/include' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. Warning: 'include-dirs: ../libraries/base/cbits' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. Warning: 'include-dirs: ../libraries/base/include' is a relative path outside of the source tree. This will not work when generating a tarball with 'sdist'. Warning: 'hs-source-dirs: cprAnalysis' directory does not exist. ghc: unrecognised flags: -fexpose-all-unfoldings Usage: For basic information, try the `--help' option. make[1]: *** [compiler/stage2/package-data.mk] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 21:30:24 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 21:05:45 2009 Subject: [GHC] #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts In-Reply-To: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> References: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> Message-ID: <052.cc2f967c0917580639662cd50dabea2f@localhost> #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts ---------------------------------+------------------------------------------ Reporter: pejo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.13 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ Comment (by pejo): Igloo said I should also point to bug #3556. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 19 21:46:03 2009 From: trac at galois.com (GHC) Date: Thu Nov 19 21:21:27 2009 Subject: [GHC] #3661: Profiling GHC HEAD broken under OSX. In-Reply-To: <043.560ca39f817b07eb47a88350bdc7c055@localhost> References: <043.560ca39f817b07eb47a88350bdc7c055@localhost> Message-ID: <052.7ce0dd986b6b9f27befa482bd0d011d6@localhost> #3661: Profiling GHC HEAD broken under OSX. ---------------------------+------------------------------------------------ Reporter: pejo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.13 Resolution: fixed | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by pejo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: I'm no longer able to reproduce this bug under HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 01:50:23 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 01:25:43 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF In-Reply-To: <043.bc40a075329f7b63a53340629e65db0f@localhost> References: <043.bc40a075329f7b63a53340629e65db0f@localhost> Message-ID: <052.41861a585b3d086737da5cc87435cb5d@localhost> #3677: Optimizer creates stack overflow on filtered CAF -------------------------+-------------------------------------------------- Reporter: jpet | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Os: Windows | Testcase: Architecture: x86 | Failure: Runtime crash -------------------------+-------------------------------------------------- Comment (by jpet): An even simpler repro: {{{ x :: [Integer] x = filter (\n -> n `mod` 10000000 == 0) [0..] main = mapM_ print x }}} Interestingly, 94k seems to be the magic stack threshold again, and in all the other simple variations I tried. The reason I was using such a small stack in the first place was to try to narrow down the stack overflow in the attached program, which overflows even an 8M stack. I'm not sure if that program is crashing because of the same issue, but I notice that using a replacement 'filter' makes the overflow go away: {{{ filter' f (x:xs) = case (f x) of True -> x : (filter' f xs) False -> filter' f xs }}} As does compiling with -O0. So I suspect it is a variation on the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 04:33:32 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 04:08:55 2009 Subject: [GHC] #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts In-Reply-To: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> References: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> Message-ID: <052.c9c2ef2c9a44f5cee5fb839ab6cebbae@localhost> #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts ----------------------------------+----------------------------------------- Reporter: pejo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonpj): * difficulty: => Comment: I have no idea what is going on here. Ian do you? -fexpose-all- unfoldings is a brand new flag, and my commit message explicitly said I hadn't tested it. It's certainly an odd thing to do to compile stage2 with that flag. (The libraries, perhaps.) But I don't know why it should be unrecognised, unless the GHC that's being run here isn't the one in the inplace build tree. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 05:09:27 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 04:44:49 2009 Subject: [GHC] #1434: Slow conversion from Double to Int In-Reply-To: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> References: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> Message-ID: <073.27e60a82c8d20b8aa44c52f88ce01c75@localhost> #1434: Slow conversion from Double to Int ----------------------------------------+----------------------------------- Reporter: ghc@henning-thielemann.de | Owner: dons Type: task | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.4.1 Resolution: | Keywords: rules Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | ----------------------------------------+----------------------------------- Changes (by simonmar): * failure: => Runtime performance bug * os: Linux => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 07:48:40 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 07:23:58 2009 Subject: [GHC] #3556: Build the bootstrapping ghc-pkg with ghc-cabal In-Reply-To: <044.67ca5f0d38da2c2c1eba80992f3ceec9@localhost> References: <044.67ca5f0d38da2c2c1eba80992f3ceec9@localhost> Message-ID: <053.8956c297942d8633215cc1706e3fabb0@localhost> #3556: Build the bootstrapping ghc-pkg with ghc-cabal ---------------------------+------------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.14.1 Component: Build System | Version: 6.11 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by igloo): See also #3678 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 07:50:07 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 07:25:26 2009 Subject: [GHC] #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts In-Reply-To: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> References: <043.e2ab445e857a0d9778b3347a024af8d1@localhost> Message-ID: <052.7fae12d5e4468cfe586403fe899c3e83@localhost> #3678: Build fails when adding -fexpose-all-unfoldings to GhcStage2HcOpts ----------------------------------+----------------------------------------- Reporter: pejo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Build System | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * priority: normal => high * milestone: => 6.14.1 Comment: Yes; the problem is that when configuring the package, we use `dummy-ghc`, which is more-or-less the bootstrapping compiler. I think we should rejig the build system so that `dummy-ghc` isn't used. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 12:18:59 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 11:54:49 2009 Subject: [GHC] #3679: ghc: panic! (the 'impossible' happened) Message-ID: <045.a31c5e09104888542891e34602423108@localhost> #3679: ghc: panic! (the 'impossible' happened) -------------------------------+-------------------------------------------- Reporter: elkner | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Solaris | Testcase: Architecture: x86_64 (amd64) | Failure: Building GHC failed -------------------------------+-------------------------------------------- SunOS q 5.11 snv_126 i86pc i386 i86pc ./configure --prefix=/opt \ --disable-static \ --disable-rpath \ --enable-shared \ --with-ghc=$ROOT4BUILD/opt/bin/ghc \ --with-gmp-includes=/usr/include/gmp \ --with-gmp-libraries=/usr/lib/${ARCH_DIR} gmake all | tee $MAKELOG ... /export/scratch/elkner/build/ghc-6.10.4/ghc-6.10.4/ghc/stage1-inplace/ghc -H32m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -I/usr/include/gmp -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -hisuf dyn_hi -hcsuf dyn_hc -osuf dyn_o -fPIC -dynamic -c Apply.cmm -o Apply.dyn_o ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-solaris2): howToAccessLabel: PIC not defined for this platform Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug gmake[2]: *** [Apply.dyn_o] Error 1 gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory `/export/scratch/elkner/build/ghc-6.10.4/ghc-6.10.4/rts' gmake: *** [stage1] Error 2 Skipping package make 432.09u 41.84s 9:58.28 79.2% -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 13:19:23 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 12:54:42 2009 Subject: [GHC] #3591: A working program reports <> when compiled with -O In-Reply-To: <047.0475174377feb22d7d802e2794561872@localhost> References: <047.0475174377feb22d7d802e2794561872@localhost> Message-ID: <056.7f0e0b7b5d9d8377430ad05fd965c7eb@localhost> #3591: A working program reports <> when compiled with -O ---------------------------+------------------------------------------------ Reporter: blamario | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 14:02:51 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 13:38:12 2009 Subject: [GHC] #3601: When running two or more instances of GHCi, persistent history is only kept for the first one In-Reply-To: <044.3e95c237b5aba9c3bbec0ec0c9a5aaba@localhost> References: <044.3e95c237b5aba9c3bbec0ec0c9a5aaba@localhost> Message-ID: <053.46ea491e6440e97f0941cae5a1a3e492@localhost> #3601: When running two or more instances of GHCi, persistent history is only kept for the first one ------------------------------+--------------------------------------------- Reporter: arnar | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.10.4 Resolution: | Keywords: ghci history Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Other | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => * type: bug => feature request * failure: => Other * milestone: => _|_ Comment: Thanks for the suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 14:18:46 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 13:54:06 2009 Subject: [GHC] #3632: lift restrictions on records with existential fields, especially in the presence of class constraints In-Reply-To: <047.bdd2c439db336bced650a9d8503aba8e@localhost> References: <047.bdd2c439db336bced650a9d8503aba8e@localhost> Message-ID: <056.bba902cc922f9ad3f0d1f46e38c3c268@localhost> #3632: lift restrictions on records with existential fields, especially in the presence of class constraints ------------------------------+--------------------------------------------- Reporter: eflister | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: existential records accessor update Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:03:02 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 14:38:34 2009 Subject: [GHC] #3633: Heap size suggestion of > 2145 MB gets ignored In-Reply-To: <042.715300f691a60275dfa2a5a83e344a71@localhost> References: <042.715300f691a60275dfa2a5a83e344a71@localhost> Message-ID: <051.0165d8c566814d74fba5f0c79f54e924@localhost> #3633: Heap size suggestion of > 2145 MB gets ignored -----------------------------+---------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => * failure: => None/Unknown * milestone: => 6.12 branch Comment: I'm not sure if a single process will be able to use more than 2G RAM, but either way I don't think we should be silently ignoring the flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:11:21 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 14:46:38 2009 Subject: [GHC] #3638: Redundant signature required with RULES and GADTs In-Reply-To: <041.a5ceb666d94c0fd232b5a23718e1981c@localhost> References: <041.a5ceb666d94c0fd232b5a23718e1981c@localhost> Message-ID: <050.7bf5fcb3c6b18980abc34e79e8a1f584@localhost> #3638: Redundant signature required with RULES and GADTs --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Type checker) | Version: 6.13 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:11:50 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 14:47:08 2009 Subject: [GHC] #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? In-Reply-To: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> References: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> Message-ID: <055.94d416f3063bd4e79fcb79cf715694ae@localhost> #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? ---------------------------+------------------------------------------------ Reporter: Aviator | Owner: judah Type: bug | Status: assigned Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => * failure: => None/Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:23:16 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 14:58:35 2009 Subject: [GHC] #3591: A working program reports <> when compiled with -O In-Reply-To: <047.0475174377feb22d7d802e2794561872@localhost> References: <047.0475174377feb22d7d802e2794561872@localhost> Message-ID: <056.2bff77e62660127da2d5c12a51e8ec25@localhost> #3591: A working program reports <> when compiled with -O -----------------------------------------+---------------------------------- Reporter: blamario | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: simplCore/should_run/T3591 | Architecture: x86_64 (amd64) Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by simonpj): * testcase: => simplCore/should_run/T3591 * owner: simonpj => igloo * type: bug => merge Comment: Oh! I fixed this one a month ago {{{ Fri Oct 23 17:15:51 GMT Daylight Time 2009 simonpj@microsoft.com * Fix Trac #3591: very tricky specialiser bug There was a subtle bug in the interation of specialisation and floating, described in Note [Specialisation of dictionary functions]. The net effect was to create a loop where none existed before; plain wrong. In fixing it, I did quite a bit of house-cleaning in the specialiser, and added a lot more comments. It's tricky, alas. M ./compiler/basicTypes/Id.lhs -1 +6 M ./compiler/specialise/Specialise.lhs -173 +301 }}} And added a regression test. Ian, if this isn't in 6.12 it probably should be Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:29:15 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 15:04:32 2009 Subject: [GHC] #3591: A working program reports <> when compiled with -O In-Reply-To: <047.0475174377feb22d7d802e2794561872@localhost> References: <047.0475174377feb22d7d802e2794561872@localhost> Message-ID: <056.161a1cd279672a1d8d5689d9520dbc78@localhost> #3591: A working program reports <> when compiled with -O -----------------------------------------+---------------------------------- Reporter: blamario | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Linux Testcase: simplCore/should_run/T3591 | Architecture: x86_64 (amd64) Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Aha, yes, it's already merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:31:33 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 15:06:51 2009 Subject: [GHC] #3649: inconsistent exception between unix/windows for running non-existant program In-Reply-To: <045.38ca9e41e1ac2553ec6a5c6c46307813@localhost> References: <045.38ca9e41e1ac2553ec6a5c6c46307813@localhost> Message-ID: <054.13422b744473fbf7980191b7ac778381@localhost> #3649: inconsistent exception between unix/windows for running non-existant program --------------------------------+------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/process | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * difficulty: => * failure: => None/Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:35:52 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 15:11:11 2009 Subject: [GHC] #3651: GADT type checking too liberal In-Reply-To: <060.8d4fb310d54f3275d8ff7d8a2f64996f@localhost> References: <060.8d4fb310d54f3275d8ff7d8a2f64996f@localhost> Message-ID: <069.aeaf3a13a8bff883a8287ea77807cad4@localhost> #3651: GADT type checking too liberal --------------------------------------+------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (Type checker) | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * difficulty: => * failure: => None/Unknown * milestone: => 6.14.1 Comment: These are all accepted in 6.12 and HEAD too, but trying to call any of them with arguments B and U fails: {{{ Couldn't match expected type `Bool' against inferred type `()' }}} I'm not sure if that's the expected behaviour or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:36:59 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 15:12:33 2009 Subject: [GHC] #3652: Gettting error while running configure In-Reply-To: <045.eff9bb915ab699f8c1f45362bb86aacf@localhost> References: <045.eff9bb915ab699f8c1f45362bb86aacf@localhost> Message-ID: <054.76fa140a74dfff99563caface3eac2df@localhost> #3652: Gettting error while running configure ---------------------------+------------------------------------------------ Reporter: cheram | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => * failure: => None/Unknown Old description: > HI, > > While i run the configure i am getting the following error. > > Please suggest me how to overcome. > > x86_32/bin:/arm/tools/arm/lyra-pkg/2.01/common:/arm/tools/arm/depot- > build/2.01/common/bin:/arm/tools/arm/depot- > build/2.01/rhe4-x86_32/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking target system type... i686-pc-linux-gnu > Which we'll further canonicalise into: i386-unknown-linux > checking for path to top of build tree... pwd: timer_create: Invalid > argument > configure: error: cannot determine current directory > tmk: child process exited abnormally > tmk: tmk: exiting. > tmk: exiting. > while executing > "error "${::__OutputPrefix} exiting."" > invoked from within > "if $::__DbgLevel { > > Thanks, > Chetan New description: HI, While i run the configure i am getting the following error. Please suggest me how to overcome. {{{ x86_32/bin:/arm/tools/arm/lyra-pkg/2.01/common:/arm/tools/arm/depot- build/2.01/common/bin:/arm/tools/arm/depot- build/2.01/rhe4-x86_32/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Which we'll further canonicalise into: i386-unknown-linux checking for path to top of build tree... pwd: timer_create: Invalid argument configure: error: cannot determine current directory tmk: child process exited abnormally tmk: tmk: exiting. tmk: exiting. while executing "error "${::__OutputPrefix} exiting."" invoked from within "if $::__DbgLevel { }}} Thanks, Chetan -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:45:44 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 15:21:16 2009 Subject: [GHC] #3652: Gettting error while running configure In-Reply-To: <045.eff9bb915ab699f8c1f45362bb86aacf@localhost> References: <045.eff9bb915ab699f8c1f45362bb86aacf@localhost> Message-ID: <054.2a647c8b8097091dc1ac549dc29d6a82@localhost> #3652: Gettting error while running configure ---------------------------+------------------------------------------------ Reporter: cheram | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Resolution: invalid | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => invalid Comment: It looks like you are trying to install a binary distribution, but your kernel or libc are too old for the binaries it contains. You'll need to either build GHC from source, or use a binary designed for your system (e.g. your Linux distribution might provide GHC binaries). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:56:44 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 15:32:04 2009 Subject: [GHC] #3657: ffi-1.0 causes panic in 6.12.20091010 In-Reply-To: <045.b9b668a0e35a678f68b5b35dd98d4aba@localhost> References: <045.b9b668a0e35a678f68b5b35dd98d4aba@localhost> Message-ID: <054.bae365f52f535355a4d04242e813d8e1@localhost> #3657: ffi-1.0 causes panic in 6.12.20091010 ---------------------------+------------------------------------------------ Reporter: tobsan | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => * failure: => None/Unknown * milestone: => 6.12.1 Comment: Thanks for the report. Unfortunately, I can't reproduce this. Did you build GHC yourself, or use one of the binary downloads? Do you have any idea of anything special about your system that might give a clue as to the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:58:31 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 15:34:00 2009 Subject: [GHC] #3671: Add partitioning functions to Data.List In-Reply-To: <047.97ceba79bfaf5cc5b24cb90720e1b14e@localhost> References: <047.97ceba79bfaf5cc5b24cb90720e1b14e@localhost> Message-ID: <056.14c5f93ff9d22406a26c8f8456237cfc@localhost> #3671: Add partitioning functions to Data.List -----------------------------+---------------------------------------------- Reporter: holzensp | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.12.1 RC1 Resolution: | Keywords: Data.List Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 15:59:17 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 15:34:37 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.a83dd53505437e9a19244197ca0c8948@localhost> #3668: PIE-enabled hardened gcc might broke GHC. ---------------------------+------------------------------------------------ Reporter: secludedsage | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => * failure: => None/Unknown Old description: > emerge --info: > Portage 2.1.7.4 (hardened/linux/x86/10.0/desktop, gcc-4.3.4, > glibc-2.10.1-r0, 2.6.31-11-generic i686) > ================================================================= > System uname: Linux-2.6.31-11-generic-i686-Genuine_Intel-R-_CPU_T2050_@_1 > .60GHz-with-gentoo-2.0.1 > Timestamp of tree: Sat, 14 Nov 2009 05:45:01 +0000 > app-shells/bash: 4.0_p35 > dev-lang/python: 2.6.4, 3.1.1-r1 > sys-apps/baselayout: 2.0.1 > sys-apps/openrc: 0.5.2-r1 > sys-apps/sandbox: 2.2 > sys-devel/autoconf: 2.63-r1 > sys-devel/automake: 1.9.6-r2, 1.10.2, 1.11 > sys-devel/binutils: 2.20 > sys-devel/gcc-config: 1.4.1 > sys-devel/libtool: 2.2.6a > virtual/os-headers: 2.6.30-r1 > CBUILD="i686-pc-linux-gnu" > CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" > CHOST="i686-pc-linux-gnu" > CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" > LDFLAGS="-Wl,-O1 -Wl,--as-needed" > LINGUAS="*" > MAKEOPTS="-j3" > > While I am building yi-editor, I get: > Building yi-0.6.1... > [ 1 of 119] Compiling System.FriendlyPath ( System/FriendlyPath.hs, > dist/build/System/FriendlyPath.o ) > [ 2 of 119] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs, > dist/build/Shim/ProjectContent.o ) > [ 3 of 119] Compiling Parser.Incremental ( Parser/Incremental.hs, > dist/build/Parser/Incremental.o ) > [ 4 of 119] Compiling Data.Trie ( Data/Trie.hs, > dist/build/Data/Trie.o > ) > [ 5 of 119] Compiling Data.DelayList ( Data/DelayList.hs, > dist/build/Data/DelayList.o ) > [ 6 of 119] Compiling Data.Rope ( Data/Rope.hs, > dist/build/Data/Rope.o > ) > [ 7 of 119] Compiling Data.Prototype ( Data/Prototype.hs, > dist/build/Data/Prototype.o ) > [ 8 of 119] Compiling HConf.Utils ( HConf/Utils.hs, > dist/build/HConf/Utils.o ) > [ 9 of 119] Compiling HConf.Paths ( HConf/Paths.hs, > dist/build/HConf/Paths.o ) > [ 10 of 119] Compiling Paths_yi ( dist/build/autogen/Paths_yi.hs, > dist/build/Paths_yi.o ) > [ 11 of 119] Compiling HConf ( HConf.hs, dist/build/HConf.o ) > [ 12 of 119] Compiling Yi.Char.Unicode ( Yi/Char/Unicode.hs, > dist/build/Yi/Char/Unicode.o ) > [ 13 of 119] Compiling Yi.UI.Common[boot] ( Yi/UI/Common.hs-boot, > dist/build/Yi/UI/Common.o-boot ) > [ 14 of 119] Compiling Yi.String ( Yi/String.hs, > dist/build/Yi/String.o > ) > [ 15 of 119] Compiling Yi.Monad ( Yi/Monad.hs, > dist/build/Yi/Monad.o ) > [ 16 of 119] Compiling Yi.Keymap.Completion ( Yi/Keymap/Completion.hs, > dist/build/Yi/Keymap/Completion.o ) > [ 17 of 119] Compiling Yi.Editor[boot] ( Yi/Editor.hs-boot, > dist/build/Yi/Editor.o-boot ) > [ 18 of 119] Compiling Yi.Debug ( Yi/Debug.hs, > dist/build/Yi/Debug.o ) > [ 19 of 119] Compiling Yi.Prelude ( Yi/Prelude.hs, > dist/build/Yi/Prelude.o ) > [ 20 of 119] Compiling Yi.Dynamic ( Yi/Dynamic.hs, > dist/build/Yi/Dynamic.o ) > [ 21 of 119] Compiling Yi.Event ( Yi/Event.hs, > dist/build/Yi/Event.o ) > [ 22 of 119] Compiling Yi.Interact ( Yi/Interact.hs, > dist/build/Yi/Interact.o ) > [ 23 of 119] Compiling Yi.Keymap[boot] ( Yi/Keymap.hs-boot, > dist/build/Yi/Keymap.o-boot ) > [ 24 of 119] Compiling Yi.Style ( Yi/Style.hs, > dist/build/Yi/Style.o ) > [ 25 of 119] Compiling Yi.Style.Library ( Yi/Style/Library.hs, > dist/build/Yi/Style/Library.o ) > [ 26 of 119] Compiling Yi.Interpreter ( Yi/Interpreter.hs, > dist/build/Yi/Interpreter.o ) > [ 27 of 119] Compiling Shim.Utils ( Shim/Utils.hs, > dist/build/Shim/Utils.o ) > [ 28 of 119] Compiling Shim.CabalInfo ( Shim/CabalInfo.hs, > dist/build/Shim/CabalInfo.o ) > [ 29 of 119] Compiling Yi.Buffer.Misc[boot] ( Yi/Buffer/Misc.hs-boot, > dist/build/Yi/Buffer/Misc.o-boot ) > [ 30 of 119] Compiling Yi.Buffer.Basic ( Yi/Buffer/Basic.hs, > dist/build/Yi/Buffer/Basic.o ) > ghc: /usr/lib/ghc-6.10.4/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o: unknown > symbol > `_GLOBAL_OFFSET_TABLE_' > Loading package ghc-prim ... linking ... ghc: unable to load package > `ghc-prim' > > mk/build.mk: > # Gentoo changes > docdir = /usr/share/doc/ghc-6.10.4 > htmldir = /usr/share/doc/ghc-6.10.4 > SRC_HC_OPTS+= -optc-march=native -opta-march=native -optc-nopie -optl- > nopie -optc-fno-PIE -opta-Wa,--noexecstack > SRC_CC_OPTS+=-O2 -march=native -pipe -nopie -Wa,--noexecstack > XMLDocWays= > HADDOCK_DOCS=NO > SRC_HC_OPTS+=-w New description: {{{ emerge --info: Portage 2.1.7.4 (hardened/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.10.1-r0, 2.6.31-11-generic i686) ================================================================= System uname: Linux-2.6.31-11-generic-i686-Genuine_Intel-R-_CPU_T2050_@_1 .60GHz-with-gentoo-2.0.1 Timestamp of tree: Sat, 14 Nov 2009 05:45:01 +0000 app-shells/bash: 4.0_p35 dev-lang/python: 2.6.4, 3.1.1-r1 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.5.2-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.30-r1 CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="*" MAKEOPTS="-j3" }}} While I am building yi-editor, I get: {{{ Building yi-0.6.1... [ 1 of 119] Compiling System.FriendlyPath ( System/FriendlyPath.hs, dist/build/System/FriendlyPath.o ) [ 2 of 119] Compiling Shim.ProjectContent ( Shim/ProjectContent.hs, dist/build/Shim/ProjectContent.o ) [ 3 of 119] Compiling Parser.Incremental ( Parser/Incremental.hs, dist/build/Parser/Incremental.o ) [ 4 of 119] Compiling Data.Trie ( Data/Trie.hs, dist/build/Data/Trie.o ) [ 5 of 119] Compiling Data.DelayList ( Data/DelayList.hs, dist/build/Data/DelayList.o ) [ 6 of 119] Compiling Data.Rope ( Data/Rope.hs, dist/build/Data/Rope.o ) [ 7 of 119] Compiling Data.Prototype ( Data/Prototype.hs, dist/build/Data/Prototype.o ) [ 8 of 119] Compiling HConf.Utils ( HConf/Utils.hs, dist/build/HConf/Utils.o ) [ 9 of 119] Compiling HConf.Paths ( HConf/Paths.hs, dist/build/HConf/Paths.o ) [ 10 of 119] Compiling Paths_yi ( dist/build/autogen/Paths_yi.hs, dist/build/Paths_yi.o ) [ 11 of 119] Compiling HConf ( HConf.hs, dist/build/HConf.o ) [ 12 of 119] Compiling Yi.Char.Unicode ( Yi/Char/Unicode.hs, dist/build/Yi/Char/Unicode.o ) [ 13 of 119] Compiling Yi.UI.Common[boot] ( Yi/UI/Common.hs-boot, dist/build/Yi/UI/Common.o-boot ) [ 14 of 119] Compiling Yi.String ( Yi/String.hs, dist/build/Yi/String.o ) [ 15 of 119] Compiling Yi.Monad ( Yi/Monad.hs, dist/build/Yi/Monad.o ) [ 16 of 119] Compiling Yi.Keymap.Completion ( Yi/Keymap/Completion.hs, dist/build/Yi/Keymap/Completion.o ) [ 17 of 119] Compiling Yi.Editor[boot] ( Yi/Editor.hs-boot, dist/build/Yi/Editor.o-boot ) [ 18 of 119] Compiling Yi.Debug ( Yi/Debug.hs, dist/build/Yi/Debug.o ) [ 19 of 119] Compiling Yi.Prelude ( Yi/Prelude.hs, dist/build/Yi/Prelude.o ) [ 20 of 119] Compiling Yi.Dynamic ( Yi/Dynamic.hs, dist/build/Yi/Dynamic.o ) [ 21 of 119] Compiling Yi.Event ( Yi/Event.hs, dist/build/Yi/Event.o ) [ 22 of 119] Compiling Yi.Interact ( Yi/Interact.hs, dist/build/Yi/Interact.o ) [ 23 of 119] Compiling Yi.Keymap[boot] ( Yi/Keymap.hs-boot, dist/build/Yi/Keymap.o-boot ) [ 24 of 119] Compiling Yi.Style ( Yi/Style.hs, dist/build/Yi/Style.o ) [ 25 of 119] Compiling Yi.Style.Library ( Yi/Style/Library.hs, dist/build/Yi/Style/Library.o ) [ 26 of 119] Compiling Yi.Interpreter ( Yi/Interpreter.hs, dist/build/Yi/Interpreter.o ) [ 27 of 119] Compiling Shim.Utils ( Shim/Utils.hs, dist/build/Shim/Utils.o ) [ 28 of 119] Compiling Shim.CabalInfo ( Shim/CabalInfo.hs, dist/build/Shim/CabalInfo.o ) [ 29 of 119] Compiling Yi.Buffer.Misc[boot] ( Yi/Buffer/Misc.hs-boot, dist/build/Yi/Buffer/Misc.o-boot ) [ 30 of 119] Compiling Yi.Buffer.Basic ( Yi/Buffer/Basic.hs, dist/build/Yi/Buffer/Basic.o ) ghc: /usr/lib/ghc-6.10.4/ghc-prim-0.1.0.0/HSghc-prim-0.1.0.0.o: unknown symbol `_GLOBAL_OFFSET_TABLE_' Loading package ghc-prim ... linking ... ghc: unable to load package `ghc- prim' }}} mk/build.mk: {{{ # Gentoo changes docdir = /usr/share/doc/ghc-6.10.4 htmldir = /usr/share/doc/ghc-6.10.4 SRC_HC_OPTS+= -optc-march=native -opta-march=native -optc-nopie -optl- nopie -optc-fno-PIE -opta-Wa,--noexecstack SRC_CC_OPTS+=-O2 -march=native -pipe -nopie -Wa,--noexecstack XMLDocWays= HADDOCK_DOCS=NO SRC_HC_OPTS+=-w }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 16:04:55 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 15:40:13 2009 Subject: [GHC] #3657: ffi-1.0 causes panic in 6.12.20091010 In-Reply-To: <045.b9b668a0e35a678f68b5b35dd98d4aba@localhost> References: <045.b9b668a0e35a678f68b5b35dd98d4aba@localhost> Message-ID: <054.311bc85433c815d4959998cbcc3f898e@localhost> #3657: ffi-1.0 causes panic in 6.12.20091010 ---------------------------+------------------------------------------------ Reporter: tobsan | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by tobsan): This was built by myself, sort of. I emerged it on gentoo. [[BR]] The only peculiar USE flag used was ghcbootstrap, which was needed in order for GHC to build at all. Maybe this is a gentoo-specific bug, and in that case I have already spoken to the guys maintaining gentoo-haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 16:08:56 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 15:44:15 2009 Subject: [GHC] #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) In-Reply-To: <045.0f6b0943402daeb82291512e1fe74507@localhost> References: <045.0f6b0943402daeb82291512e1fe74507@localhost> Message-ID: <054.cc527361ac0d17b6cde433a33a0f35a1@localhost> #3664: Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate) -------------------------------------------+-------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Changes (by igloo): * difficulty: => * failure: => Compile-time performance bug * milestone: => 6.12 branch Comment: Thanks for the report. Is this a regression since 6.10? That PHP module includes a couple of 50000 character lines, mostly composed of a list of strings. I suspect that's the problem, but haven't profiled at all. It would be useful if someone could make a standalone, minimal testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 16:31:57 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 16:07:16 2009 Subject: [GHC] #17: Separate warnings for unused local and top-level bindings In-Reply-To: <047.fe4cdb312b5d86f34d27df1115f2c91a@localhost> References: <047.fe4cdb312b5d86f34d27df1115f2c91a@localhost> Message-ID: <056.695b135eb9d86ae36b910fb8a04b2678@localhost> #17: Separate warnings for unused local and top-level bindings ------------------------------+--------------------------------------------- Reporter: magunter | Owner: Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: -fwarn-unused-binds Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by igloo): Replying to [comment:10 byorgey]: > Would any developers care to guess at the difficulty of this feature? Could this make a good project for someone just starting to get their feet wet hacking on ghc? I'd say so. It would probably be worth discussing the design on the cvs- ghc list first, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 16:52:38 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 16:27:56 2009 Subject: [GHC] #3656: ghci leaves /tmp/ghc* directory if killed by signal In-Reply-To: <042.d95f8802b8c0b09855d12a49e63b7a91@localhost> References: <042.d95f8802b8c0b09855d12a49e63b7a91@localhost> Message-ID: <051.5177821af89d903607911d63b472616e@localhost> #3656: ghci leaves /tmp/ghc* directory if killed by signal ---------------------------+------------------------------------------------ Reporter: vvv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => * failure: => None/Unknown * milestone: => 6.12.2 Comment: Thanks for the report. I'm not quite sure what's going on here. After killing GHC, if I hit enter in the terminal then I get a {{{ : hWaitForInput: hardware fault (Input/output error) }}} exception, after which the directory is deleted. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 16:56:39 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 16:32:20 2009 Subject: [GHC] #3679: ghc: panic! (the 'impossible' happened) In-Reply-To: <045.a31c5e09104888542891e34602423108@localhost> References: <045.a31c5e09104888542891e34602423108@localhost> Message-ID: <054.ee9d83eaa5b087bd31671c711b4effdf@localhost> #3679: ghc: panic! (the 'impossible' happened) ----------------------------------+----------------------------------------- Reporter: elkner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: x86_64 (amd64) Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Old description: > SunOS q 5.11 snv_126 i86pc i386 i86pc > > ./configure --prefix=/opt \ > --disable-static \ > --disable-rpath \ > --enable-shared \ > --with-ghc=$ROOT4BUILD/opt/bin/ghc \ > --with-gmp-includes=/usr/include/gmp \ > --with-gmp-libraries=/usr/lib/${ARCH_DIR} > > gmake all | tee $MAKELOG > > ... > /export/scratch/elkner/build/ghc-6.10.4/ghc-6.10.4/ghc/stage1-inplace/ghc > -H32m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS > -package-name rts -I/usr/include/gmp -I../gmp/gmpbuild > -I../libffi/build/include -I. -dcmm-lint -hisuf dyn_hi -hcsuf dyn_hc > -osuf dyn_o -fPIC -dynamic -c Apply.cmm -o Apply.dyn_o > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.4 for i386-unknown-solaris2): > howToAccessLabel: PIC not defined for this platform > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > gmake[2]: *** [Apply.dyn_o] Error 1 > gmake[1]: *** [all] Error 1 > gmake[1]: Leaving directory > `/export/scratch/elkner/build/ghc-6.10.4/ghc-6.10.4/rts' > gmake: *** [stage1] Error 2 > Skipping package make > 432.09u 41.84s 9:58.28 79.2% New description: {{{ SunOS q 5.11 snv_126 i86pc i386 i86pc ./configure --prefix=/opt \ --disable-static \ --disable-rpath \ --enable-shared \ --with-ghc=$ROOT4BUILD/opt/bin/ghc \ --with-gmp-includes=/usr/include/gmp \ --with-gmp-libraries=/usr/lib/${ARCH_DIR} gmake all | tee $MAKELOG ... /export/scratch/elkner/build/ghc-6.10.4/ghc-6.10.4/ghc/stage1-inplace/ghc -H32m -O -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -I/usr/include/gmp -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -hisuf dyn_hi -hcsuf dyn_hc -osuf dyn_o -fPIC -dynamic -c Apply.cmm -o Apply.dyn_o ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-solaris2): howToAccessLabel: PIC not defined for this platform Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug gmake[2]: *** [Apply.dyn_o] Error 1 gmake[1]: *** [all] Error 1 gmake[1]: Leaving directory `/export/scratch/elkner/build/ghc-6.10.4/ghc-6.10.4/rts' gmake: *** [stage1] Error 2 Skipping package make 432.09u 41.84s 9:58.28 79.2% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 16:59:58 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 16:35:17 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF In-Reply-To: <043.bc40a075329f7b63a53340629e65db0f@localhost> References: <043.bc40a075329f7b63a53340629e65db0f@localhost> Message-ID: <052.077deed055e9ca6d334dd17434018e01@localhost> #3677: Optimizer creates stack overflow on filtered CAF ----------------------------+----------------------------------------------- Reporter: jpet | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Old description: > The following code creates a stack overflow at -O1 or -O2, when running > with a moderately small stack (+RTS -K94k): > > import Data.Bits > hmm :: [Integer] > hmm = filter (\n -> (n .&. (n-1))==0) [1..] > main = mapM_ print hmm > > The lambda just picks out powers of two, so that filter will skip > increasingly long subsequences. It's the filter causing the overflow. > > Changing hmm to [Int], or to be let-bound, or compiling with -O0 makes > the overflow go away. Using a 95k stack also makes the overflow go away. > (Below 95k, stack usage is linear with the length of the filtered-out > subsequence; then it seems to cap out.) New description: The following code creates a stack overflow at -O1 or -O2, when running with a moderately small stack (+RTS -K94k): {{{ import Data.Bits hmm :: [Integer] hmm = filter (\n -> (n .&. (n-1))==0) [1..] main = mapM_ print hmm }}} The lambda just picks out powers of two, so that filter will skip increasingly long subsequences. It's the filter causing the overflow. Changing hmm to [Int], or to be let-bound, or compiling with -O0 makes the overflow go away. Using a 95k stack also makes the overflow go away. (Below 95k, stack usage is linear with the length of the filtered-out subsequence; then it seems to cap out.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 17:01:31 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 16:36:50 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF In-Reply-To: <043.bc40a075329f7b63a53340629e65db0f@localhost> References: <043.bc40a075329f7b63a53340629e65db0f@localhost> Message-ID: <052.6a6b70520eca1b0254056ad3b44bc36f@localhost> #3677: Optimizer creates stack overflow on filtered CAF ----------------------------+----------------------------------------------- Reporter: jpet | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => 6.12 branch Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 17:01:42 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 16:37:01 2009 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@localhost> References: <046.c71a4f69a48e7e64e18a56e29c643e03@localhost> Message-ID: <055.68f0ec7091d9f7a150759ef76f9c2660@localhost> #3676: realToFrac doesn't sanely convert between floating types --------------------------------+------------------------------------------- Reporter: draconx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * difficulty: => Old description: > As far as I can tell, the only way to convert between floating types in > Haskell is to use realToFrac. Unfortunately, this function does some > insane mangling of values when converting. Some examples: > > realToFrac (0/0 :: Double) :: Double > --> -Infinity > realToFrac (-1/0 :: Float) :: Double > --> -3.402823669209385e38 > realToFrac (-0 :: Double) :: CDouble > --> 0.0 > > The last item illustrates an important point: it is impossible to > convert a value from Double to CDouble without potentially changing it. > This makes it difficult or impossible to use the FFI to call any > functions with floating point parameters/return values. > > Using a combination of unsafeCoerce (to shoehorn Double values in/out of > CDoubles) and some functions written in C (to perform float<=>double), I > was able to work around these problems, but that hardly seems like a nice > solution. New description: As far as I can tell, the only way to convert between floating types in Haskell is to use realToFrac. Unfortunately, this function does some insane mangling of values when converting. Some examples: {{{ realToFrac (0/0 :: Double) :: Double --> -Infinity realToFrac (-1/0 :: Float) :: Double --> -3.402823669209385e38 realToFrac (-0 :: Double) :: CDouble --> 0.0 }}} The last item illustrates an important point: it is impossible to convert a value from Double to CDouble without potentially changing it. This makes it difficult or impossible to use the FFI to call any functions with floating point parameters/return values. Using a combination of unsafeCoerce (to shoehorn Double values in/out of CDoubles) and some functions written in C (to perform float<=>double), I was able to work around these problems, but that hardly seems like a nice solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 17:09:57 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 16:45:19 2009 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@localhost> References: <046.c71a4f69a48e7e64e18a56e29c643e03@localhost> Message-ID: <055.fcae48040c9748a76b97fe1739f6988e@localhost> #3676: realToFrac doesn't sanely convert between floating types --------------------------------+------------------------------------------- Reporter: draconx | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * milestone: => 6.12.2 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 17:11:58 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 16:47:21 2009 Subject: [GHC] #3675: load fails with Literate target contents In-Reply-To: <059.e4fb807f52838bcaa82d8c96f6c3158a@localhost> References: <059.e4fb807f52838bcaa82d8c96f6c3158a@localhost> Message-ID: <068.778b3ede426448c9e1ef918a138da9ac@localhost> #3675: load fails with Literate target contents ------------------------------------------------+--------------------------- Reporter: JeanPhilippeMoresmau | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.10.4 Resolution: | Keywords: preprocess Literate Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Changes (by igloo): * difficulty: => Old description: > I am loading a target with actual contents (targetContents=Just > (contents, time)). The contents are literate Haskell. I get compilation > errors instead of the "preprocessing needed, interactive check disabled" > error I should get. It works if I manually set the Phase to Unlit > HsSrcFile, but the doc says it should guess it's literate from the file > extension. I'm using 6.10.4 in Windows.[[BR]] > > GHC.hs line 2240: [[BR]] > Nothing <- mb_phase, Unlit _ <- startPhase src_fn = True[[BR]] > > (src_fn is the file name, endings in .lhs in my case)[[BR]] > > DriverPhase.hs line 146:[[BR]] > startPhase "lhs" = Unlit HsSrcFile[[BR]] > > Somewhere in there we forgot to move from "/drive/dir/foo.lhs" to "lhs". > We need something like tail $ takeExtension $ src_fn, and handling > gracefully the case where there is no extension.[[BR]] > > I can try to actually code the patch, but I've never tried to build GHC > on my machine.... New description: I am loading a target with actual contents (targetContents=Just (contents, time)). The contents are literate Haskell. I get compilation errors instead of the "preprocessing needed, interactive check disabled" error I should get. It works if I manually set the Phase to Unlit `HsSrcFile`, but the doc says it should guess it's literate from the file extension. I'm using 6.10.4 in Windows. `GHC.hs` line 2240: {{{ Nothing <- mb_phase, Unlit _ <- startPhase src_fn = True[[BR]] }}} (src_fn is the file name, endings in .lhs in my case)[[BR]] `DriverPhase.hs` line 146: {{{ startPhase "lhs" = Unlit HsSrcFile[[BR]] }}} Somewhere in there we forgot to move from "/drive/dir/foo.lhs" to "lhs". We need something like tail $ takeExtension $ src_fn, and handling gracefully the case where there is no extension.[[BR]] I can try to actually code the patch, but I've never tried to build GHC on my machine.... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 17:13:24 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 16:48:41 2009 Subject: [GHC] #3675: load fails with Literate target contents In-Reply-To: <059.e4fb807f52838bcaa82d8c96f6c3158a@localhost> References: <059.e4fb807f52838bcaa82d8c96f6c3158a@localhost> Message-ID: <068.b9c5898c83a7f2a4764ea1dc9384bc02@localhost> #3675: load fails with Literate target contents ------------------------------------------------+--------------------------- Reporter: JeanPhilippeMoresmau | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHC API | Version: 6.10.4 Resolution: | Keywords: preprocess Literate Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Changes (by igloo): * milestone: => 6.14.1 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 17:16:59 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 16:52:17 2009 Subject: [GHC] #3672: Let Linker.c know about stg_arg_bitmaps In-Reply-To: <044.9478d419ceaff4352f148c46bb1abb99@localhost> References: <044.9478d419ceaff4352f148c46bb1abb99@localhost> Message-ID: <053.69714664fbf6503747d567d5de5533f8@localhost> #3672: Let Linker.c know about stg_arg_bitmaps ------------------------------+--------------------------------------------- Reporter: int-e | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.14.1 Component: Runtime System | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * priority: normal => high * milestone: => 6.14.1 Comment: Thanks for the report; we'll take a look at the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 18:07:07 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 17:42:25 2009 Subject: [GHC] #2984: Vectorized dph code doesn't terminate In-Reply-To: <042.776c42012cc46c4d8dc7e12433e5e6d8@localhost> References: <042.776c42012cc46c4d8dc7e12433e5e6d8@localhost> Message-ID: <051.3b4e38a4309f17c901c758b8b86edc3c@localhost> #2984: Vectorized dph code doesn't terminate ------------------------------------+--------------------------------------- Reporter: fre | Owner: rl Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Data Parallel Haskell | Version: 6.13 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------------+--------------------------------------- Changes (by rl): * status: new => closed * resolution: => fixed Comment: Works in the HEAD now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 18:25:18 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 18:00:36 2009 Subject: [GHC] #3184: package.conf should be under /var, not /usr In-Reply-To: <044.f476a4a28c9761f9c30b392c86475e98@localhost> References: <044.f476a4a28c9761f9c30b392c86475e98@localhost> Message-ID: <053.37e129c982d0bd4169e143e9436d2326@localhost> #3184: package.conf should be under /var, not /usr -----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Package system | Version: 6.10.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 Comment: punting -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 18:34:26 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 18:09:50 2009 Subject: [GHC] #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? In-Reply-To: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> References: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> Message-ID: <055.06e497e27cb9960a2dc3f03308c68f19@localhost> #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? ---------------------------+------------------------------------------------ Reporter: Aviator | Owner: judah Type: bug | Status: assigned Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by judahj): A few questions: Do arrow keys work with ghci in your terminal? If you run the following command in the shell, does it clear the screen? {{{ tput clear }}} If you run the following command, press the Home key, then press Return, what happens? {{{ ghc -e getLine }}} Finally, the haskeline library (which handles line-reading for ghci) has had several updates since ghc-6.10.4 was released. Can you confirm whether this problem still occurs with the most recent version of haskeline? The easiest way to test this is to run the following commands: {{{ cabal update && cabal install ghci-haskeline --constraint=haskeline==0.6.2.2 }}} which will build and install the `ghci-haskeline` executable, usually in `~/.cabal/bin`. Let me know if you have problems getting it working. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 19:43:06 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 19:18:27 2009 Subject: [GHC] #3280: The order of arguments to the function passed to nubBy got swapped somehow In-Reply-To: <044.3c8fa074464e1da7a1a920048af3ac0f@localhost> References: <044.3c8fa074464e1da7a1a920048af3ac0f@localhost> Message-ID: <053.3e92a07337e7b5a7805cfc74339b079f@localhost> #3280: The order of arguments to the function passed to nubBy got swapped somehow -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.3 Resolution: wontfix | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => wontfix Comment: My understanding is that `nub` and `nubBy` are currently consistent, so I'm closing this ticket. If you want to propose different behaviour, please see http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 19:45:37 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 19:20:55 2009 Subject: [GHC] #2034: In FilePath, current directory should be ".", not "" In-Reply-To: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost> References: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost> Message-ID: <053.0cba208b8d0120cb598b9140fd3c173b@localhost> #2034: In FilePath, current directory should be ".", not "" --------------------------------+------------------------------------------- Reporter: igloo | Owner: neil Type: proposal | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.8.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * failure: => None/Unknown Comment: See also #3276 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 20 19:46:32 2009 From: trac at galois.com (GHC) Date: Fri Nov 20 19:21:50 2009 Subject: [GHC] #3276: FilePath.addTrailingPathSeparator "" = "/" In-Reply-To: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> References: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> Message-ID: <054.74d44e495199c25fb250da868f9123dc@localhost> #3276: FilePath.addTrailingPathSeparator "" = "/" --------------------------------+------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries (other) | Version: 6.10.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 05:03:49 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 04:39:22 2009 Subject: [GHC] #3656: ghci leaves /tmp/ghc* directory if killed by signal In-Reply-To: <042.d95f8802b8c0b09855d12a49e63b7a91@localhost> References: <042.d95f8802b8c0b09855d12a49e63b7a91@localhost> Message-ID: <051.b3ecb8e57b3169fc1fdaa1fdd6c0fd2e@localhost> #3656: ghci leaves /tmp/ghc* directory if killed by signal ---------------------------+------------------------------------------------ Reporter: vvv | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by vvv): Replying to [comment:1 igloo]: > After killing GHC, if I hit enter in the terminal then I get a > {{{ > : hWaitForInput: hardware fault (Input/output error) > }}} > exception, after which the directory is deleted. I haven't noticed such behavior. What I ''have'' noticed is that /tmp/ghc* directories are not ''always'' created. They are created on one of my laptops, while on another they are not. Both have the same version of GHC (6.10.4) installed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 07:29:48 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 07:05:30 2009 Subject: [GHC] #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient In-Reply-To: <059.876fe881e6bc9b43ab179d4b6da29ec1@localhost> References: <059.876fe881e6bc9b43ab179d4b6da29ec1@localhost> Message-ID: <068.a53d47a6f9a63f5f437f3714a72ff280@localhost> #1544: Derived Read instances for recursive datatypes with infix constructors are too inefficient -----------------------------------+---------------------------------------- Reporter: jcpetruzza@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------+---------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 07:31:15 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 07:06:32 2009 Subject: [GHC] #1579: instance Read Integer contradicts Haskell98 In-Reply-To: <051.6921aabdfe30316c83b43a5f181003cc@localhost> References: <051.6921aabdfe30316c83b43a5f181003cc@localhost> Message-ID: <060.0a282fc75c8050c8ee17f7d5d58ec6c5@localhost> #1579: instance Read Integer contradicts Haskell98 -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: 6.6.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 07:31:53 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 07:07:11 2009 Subject: [GHC] #1693: Make distclean (still) doesn't In-Reply-To: <046.e3a8789d309d54a6f93929d3964d34f4@localhost> References: <046.e3a8789d309d54a6f93929d3964d34f4@localhost> Message-ID: <055.d9e1904164ebe569288d0ff2069be0ed@localhost> #1693: Make distclean (still) doesn't ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.6.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 07:34:00 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 07:09:19 2009 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.84b57418320f2b0742d5b0b70311e02a@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------+---------------------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: hsetbuffering buffering buffer Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 07:37:54 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 07:13:11 2009 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@localhost> References: <045.f06a53427920f75d02000e2372e27573@localhost> Message-ID: <054.10e5f62420c9aca242c5613fbe7b33a5@localhost> #2301: Proper handling of SIGINT/SIGQUIT --------------------------------+------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/process | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 07:43:53 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 07:19:12 2009 Subject: [GHC] #2346: Compilation of large source files requires a lot of RAM In-Reply-To: <046.285595109907aedbac69f385749bac00@localhost> References: <046.285595109907aedbac69f385749bac00@localhost> Message-ID: <055.3541e1e4a3046fa0d74f685c8dce1daf@localhost> #2346: Compilation of large source files requires a lot of RAM -------------------------------------------+-------------------------------- Reporter: choener | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 07:58:48 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 07:34:05 2009 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.e7af80202c84d84dc7c7c887f4765734@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------------+------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: None | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 07:59:14 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 07:34:30 2009 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.38c13ad870f12637b5054ec554f34079@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------------+------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: None | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by igloo): See also #2510 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 08:00:18 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 07:35:36 2009 Subject: [GHC] #2510: Environment modification during installation should be optional In-Reply-To: <045.3e84f679ca4e95a8a9ec350bbb64b495@localhost> References: <045.3e84f679ca4e95a8a9ec350bbb64b495@localhost> Message-ID: <054.bb9ffbe80577f32a5794656c41eaa4c9@localhost> #2510: Environment modification during installation should be optional ------------------------------+--------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => _|_ Comment: See also #2489 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 08:36:28 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 08:11:45 2009 Subject: [GHC] #2979: better support for FFI C wrappers for macros in system headers In-Reply-To: <045.050d142d1954d12d764c4cd94c9c38c8@localhost> References: <045.050d142d1954d12d764c4cd94c9c38c8@localhost> Message-ID: <054.6587734f3a666f392192130354b5c13e@localhost> #2979: better support for FFI C wrappers for macros in system headers ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 Comment: I would like to be able to just say {{{ foreign import wrapped "iconv" iconv :: Foo -> IO Bar }}} and have GHC automatically generate the trivial wrapper. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 08:54:24 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 08:29:41 2009 Subject: [GHC] #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` In-Reply-To: <043.429d5e175a90219c9682c6f3937cb586@localhost> References: <043.429d5e175a90219c9682c6f3937cb586@localhost> Message-ID: <052.4b7510984e989198d09e097506523160@localhost> #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` ------------------------------+--------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:05:20 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 08:40:47 2009 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.30b98b39ef569cbe6512154d32c01096@localhost> #2615: ghci doesn't play nice with linker scripts ---------------------------+------------------------------------------------ Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:06:03 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 08:41:21 2009 Subject: [GHC] #2797: ghci stack overflows when ghc does not In-Reply-To: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> References: <053.b5bed6c883dfb7d157e5092dcf2242ee@localhost> Message-ID: <062.e83151e362307617ffba6a50a6c46008@localhost> #2797: ghci stack overflows when ghc does not --------------------------------------+------------------------------------- Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: GHCi | Version: 6.11 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:08:10 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 08:43:33 2009 Subject: [GHC] #2824: Duplicate symbols generated when Generics flag and syb-with-class "derive" used simultaneously In-Reply-To: <046.347763e7287f3bda7f4c07ddb98fcdaa@localhost> References: <046.347763e7287f3bda7f4c07ddb98fcdaa@localhost> Message-ID: <055.8fbc492e7fd605927d96fe5c1d547078@localhost> #2824: Duplicate symbols generated when Generics flag and syb-with-class "derive" used simultaneously -------------------------------+-------------------------------------------- Reporter: jcheney | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Template Haskell | Version: 6.10.1 Resolution: fixed | Keywords: generics, syb-with-class Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: I can no longer reproduce this in the 6.12 branch or HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:18:41 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 08:54:22 2009 Subject: [GHC] #2897: HsFFI.h is not in the default include path for hsc2hs In-Reply-To: <042.b2d6e868e73bff261558ad2f8fec87f6@localhost> References: <042.b2d6e868e73bff261558ad2f8fec87f6@localhost> Message-ID: <051.47a8287c1df9c9dbcc3eb3d3086c2233@localhost> #2897: HsFFI.h is not in the default include path for hsc2hs ---------------------------+------------------------------------------------ Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: hsc2hs | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:19:38 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 08:54:55 2009 Subject: [GHC] #2924: createDirectory: permission denied In-Reply-To: <047.7f5e4787e0730bc3878fcff588107d39@localhost> References: <047.7f5e4787e0730bc3878fcff588107d39@localhost> Message-ID: <056.0765e4b678e337e5c8eded932cc44aaf@localhost> #2924: createDirectory: permission denied ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries/directory | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 Failure: None/Unknown | ----------------------------------+----------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:22:29 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 08:57:45 2009 Subject: [GHC] #2929: INFINITY used in .hc files without -std=c99 In-Reply-To: <045.9c2069ffa5b68c9fb1e9f0987d2d791e@localhost> References: <045.9c2069ffa5b68c9fb1e9f0987d2d791e@localhost> Message-ID: <054.3f4d818ad94a6fa7e076d2c5c069de14@localhost> #2929: INFINITY used in .hc files without -std=c99 -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Solaris Testcase: 1861 | Architecture: sparc Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:28:27 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 09:03:44 2009 Subject: [GHC] #3072: considerations for management of shared libs In-Reply-To: <045.6f777a46b5d4eb212ac94c917f9f3ef8@localhost> References: <045.6f777a46b5d4eb212ac94c917f9f3ef8@localhost> Message-ID: <054.4245a4d0c29ce1face1b4bcce0c4a6a8@localhost> #3072: considerations for management of shared libs ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Package system | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:30:15 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 09:05:53 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.c31b1fb171e13eeaabf1066d99271397@localhost> #3085: warn about language extensions that are not used ------------------------------+--------------------------------------------- Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: warnings extensions language Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:32:36 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 09:08:03 2009 Subject: [GHC] #3090: ghc-pkg update should fail if dependent packages might break In-Reply-To: <047.bbfd47d98ad2aecd41c60e5c078d3f61@localhost> References: <047.bbfd47d98ad2aecd41c60e5c078d3f61@localhost> Message-ID: <056.c0d0b115980768d9f2cdaa6aab393814@localhost> #3090: ghc-pkg update should fail if dependent packages might break -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Package system | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:24:55 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 09:08:28 2009 Subject: [GHC] #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix In-Reply-To: <044.33b296bee16ac04eb53e73148864ea5b@localhost> References: <044.33b296bee16ac04eb53e73148864ea5b@localhost> Message-ID: <053.851b79a02fc351d4716a33e98bfcb1ce@localhost> #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/process | Version: 6.10.1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed * type: feature request => bug Comment: I'm closing this ticket. If someone wants to propose adding a `killProcess` then please see http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:33:26 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 09:08:43 2009 Subject: [GHC] #3104: -main-is should be a link time option, not compile time In-Reply-To: <051.c9e4c40c62127bef2ad48557fef49f93@localhost> References: <051.c9e4c40c62127bef2ad48557fef49f93@localhost> Message-ID: <060.ed7ffc5896b5622b9e28b5047c701925@localhost> #3104: -main-is should be a link time option, not compile time ---------------------------+------------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:34:23 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 09:09:40 2009 Subject: [GHC] #3107: Over-eager GC when blocked on a signal in the non-threaded runtime In-Reply-To: <044.33d111777101268af6a254823101f5b5@localhost> References: <044.33d111777101268af6a254823101f5b5@localhost> Message-ID: <053.062eeee4cf390ae706f1dec9608e6741@localhost> #3107: Over-eager GC when blocked on a signal in the non-threaded runtime --------------------------------------+------------------------------------- Reporter: awick | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:35:12 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 09:10:29 2009 Subject: [GHC] #3130: copyFile and findExecutable don't work correctly if filename has national symbols In-Reply-To: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> References: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> Message-ID: <056.1785ec65f34bb69cac99cf443b2a39bb@localhost> #3130: copyFile and findExecutable don't work correctly if filename has national symbols ----------------------------------+----------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries/directory | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 Failure: None/Unknown | ----------------------------------+----------------------------------------- Changes (by igloo): * priority: normal => high * failure: => None/Unknown * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:37:35 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 09:12:59 2009 Subject: [GHC] #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar In-Reply-To: <053.70a1854543dd01f0108efd70a01e67de@localhost> References: <053.70a1854543dd01f0108efd70a01e67de@localhost> Message-ID: <062.4ba43c0b8b8940373041d1bc72dfa82e@localhost> #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar -----------------------------+---------------------------------------------- Reporter: ChrisKuklewicz | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: 6.10.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 Comment: The simplest way forward might be to remove them from base, and put them in a de-coupled concurrency package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:43:27 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 09:18:53 2009 Subject: [GHC] #3165: :history throws "Irrefutable pattern failed" exception In-Reply-To: <046.98732e4c9934d7000eb5550f93cd4a26@localhost> References: <046.98732e4c9934d7000eb5550f93cd4a26@localhost> Message-ID: <055.a10e806e4af2a101ec3d1b538f12065b@localhost> #3165: :history throws "Irrefutable pattern failed" exception ---------------------------+------------------------------------------------ Reporter: greenrd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.2 Resolution: invalid | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => invalid Comment: No response from submitter, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:45:29 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 09:20:53 2009 Subject: [GHC] #3169: Bad occurs-check error message In-Reply-To: <046.f50c6669d566defadebec162fefa1a6e@localhost> References: <046.f50c6669d566defadebec162fefa1a6e@localhost> Message-ID: <055.16c90c463a4bf5aeff112e47a5e7cff0@localhost> #3169: Bad occurs-check error message --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 09:57:09 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 09:32:29 2009 Subject: [GHC] #3657: ffi-1.0 causes panic in 6.12.20091010 In-Reply-To: <045.b9b668a0e35a678f68b5b35dd98d4aba@localhost> References: <045.b9b668a0e35a678f68b5b35dd98d4aba@localhost> Message-ID: <054.5f03f7b0642b369bf6c5075895e1c23d@localhost> #3657: ffi-1.0 causes panic in 6.12.20091010 ---------------------------+------------------------------------------------ Reporter: tobsan | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by kosmikus): This is almost certainly a duplicate of #3580. As far as I know, Gentoo also strips all files by default, and this for some reason turns out to be harmful to ghci in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 10:25:19 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 10:00:38 2009 Subject: [GHC] #3181: Regression in unboxing In-Reply-To: <044.12b8af7c7e17bf83c854d3057fcb12c2@localhost> References: <044.12b8af7c7e17bf83c854d3057fcb12c2@localhost> Message-ID: <053.30afd537126dea8b283c438d3f671f24@localhost> #3181: Regression in unboxing --------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.2 Resolution: | Keywords: unboxing boxing Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 10:33:40 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 10:08:56 2009 Subject: [GHC] #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain In-Reply-To: <045.7911c27a1a92708be5cdea967d156927@localhost> References: <045.7911c27a1a92708be5cdea967d156927@localhost> Message-ID: <054.f99fa9f7b1b6ea2aedf91906de60ae1d@localhost> #3252: having to call hs_add_root(__stginit_Foo) is a bit of a pain ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (FFI) | Version: 6.10.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 10:58:39 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 10:34:00 2009 Subject: [GHC] #3657: ffi-1.0 causes panic in 6.12.20091010 In-Reply-To: <045.b9b668a0e35a678f68b5b35dd98d4aba@localhost> References: <045.b9b668a0e35a678f68b5b35dd98d4aba@localhost> Message-ID: <054.cfc12d40e9132da0a6991360c01ebcee@localhost> #3657: ffi-1.0 causes panic in 6.12.20091010 ---------------------------+------------------------------------------------ Reporter: tobsan | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.12.1 RC1 Resolution: duplicate | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: Thanks, kosmikus. Looks likely you're right, so I'm closing this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 11:02:35 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 10:37:52 2009 Subject: [GHC] #3072: considerations for management of shared libs In-Reply-To: <045.6f777a46b5d4eb212ac94c917f9f3ef8@localhost> References: <045.6f777a46b5d4eb212ac94c917f9f3ef8@localhost> Message-ID: <054.84b7faa02bfa80c6a7b81d0790989c4c@localhost> #3072: considerations for management of shared libs ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Package system | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by igloo): See also #3268. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 11:02:49 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 10:38:06 2009 Subject: [GHC] #3268: implement the Cabal ${pkgroot} spec extension In-Reply-To: <045.8be95892c9d19347370cbf9a54614c20@localhost> References: <045.8be95892c9d19347370cbf9a54614c20@localhost> Message-ID: <054.1580f693ce9f3ead3ecae7260d54e1f3@localhost> #3268: implement the Cabal ${pkgroot} spec extension ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Package system | Version: 6.10.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 Comment: See also #3072. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 11:05:00 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 10:40:17 2009 Subject: [GHC] #3283: Selective disabling of unused bind warnings In-Reply-To: <042.99c53619193c24de1883dd2c0ccb355d@localhost> References: <042.99c53619193c24de1883dd2c0ccb355d@localhost> Message-ID: <051.027575570f13be8a5ccbfd151e4d7dc3@localhost> #3283: Selective disabling of unused bind warnings ------------------------------+--------------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 11:05:34 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 10:40:51 2009 Subject: [GHC] #3326: the recompilation checker should take CPP flags into account In-Reply-To: <047.f460b2673a1733e129e3e26d96037ca8@localhost> References: <047.f460b2673a1733e129e3e26d96037ca8@localhost> Message-ID: <056.d2f7fac3c381533b3cd1c05613461f17@localhost> #3326: the recompilation checker should take CPP flags into account ---------------------------+------------------------------------------------ Reporter: bkomuves | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 11:13:41 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 10:49:31 2009 Subject: [GHC] #3329: Errors Building 6.10.3 on NetBSD 4.0 In-Reply-To: <042.a79f04c63210b2fd7097ecd4b82fa86e@localhost> References: <042.a79f04c63210b2fd7097ecd4b82fa86e@localhost> Message-ID: <051.7c11949ca2876d19fc66947cb088accf@localhost> #3329: Errors Building 6.10.3 on NetBSD 4.0 ---------------------------+------------------------------------------------ Reporter: cjs | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: The build system has been completely changed in 6.12, so I'm closing this ticket. If you are still having problems, please open new tickets, one for each issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 14:55:41 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 14:30:56 2009 Subject: [GHC] #3200: System.Environment.withProgName strips everything before the last slash In-Reply-To: <044.6c7a0324fd6d877811b6a46ca881b0e2@localhost> References: <044.6c7a0324fd6d877811b6a46ca881b0e2@localhost> Message-ID: <053.e7caee3d113c11c942da90a2574561a5@localhost> #3200: System.Environment.withProgName strips everything before the last slash -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.2 Resolution: wontfix | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: reopened => closed * failure: => None/Unknown * resolution: => wontfix Comment: I think this would be best handled as part of the library proposal for #3199. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 15:06:23 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 14:41:39 2009 Subject: [GHC] #3215: Valgrind support In-Reply-To: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> References: <043.40f286e92e08e430fc0b2cd8ad0e1b39@localhost> Message-ID: <052.71b3cc9716d1cc392a3991f3fde39c0b@localhost> #3215: Valgrind support ------------------------------+--------------------------------------------- Reporter: cmcq | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.3 Resolution: | Keywords: valgrind Difficulty: Unknown | Os: Linux Testcase: yes | Architecture: x86 Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 15:08:47 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 14:44:02 2009 Subject: [GHC] #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 In-Reply-To: <053.190394749e5862e303daca81830a576b@localhost> References: <053.190394749e5862e303daca81830a576b@localhost> Message-ID: <062.9e6ac80317345815bd89a385d3bd1f04@localhost> #3222: GLFW 0.3 build fails w/ SSE error in 6.10.3, works in 6.10.1 -----------------------------+---------------------------------------------- Reporter: GregFrascadore | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.3 Resolution: | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 15:14:23 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 14:49:41 2009 Subject: [GHC] #3226: please eliminate error message from Make on every build In-Reply-To: <041.af1846b041a640c6799f84ed05380953@localhost> References: <041.af1846b041a640c6799f84ed05380953@localhost> Message-ID: <050.e571c81c834a7e6522d0c0d5a4579616@localhost> #3226: please eliminate error message from Make on every build ------------------------------+--------------------------------------------- Reporter: nr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.11 Resolution: wontfix | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => wontfix Comment: I don't think there's a cure for this that isn't worse than the disease, so I'm closing this as wont-fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 15:15:15 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 14:50:37 2009 Subject: [GHC] #3260: Linking stage2 on PPC gives "scattered reloc r_address too large" In-Reply-To: <043.9087f80d620051a542dc03d51ff19b43@localhost> References: <043.9087f80d620051a542dc03d51ff19b43@localhost> Message-ID: <052.7486941affdb099a6bfb325796dadbd1@localhost> #3260: Linking stage2 on PPC gives "scattered reloc r_address too large" ---------------------------+------------------------------------------------ Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.11 Resolution: | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: powerpc Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => _|_ Comment: Not a tier 1 platform, so setting milestone to _|_. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 15:16:10 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 14:51:27 2009 Subject: [GHC] #3350: GHC doesn't compile on Mac OS X 10.4 (Tiger) via MacPorts In-Reply-To: <044.ceb05e62d959d517126b90f70525a764@localhost> References: <044.ceb05e62d959d517126b90f70525a764@localhost> Message-ID: <053.070af28e4dbc9816a5fd5a7671c8d72c@localhost> #3350: GHC doesn't compile on Mac OS X 10.4 (Tiger) via MacPorts ---------------------------+------------------------------------------------ Reporter: indil | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.3 Resolution: invalid | Keywords: install, error, gmp, linker Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => invalid Comment: I'm closing this as it looks like a !MacPorts issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 15:22:01 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 14:57:16 2009 Subject: [GHC] #3419: Incorrect "unnecessary import" warning In-Reply-To: <051.9b501dfeb3f845847a9d65fa1e7b4552@localhost> References: <051.9b501dfeb3f845847a9d65fa1e7b4552@localhost> Message-ID: <060.dec0b28d9dee24a901979635e30c034f@localhost> #3419: Incorrect "unnecessary import" warning ---------------------------+------------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Resolution: wontfix | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => wontfix Comment: Too late to change this for 6.12, so I'd suggest that if anyone is not happy with the new behaviour that it would be best brought up on the users mailing list once 6.12 has been released. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 15:23:47 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 14:59:04 2009 Subject: [GHC] #3436: runtime: internal error: traverseWeakPtrList: not WEAK In-Reply-To: <050.705145ec7510c89b41279536e44ce954@localhost> References: <050.705145ec7510c89b41279536e44ce954@localhost> Message-ID: <059.30b29971c4435340b1065a65f7d90563@localhost> #3436: runtime: internal error: traverseWeakPtrList: not WEAK -----------------------------+---------------------------------------------- Reporter: sannysanoff | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * failure: => None/Unknown Old description: > I was compiling my program (attached) with jhc version 0.6.1. > jhc was compiled with ghc 6.10.4 with -O, not -O2 option, as in jhc's > Makefile. > ghc 6.10.4 was taken from arch linux repository. > warning: jhc compilation takes very long (I went home after 45 min) and > very much (maybe 8G RAM?). > i am not sure about total memory conditions, around 10G+7G swap was > available for compile. > error was: > > jhc: internal error: traverseWeakPtrList: not WEAK > (GHC version 6.10.4 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug New description: I was compiling my program (attached) with jhc version 0.6.1. jhc was compiled with ghc 6.10.4 with -O, not -O2 option, as in jhc's Makefile. ghc 6.10.4 was taken from arch linux repository. warning: jhc compilation takes very long (I went home after 45 min) and very much (maybe 8G RAM?). i am not sure about total memory conditions, around 10G+7G swap was available for compile. error was: {{{ jhc: internal error: traverseWeakPtrList: not WEAK (GHC version 6.10.4 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 16:13:55 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 15:49:09 2009 Subject: [GHC] #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks In-Reply-To: <052.f949c738ea0d9d2b66116addc98fdaed@localhost> References: <052.f949c738ea0d9d2b66116addc98fdaed@localhost> Message-ID: <061.b6dcf47989688eec315e0c486aa2248d@localhost> #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks -----------------------------+---------------------------------------------- Reporter: andrewbirkett | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 16:14:15 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 15:49:31 2009 Subject: [GHC] #3441: readProcess ... (exit 11): failed In-Reply-To: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> References: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> Message-ID: <054.67b6ac900c2e82d39a596143761693dc@localhost> #3441: readProcess ... (exit 11): failed --------------------------------+------------------------------------------- Reporter: Andriy | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/process | Version: 6.10.3 Resolution: | Keywords: readProcess exit 11 Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * failure: => None/Unknown Old description: > When one haskell script (here Parent.hs) runs another script (Child.hs), > it fails at some point with an error: > > Parent.hs: readProcess: ./Child.hs "param1" "param2" ... "paramN" (exit > 11): failed > > Details: > > I have a set of haskell scripts. Each script has following interpreter > spec as the first line: > > #!/usr/bin/env runghc > > These scripts manage some Java building process. Child.hs is long- > running. It can run for a few hours. It builds a Java application, runs > tests on it. About once a week the parent script fails with the error > above. I use the script about 2-5 times a day. > > My system is Ubuntu 8.04 (Hardy Heron). I installed GHC 6.10.3 locally, I > also have GHC 6.8.2 installed from the Ubuntu repositories. > > Besides the problem itself, it is not clear what "exit 11" means. New description: When one haskell script (here Parent.hs) runs another script (Child.hs), it fails at some point with an error: {{{ Parent.hs: readProcess: ./Child.hs "param1" "param2" ... "paramN" (exit 11): failed }}} Details: I have a set of haskell scripts. Each script has following interpreter spec as the first line: {{{ #!/usr/bin/env runghc }}} These scripts manage some Java building process. Child.hs is long-running. It can run for a few hours. It builds a Java application, runs tests on it. About once a week the parent script fails with the error above. I use the script about 2-5 times a day. My system is Ubuntu 8.04 (Hardy Heron). I installed GHC 6.10.3 locally, I also have GHC 6.8.2 installed from the Ubuntu repositories. Besides the problem itself, it is not clear what "exit 11" means. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 17:52:39 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 17:27:57 2009 Subject: [GHC] #3436: runtime: internal error: traverseWeakPtrList: not WEAK In-Reply-To: <050.705145ec7510c89b41279536e44ce954@localhost> References: <050.705145ec7510c89b41279536e44ce954@localhost> Message-ID: <059.e437d9f72ef0bf8107048a47556c8d75@localhost> #3436: runtime: internal error: traverseWeakPtrList: not WEAK -----------------------------+---------------------------------------------- Reporter: sannysanoff | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12.2 Comment: To clarify: It's running jhc (to compile !BenchVm) that takes the time/RAM. I tried it with 4G RAM a 20G swap file, but after about 14 mins I was spending too much time swapping and making very little progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 17:55:54 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 17:31:10 2009 Subject: [GHC] #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet In-Reply-To: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> References: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> Message-ID: <058.e41b64d3134add1329f89d486e3d9316@localhost> #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet ---------------------------+------------------------------------------------ Reporter: mightybyte | Owner: Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 17:56:43 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 17:31:58 2009 Subject: [GHC] #3440: Improve error message for GADT failures In-Reply-To: <046.b4d392ead07808cb956844cd7c242871@localhost> References: <046.b4d392ead07808cb956844cd7c242871@localhost> Message-ID: <055.387b3cdc8269c178b5390dec95592a4a@localhost> #3440: Improve error message for GADT failures --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 17:57:07 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 17:32:31 2009 Subject: [GHC] #3052: ghc FFI doesn't support thiscall In-Reply-To: <047.ea34806f73921c57cbc395f3f5a9a535@localhost> References: <047.ea34806f73921c57cbc395f3f5a9a535@localhost> Message-ID: <056.dbaf56eb4fc542837101492cc0976f96@localhost> #3052: ghc FFI doesn't support thiscall -----------------------------------------+---------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (FFI) | Version: 6.10.1 Resolution: | Keywords: Difficulty: Moderate (less than a day) | Os: Windows Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 17:58:46 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 17:34:04 2009 Subject: [GHC] #3024: Rewrite hp2ps in Haskell In-Reply-To: <043.5e2ae06063a38e8d4403ee8cfc50d869@localhost> References: <043.5e2ae06063a38e8d4403ee8cfc50d869@localhost> Message-ID: <052.c069b0d7fc22bba959484d98d37de28f@localhost> #3024: Rewrite hp2ps in Haskell ---------------------------+------------------------------------------------ Reporter: SamB | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Profiling | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12 branch => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 17:58:59 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 17:34:14 2009 Subject: [GHC] #2968: add test for C trigraphs In-Reply-To: <045.2a7f68178978b83c4a4101bfbab4cf22@localhost> References: <045.2a7f68178978b83c4a4101bfbab4cf22@localhost> Message-ID: <054.e1874e321dd9edb8bf2f67a81954d151@localhost> #2968: add test for C trigraphs ---------------------------+------------------------------------------------ Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 17:58:51 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 17:34:21 2009 Subject: [GHC] #3021: A way to programmatically insert marks into heap profiling output In-Reply-To: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> References: <043.8f6f7af4d3cf139bc012e761a76247cb@localhost> Message-ID: <052.7ab1388dff9ded69120ad30ac996a47e@localhost> #3021: A way to programmatically insert marks into heap profiling output ------------------------------+--------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Profiling | Version: 6.10.1 Resolution: | Keywords: profiling Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 17:59:13 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 17:34:34 2009 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.837bc4530cee03cb87a4cfb9c993715a@localhost> #2467: orphan instance warnings are badly behaved ---------------------------+------------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:22:16 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 17:57:34 2009 Subject: [GHC] #1216: indexing 2d arrays is slow and leaky. why? In-Reply-To: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> References: <044.7a2c34fb5e14ee065cc1b66e35e75915@localhost> Message-ID: <053.50fa4bceb1bd6b129d893839cb5cf2c3@localhost> #1216: indexing 2d arrays is slow and leaky. why? --------------------------------------+------------------------------------- Reporter: claus | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:25:02 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:00:22 2009 Subject: [GHC] #1434: Slow conversion from Double to Int In-Reply-To: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> References: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> Message-ID: <073.abcccb2c60932ca2b2649534de1fddd2@localhost> #1434: Slow conversion from Double to Int ----------------------------------------+----------------------------------- Reporter: ghc@henning-thielemann.de | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.4.1 Resolution: | Keywords: rules Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | ----------------------------------------+----------------------------------- Changes (by igloo): * owner: dons => * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:26:41 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:01:56 2009 Subject: [GHC] #1820: Windows segfault-catching only works for the main thread In-Reply-To: <047.7ca539e672ab08a35be7d52badf17eec@localhost> References: <047.7ca539e672ab08a35be7d52badf17eec@localhost> Message-ID: <056.c23f97090534e49f08305bbe884a182e@localhost> #1820: Windows segfault-catching only works for the main thread -----------------------------------------------+---------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.8.1 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: derefnull(ghci), divbyzero(ghci) | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------------+---------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:28:04 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:03:41 2009 Subject: [GHC] #1969: enormous compile times In-Reply-To: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> References: <045.1ab99ac1a52ae6b35a7131dc801608a9@localhost> Message-ID: <054.3cc58947b791e5881541005d35d272bf@localhost> #1969: enormous compile times -------------------------------------------+-------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.1 Resolution: | Keywords: performance Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: T1969 | Architecture: Unknown/Multiple Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:29:31 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:04:50 2009 Subject: [GHC] #2034: In FilePath, current directory should be ".", not "" In-Reply-To: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost> References: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost> Message-ID: <053.81750b68c5c159a325f448df1561e595@localhost> #2034: In FilePath, current directory should be ".", not "" --------------------------------+------------------------------------------- Reporter: igloo | Owner: neil Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * milestone: 6.12.1 => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:40:49 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:16:05 2009 Subject: [GHC] #2193: Monomorphic Pattern Bindings and Error Messages In-Reply-To: <043.34ccdeb27bebe4aa866d2df9503f28c8@localhost> References: <043.34ccdeb27bebe4aa866d2df9503f28c8@localhost> Message-ID: <052.9e6e065e00dcb1bd5a92e7d82e458d28@localhost> #2193: Monomorphic Pattern Bindings and Error Messages ---------------------------+------------------------------------------------ Reporter: sclv | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 Comment: Still happens with 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:41:47 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:17:02 2009 Subject: [GHC] #2271: floor, ceiling, round :: Double -> Int are awesomely slow In-Reply-To: <043.845265305898c52232b3689d70d3b99c@localhost> References: <043.845265305898c52232b3689d70d3b99c@localhost> Message-ID: <052.4c63c69d455bfdec35875e7d4c204017@localhost> #2271: floor, ceiling, round :: Double -> Int are awesomely slow -----------------------------+---------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: performance, math, double Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * owner: dons@galois.com => * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:42:51 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:18:09 2009 Subject: [GHC] #2281: properFraction implemented with modf primitive? In-Reply-To: <044.76024905950f1c976abf1516a4afff90@localhost> References: <044.76024905950f1c976abf1516a4afff90@localhost> Message-ID: <053.f82cd829be29af407c51370aa514db81@localhost> #2281: properFraction implemented with modf primitive? -----------------------------+---------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:49:59 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:25:15 2009 Subject: [GHC] #2558: re-throwing an asynchronous exception throws it synchronously In-Reply-To: <047.339350d6751eeb20e19b24c52175ed9b@localhost> References: <047.339350d6751eeb20e19b24c52175ed9b@localhost> Message-ID: <056.fe65833201976e889feb0684dc32d3e8@localhost> #2558: re-throwing an asynchronous exception throws it synchronously ---------------------------+------------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:55:59 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:31:18 2009 Subject: [GHC] #3008: Strange behavior when using newtyped version of IO monad in FFI import declarations In-Reply-To: <044.36e848c5758ff29e66ba18e678751e7c@localhost> References: <044.36e848c5758ff29e66ba18e678751e7c@localhost> Message-ID: <053.af86a667d389df52fa0a219739b464ef@localhost> #3008: Strange behavior when using newtyped version of IO monad in FFI import declarations ---------------------------+------------------------------------------------ Reporter: waern | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: FFI Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:57:46 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:33:01 2009 Subject: [GHC] #3016: Long compile times, large memory use with static data in 6.10 In-Reply-To: <043.860ff3ba501bcb6418e5778e2c5eff65@localhost> References: <043.860ff3ba501bcb6418e5778e2c5eff65@localhost> Message-ID: <052.f2ba5ad449dc011ba7c5ced57b5475d6@localhost> #3016: Long compile times, large memory use with static data in 6.10 ---------------------------------------------+------------------------------ Reporter: dons | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Resolution: | Keywords: static data Difficulty: Unknown | Os: Unknown/Multiple Testcase: simplCore/should_compile/T3016 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------------------------+------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 18:57:56 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:33:11 2009 Subject: [GHC] #3055: Int / Word / IntN / WordN are unequally optimized In-Reply-To: <044.1c39597802e7cddf9bd2ebc2460d51ee@localhost> References: <044.1c39597802e7cddf9bd2ebc2460d51ee@localhost> Message-ID: <053.63a338ec82951eb1f2d4a69b4fbff7aa@localhost> #3055: Int / Word / IntN / WordN are unequally optimized --------------------------------------+------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by igloo): * owner: igloo => * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 19:00:24 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:35:46 2009 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@localhost> References: <046.c71a4f69a48e7e64e18a56e29c643e03@localhost> Message-ID: <055.ece22a77b7d5049f9ad059da49925080@localhost> #3676: realToFrac doesn't sanely convert between floating types --------------------------------+------------------------------------------- Reporter: draconx | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: libraries (other) | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | --------------------------------+------------------------------------------- Comment (by igloo): See also #3070 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 19:00:34 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:35:53 2009 Subject: [GHC] #3070: floor(0/0) should not be defined In-Reply-To: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> References: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> Message-ID: <055.bee8eb678dcbbfaa5e7cb72faf5699b1@localhost> #3070: floor(0/0) should not be defined ---------------------------+------------------------------------------------ Reporter: carette | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Prelude | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12.2 Comment: See also #3676 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 19:04:39 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:40:07 2009 Subject: [GHC] #3102: The impossible happened with implicit parameters In-Reply-To: <053.ebde85ce07c798d9c38e07173af669f0@localhost> References: <053.ebde85ce07c798d9c38e07173af669f0@localhost> Message-ID: <062.226a037fb9c7f3c3697fa92f76739c08@localhost> #3102: The impossible happened with implicit parameters --------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: In 6.12 and HEAD, we now get a nice error: {{{ u.hs:11:9: Occurs check: cannot construct the infinite type: a = (?p::Int) => a In the first argument of `f', namely `t' In the expression: f t In the definition of `result': result = f t }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 19:06:35 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:42:01 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.ebbe88bfca1e5545b7cf5187acd2e322@localhost> #3231: Permission denied error with runProcess/openFile -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: reopened Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 19:07:50 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:43:06 2009 Subject: [GHC] #3294: Large compilation time/memory consumption In-Reply-To: <046.0a15417e538aeef3254b5152fea74b37@localhost> References: <046.0a15417e538aeef3254b5152fea74b37@localhost> Message-ID: <055.54ba37ac605f5e4a1cfd2ec787678e9d@localhost> #3294: Large compilation time/memory consumption -------------------------------------------+-------------------------------- Reporter: pumpkin | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.3 Resolution: | Keywords: Difficulty: Unknown | Os: MacOS X Testcase: | Architecture: x86 Failure: Compile-time performance bug | -------------------------------------------+-------------------------------- Changes (by igloo): * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 19:10:00 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:45:23 2009 Subject: [GHC] #3297: Compiler panic on incorrect code (TcTyFuns.flattenType: synonym family in a rank-n type) In-Reply-To: <048.6b2e6afb6975be0e0c389f8b6c47df0c@localhost> References: <048.6b2e6afb6975be0e0c389f8b6c47df0c@localhost> Message-ID: <057.8a3aa76a9aaf8aadc94f59634f89508a@localhost> #3297: Compiler panic on incorrect code (TcTyFuns.flattenType: synonym family in a rank-n type) --------------------------------------+------------------------------------- Reporter: hesselink | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.11 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: 6.12.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 21 19:19:41 2009 From: trac at galois.com (GHC) Date: Sat Nov 21 18:55:01 2009 Subject: [GHC] #3102: The impossible happened with implicit parameters In-Reply-To: <053.ebde85ce07c798d9c38e07173af669f0@localhost> References: <053.ebde85ce07c798d9c38e07173af669f0@localhost> Message-ID: <062.16e81a0321c28aa1ff3e74340f7e464e@localhost> #3102: The impossible happened with implicit parameters --------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by Ashley Yakeley): * status: closed => reopened * resolution: fixed => Comment: Better than panic, but it's still wrong, because "a = (?p::Int) => a" is not an infinite type. For instance, a = "(?p::Int) => String" satisfies "a = (?p::Int) => a". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 07:05:38 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 06:40:54 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.3ad4442fe15e4ac244337e636d16e7f6@localhost> #3668: PIE-enabled hardened gcc might broke GHC. ---------------------------+------------------------------------------------ Reporter: secludedsage | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by secludedsage): Line 2735 in the build.log, I notice: /usr/bin/ld -x -r -o dist/build/HSghc-prim-0.1.0.0.o dist/build/GHC/Bool.o dist/build/GHC/Generics.o dist/build/GHC/Ordering.o dist/build/GHC/PrimopWrappers.o dist/build/GHC/IntWord32.o dist/build/GHC/IntWord64.o dist/build/GHC/Tuple.o dist/build/GHC/Types.o dist/build/GHC/Unit.o `find dist/build -name "*_stub.o" -print` dist/build/cbits/longlong.o without -nopie from the build.mk's -optl-nopie. Is this the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 07:09:44 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 06:45:06 2009 Subject: [GHC] #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) In-Reply-To: <046.4436609d3a414ddff94df71de1efe346@localhost> References: <046.4436609d3a414ddff94df71de1efe346@localhost> Message-ID: <055.dad922587c2989f3f9f7465e2bbac867@localhost> #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) ------------------------------+--------------------------------------------- Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.11 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by ganesh): * failure: => None/Unknown Comment: See also #368 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 07:09:47 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 06:45:09 2009 Subject: [GHC] #368: Provide a Java Backend In-Reply-To: <049.9a5162d2cca544679bf8d2366946a80b@localhost> References: <049.9a5162d2cca544679bf8d2366946a80b@localhost> Message-ID: <058.5febece47d68a8d65df5a2f7bcc3dfc6@localhost> #368: Provide a Java Backend -----------------------------------------+---------------------------------- Reporter: rainbowang | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Resolution: None | Keywords: Difficulty: Project (more than a week) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by ganesh): * failure: => None/Unknown Comment: See also #2959 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 07:18:22 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 06:53:37 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.88dd30793125108d2442dd72d2208f89@localhost> #3668: PIE-enabled hardened gcc might broke GHC. ---------------------------+------------------------------------------------ Reporter: secludedsage | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by igloo): I don't know, but you probably need to add -nopie to `SRC_LD_OPTS`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 08:34:07 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 08:09:24 2009 Subject: [GHC] #408: OpenAL needs -pthread In-Reply-To: <047.3812ba60c7a6ad0b4a8228d469a2b634@localhost> References: <047.3812ba60c7a6ad0b4a8228d469a2b634@localhost> Message-ID: <056.b23de4c62162024b191f85e81cab703d@localhost> #408: OpenAL needs -pthread --------------------------------+------------------------------------------- Reporter: volkersf | Owner: panne Type: bug | Status: closed Priority: low | Milestone: Not GHC Component: libraries (other) | Version: 6.4.1 Resolution: invalid | Keywords: Difficulty: Unknown | Os: FreeBSD Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: None => invalid Comment: OpenAL is no longer shipped with GHC, so closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 08:37:34 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 08:12:49 2009 Subject: [GHC] #420: O'Haskell In-Reply-To: <043.85eea6d2fdc5ea4d79df32edc41b4340@localhost> References: <043.85eea6d2fdc5ea4d79df32edc41b4340@localhost> Message-ID: <052.bacb2dfdc7ec161507c2a4a9a949aa4b@localhost> #420: O'Haskell ------------------------------+--------------------------------------------- Reporter: mlbm | Owner: Type: feature request | Status: closed Priority: normal | Milestone: _|_ Component: None | Version: None Resolution: wontfix | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: None => wontfix Comment: I'm not aware of any plans in this area, but if anyone does want to do anything along these lines then it would be best to discuss it on the cvs- ghc list. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 10:03:48 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 09:39:04 2009 Subject: [GHC] #3070: floor(0/0) should not be defined In-Reply-To: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> References: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> Message-ID: <055.3838d0c78f76f8787ea34caaedc5ca46@localhost> #3070: floor(0/0) should not be defined ---------------------------+------------------------------------------------ Reporter: carette | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Prelude | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by carette): I don't think that exact patch is quite the way to go. Actually, I think that decodeFloat should be fixed to throw an exception when encountering NaN or infinities -- that's much more compatible with IEEE 754-2008. Also, there should probably be an isFinite :: Double -> Bool function, which would help guard against 'weird' floats with one check, not two. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 10:05:49 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 09:41:04 2009 Subject: [GHC] #451: GHC poor type-checker error message In-Reply-To: <050.1ad7d37d949f4e39b8c05bccbb5e4d15@localhost> References: <050.1ad7d37d949f4e39b8c05bccbb5e4d15@localhost> Message-ID: <059.cebd91a260906c39439682185e139bc2@localhost> #451: GHC poor type-checker error message --------------------------------------+------------------------------------- Reporter: isaacdupree | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.4 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: tcfail140 | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Changes (by igloo): * failure: => Other Comment: We get the same error in 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 10:10:06 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 09:45:19 2009 Subject: [GHC] #457: Strictness problem In-Reply-To: <049.af455cad9d05bfa37be883f32dbdb2e9@localhost> References: <049.af455cad9d05bfa37be883f32dbdb2e9@localhost> Message-ID: <058.891a203fa28878e0b06b48430b918207@localhost> #457: Strictness problem ------------------------------------------+--------------------------------- Reporter: nilsanders | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by igloo): * failure: => Incorrect result at runtime Comment: Still happens in 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 10:18:17 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 09:53:32 2009 Subject: [GHC] #476: HUnit treats failures as errors In-Reply-To: <052.8828f82466f40f846be6408440ea2b49@localhost> References: <052.8828f82466f40f846be6408440ea2b49@localhost> Message-ID: <061.5a22f989f3a3ceb1935b5b498eb9fc54@localhost> #476: HUnit treats failures as errors --------------------------------+------------------------------------------- Reporter: stefanheimann | Owner: RichardG Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.4.1 Resolution: invalid | Keywords: hunit Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: None => invalid Comment: HUnit is no longer distributed with GHC, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 10:42:30 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 10:17:48 2009 Subject: [GHC] #601: Replace GMP In-Reply-To: <047.118762464fe3464def09b9461b8cccc5@localhost> References: <047.118762464fe3464def09b9461b8cccc5@localhost> Message-ID: <056.f3f393ebfdd88429d0d1fc85a5c9ab95@localhost> #601: Replace GMP -----------------------------------+---------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: None Resolution: fixed | Keywords: Difficulty: Difficult (2-5 days) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------+---------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: None => fixed Comment: It's now possible to build GHC with different integer libraries, so I think we can call this ticket fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 13:35:23 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 13:10:40 2009 Subject: [GHC] #700: Inconsistent typechecking of pattern match in function binding In-Reply-To: <044.6d6aa26c41100e1b7bc5030e07a904dd@localhost> References: <044.6d6aa26c41100e1b7bc5030e07a904dd@localhost> Message-ID: <053.833e255ece6963776e572feb5a2d2e8b@localhost> #700: Inconsistent typechecking of pattern match in function binding ---------------------------+------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.4.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * priority: lowest => normal * failure: => None/Unknown * milestone: _|_ => 6.14.1 Comment: If it's now easy to fix then I think it's probably worth doing. The current behaviour does seem inconsistent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 13:37:04 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 13:12:20 2009 Subject: [GHC] #728: switch to compacting collection when swapping occurs In-Reply-To: <047.d71284f919c6246c824e6f6eb3e3cecf@localhost> References: <047.d71284f919c6246c824e6f6eb3e3cecf@localhost> Message-ID: <056.65ca0962d27a5f46f44010182c27c9e8@localhost> #728: switch to compacting collection when swapping occurs -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Resolution: | Keywords: compacting Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: Runtime performance bug | -----------------------------------------+---------------------------------- Changes (by igloo): * failure: => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 13:39:55 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 13:15:09 2009 Subject: [GHC] #706: GHC uses _stub.c files regardless of whether any 'foreign import' decls remain in a .hs file In-Reply-To: <055.48ae21f76b1442654d47b9fd49147ccc@localhost> References: <055.48ae21f76b1442654d47b9fd49147ccc@localhost> Message-ID: <064.7712251cdbddf9a00f84f4a561e0ca5d@localhost> #706: GHC uses _stub.c files regardless of whether any 'foreign import' decls remain in a .hs file -----------------------------------------+---------------------------------- Reporter: ncalexan@uci.edu | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (FFI) | Version: 6.4.1 Resolution: | Keywords: ffi, link Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by igloo): * failure: => None/Unknown * milestone: _|_ => 6.14.1 Comment: Can't/shouldn't we just record whether or not there's a stub file in the .hi file? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 13:56:41 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 13:32:16 2009 Subject: [GHC] #740: Copyright information is wrong in some GHC source files In-Reply-To: <044.e3018ba04e94127af296980fb94fc0de@localhost> References: <044.e3018ba04e94127af296980fb94fc0de@localhost> Message-ID: <053.d4622171441717ea35a4c3c50b35689b@localhost> #740: Copyright information is wrong in some GHC source files ---------------------------+------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: lowest | Milestone: _|_ Component: Prelude | Version: 6.4.1 Resolution: wontfix | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => wontfix Comment: I'm going to close this ticket because, while the copyright holder information is doubtless inaccurate, I can't see anyone comprehensively correcting it (if that's even possible). I'd suggest that if people find particular inaccuracies then they send patches to add copyright holders to the appropriate places. "wontfix" isn't entirely accurate, but none of the other options is better. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 14:56:58 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 14:32:18 2009 Subject: [GHC] #768: Improve performance of binary serialisation for interface files In-Reply-To: <047.d82f0a6c0e3929ea11d4f077a0cdb833@localhost> References: <047.d82f0a6c0e3929ea11d4f077a0cdb833@localhost> Message-ID: <056.ea38dce42cdce8e9b43830f220c6f65f@localhost> #768: Improve performance of binary serialisation for interface files -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.1 Resolution: fixed | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: N/A | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: We've started to move towards using the binary package, which uses a !ForeignPtr, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 15:07:27 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 14:42:40 2009 Subject: [GHC] #3680: Improve docs for 'length' Message-ID: <056.32b26bd2c9b5e88047fb0bedd9442617@localhost> #3680: Improve docs for 'length' ----------------------------------+----------------------------------------- Reporter: daniel.is.fischer | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ----------------------------------+----------------------------------------- The haddock docs for 'length' and 'genericLength' give no indication of their complexity. This leads to many inadvertent uses of 'length', causing poor performance. To reduce the number of those cases, I suggest inserting the complexity (/O(n)/) into the haddock docs, perhaps even a warning to the effect of "use only if you really want to know the length". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 15:51:38 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 15:26:54 2009 Subject: [GHC] #785: Allow partial application of type synonyms In-Reply-To: <064.c7f12400518ad269e3cde09d711352a9@localhost> References: <064.c7f12400518ad269e3cde09d711352a9@localhost> Message-ID: <073.40c7cb374a1cd254bb748bacf05a0cfe@localhost> #785: Allow partial application of type synonyms ----------------------------------------+----------------------------------- Reporter: Bulat.Ziganshin@gmail.com | Owner: Type: feature request | Status: closed Priority: low | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: wontfix | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------------------+----------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => wontfix Comment: I think that this is very unlikely to be implemented, and even if it is, would be better discussed in another forum, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 16:19:23 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 15:54:51 2009 Subject: [GHC] #816: Weird fundep behavior (with -fallow-undecidable-instances) In-Reply-To: <044.3c70b416f57f6840427c7f7466886ae7@localhost> References: <044.3c70b416f57f6840427c7f7466886ae7@localhost> Message-ID: <053.87410170b36aea6944bd80d09019e1c1@localhost> #816: Weird fundep behavior (with -fallow-undecidable-instances) --------------------------------------+------------------------------------- Reporter: nibro | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.4.2 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: tc216 | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: This example now compiles in 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 17:07:40 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 16:42:59 2009 Subject: [GHC] #851: Incomplete-pattern checking for n+k patterns is not implemented In-Reply-To: <046.dfba11239564563edf19c7b91679aa5b@localhost> References: <046.dfba11239564563edf19c7b91679aa5b@localhost> Message-ID: <055.0095d0a6ae1a28afd892035a2a72d260@localhost> #851: Incomplete-pattern checking for n+k patterns is not implemented ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: wontfix | Keywords: warnings Difficulty: Unknown | Os: Unknown/Multiple Testcase: ds061 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * failure: => None/Unknown * resolution: => wontfix Comment: The !NoNPlusKPatterns proposal was accepted for H'2010, so I don't think it is worth spending time on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 17:14:00 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 16:49:13 2009 Subject: [GHC] #2143: Yhc's sort is faster than GHC's In-Reply-To: <051.957b307ec22b893e4ac872796076b55a@localhost> References: <051.957b307ec22b893e4ac872796076b55a@localhost> Message-ID: <060.20dce10a86d844568a3d5736d328d318@localhost> #2143: Yhc's sort is faster than GHC's -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: NeilMitchell Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Comment (by daniel.is.fischer): For pseudo-random lists, my measurements showed the Yhc code consistently faster, though not very much (3-12%). For (rev)sorted or almost (rev)sorted lists, Yhc's code is up to 10 times faster (according to my measurements). Any chance to get the Yhc code into GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 20:48:19 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 20:23:42 2009 Subject: [GHC] #2143: Yhc's sort is faster than GHC's In-Reply-To: <051.957b307ec22b893e4ac872796076b55a@localhost> References: <051.957b307ec22b893e4ac872796076b55a@localhost> Message-ID: <060.bfd2f8634100732d63f45b8485566023@localhost> #2143: Yhc's sort is faster than GHC's -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: NeilMitchell Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): The attachment is the sorting algorithm from Yhc (actually, nhc98), as originally contributed by Thomas Nordin. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 20:49:55 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 20:25:06 2009 Subject: [GHC] #3681: hsc2hs wrapper script ignores default flags Message-ID: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> #3681: hsc2hs wrapper script ignores default flags ---------------------------+------------------------------------------------ Reporter: nwn | Owner: Type: bug | Status: new Priority: normal | Component: hsc2hs Version: 6.12.1 RC1 | Keywords: Os: MacOS X | Testcase: Architecture: x86 | Failure: None/Unknown ---------------------------+------------------------------------------------ hsc2hs wrapper script ignores default flags to build 32bit binary when specified C-compiler to use even if it was gcc. This become a problem when building packages with Cabal. As usual, Cabal passes --cc=/path/to/gcc to hsc2hs. So default flags are ignored, built packages are broken. I edited script to fix this problem. I think it's ugly fix, but it works. {{{ #!/bin/sh exedir="/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.0.20091121" exeprog="hsc2hs" executablename="$exedir/$exeprog" datadir="/Library/Frameworks/GHC.framework/Versions/612/usr/share" bindir="/Library/Frameworks/GHC.framework/Versions/612/usr/bin" topdir="/Library/Frameworks/GHC.framework/Versions/612/usr/lib/ghc-6.12.0.20091121" HSC2HS_EXTRA="--cflag=-m32 --lflag=-m32" #!/bin/sh tflag="--template=$topdir/template-hsc.h" Iflag="-I$topdir/include/" for arg do case "$arg" in *gcc) break;; -c*) HSC2HS_EXTRA=;; --cc=*) HSC2HS_EXTRA=;; -t*) tflag=;; --template=*) tflag=;; --) break;; esac done exec "$executablename" "$tflag" $HSC2HS_EXTRA ${1+"$@"} "$Iflag" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 22 23:58:08 2009 From: trac at galois.com (GHC) Date: Sun Nov 22 23:33:19 2009 Subject: [GHC] #3682: shared libraries not installed executable Message-ID: <050.74da172fa23f1ae1ddea30f8c8576c12@localhost> #3682: shared libraries not installed executable ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Package system Version: 6.12.1 RC1 | Keywords: Os: Linux | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ When ghc-6.12.0 is built with --enable-shared, libHS*.so shared library object files are installed with permission -rw-r--r-- (644) not -rwxr-xr-x (755) as they should be. (This is true for 6.12.0.20091118 and I assume also for rc2.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 03:57:18 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 03:32:37 2009 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.ffb2ba41d23a96c4a86646237d91482e@localhost> #2467: orphan instance warnings are badly behaved ---------------------------+------------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by simonpj): There seem to be two things going on in this ticket. 1. Do the instances in `mtl` and `array` have to include orphan instances? We should investigate and fix or punt. 2. Some reflections on orphan instances in general. Here the discussion is inconclusive, so we should probably milestone as _|_, leaving the ticket open so that we don't lose the thoughts. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 05:02:10 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 04:37:43 2009 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@localhost> Message-ID: <060.9226ac25188913842ee6a3de49cd28f7@localhost> #3085: warn about language extensions that are not used ------------------------------+--------------------------------------------- Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: warnings extensions language Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by NeilMitchell): HLint 1.6.6 above above can warn on unused language extensions: http://community.haskell.org/~ndm/hlint The hints are limited to those extensions which enable new syntax, but have spotted unused extensions for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 05:08:18 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 04:43:44 2009 Subject: [GHC] #2143: Yhc's sort is faster than GHC's In-Reply-To: <051.957b307ec22b893e4ac872796076b55a@localhost> References: <051.957b307ec22b893e4ac872796076b55a@localhost> Message-ID: <060.8cd042a7ab7ea411f398e53215327255@localhost> #2143: Yhc's sort is faster than GHC's -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: NeilMitchell Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Comment (by NeilMitchell): If memory serves, Lennart said he was the originally author of this code, so the path probably originates with HBC. The code in Yhc was taken unmodified from nhc98. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 05:47:15 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 05:22:42 2009 Subject: [GHC] #2143: Yhc's sort is faster than GHC's In-Reply-To: <051.957b307ec22b893e4ac872796076b55a@localhost> References: <051.957b307ec22b893e4ac872796076b55a@localhost> Message-ID: <060.93eb869ecab4e3bfa461e1dd5d15b571@localhost> #2143: Yhc's sort is faster than GHC's -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * owner: NeilMitchell => igloo * cc: lennart@augustsson.net (added) Comment: OK, well assuming Lennart is happy (I've added him to cc), let's just adopt this. Ian can you action? Although the milestone says "not ghc", these sorting routines are in the base libraries which we ship with GHC, aren't they? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Mon Nov 23 08:26:44 2009 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Mon Nov 23 08:14:02 2009 Subject: testing 6.12.1-pre Message-ID: <20091123132644.GA29768@scico.botik.ru> Dear GHC team, I have tested ghc-6.12.0.20091121 by 1) installing its binary and making and running the DoCon and Dumatel programs, 2) making it from source by its binary, making and running on it the DoCon and Dumatel programs. It looks all right. I skipped profiling. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From trac at galois.com Mon Nov 23 08:46:51 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 08:22:10 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris Message-ID: <045.e5089cca43f6d0feea222b47017c2de3@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ---------------------------+------------------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.1 RC1 | Keywords: Os: Solaris | Testcase: Architecture: x86 | Failure: Building GHC failed ---------------------------+------------------------------------------------ after unpacking `ghc-6.12.0.20091121-src.tar.bz2` and doing "./configure" and "gmake" I get many lines with: {{{ /bin/sh: syntax error at line 1: `;' unexpected }}} probably because /bin/sh is not bash under solaris. (I've no idea what calls /bin/sh) Finally building fails with: {{{ compiler/nativeGen/AsmCodeGen.lhs:19:1: lexical error at character 'i' gmake[1]: *** [compiler/stage2/build/.depend-v-p] Error 1 gmake[1]: *** Deleting file `compiler/stage2/build/.depend-v-p' gmake: *** [all] Error 2 }}} (thats the 'i' of an '#include', probably because unlit wasn't build) My log file is 1MB long (so I'm not sure if I can attach it here) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 08:55:21 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 08:30:31 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.8ef023e10eeda556a92f19c0d53dc751@localhost> #3668: PIE-enabled hardened gcc might broke GHC. ---------------------------+------------------------------------------------ Reporter: secludedsage | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by secludedsage): Well, I add "SRC_LD_OPTS+= -fno-PIE" here and the build failed at: ------------------------------------------------------------------------ == make boot - --no-print-directory -r --jobserver-fds=3,4 - --jobserver- fds=3,4 -j; in /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/utils/genapply ------------------------------------------------------------------------ /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -package-conf /var/tmp/portage/dev- lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,-- noexecstack -w -package pretty -fforce-recomp -c GenApply.hs -o GenApply.o -ohi GenApply.hi /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -M -dep-makefile .depend -osuf o -package-conf /var/tmp/portage/dev- lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -package- conf /var/tmp/portage/dev- lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,-- noexecstack -w -package pretty -fforce-recomp GenApply.hs /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -o genapply -package-conf /var/tmp/portage/dev- lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,-- noexecstack -w -package pretty -fforce-recomp -fno-PIE GenApply.o ghc: unrecognised flags: -fno-PIE Usage: For basic information, try the `--help' option. make[2]: *** [genapply] Error 1 Failed making boot in genapply: 1 make[1]: *** [boot] Error 1 make: *** [stage1] Error 1 notice that -fno-PIE is directly sent here, unlike other commands listed above. Why it is sent here? SRC_LD_OPTS should be sent directly to ld, shouldn't it? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 08:56:14 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 08:31:24 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.901d694ea99198b55193c6a2b4df8c2c@localhost> #3668: PIE-enabled hardened gcc might broke GHC. ---------------------------+------------------------------------------------ Reporter: secludedsage | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by secludedsage): {{{ ------------------------------------------------------------------------ == make boot - --no-print-directory -r --jobserver-fds=3,4 - --jobserver- fds=3,4 -j; in /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/utils/genapply ------------------------------------------------------------------------ /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -package-conf /var/tmp/portage/dev- lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,-- noexecstack -w -package pretty -fforce-recomp -c GenApply.hs -o GenApply.o -ohi GenApply.hi /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -M -dep-makefile .depend -osuf o -package-conf /var/tmp/portage/dev- lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -package- conf /var/tmp/portage/dev- lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,-- noexecstack -w -package pretty -fforce-recomp GenApply.hs /var/tmp/portage/dev-lang/ghc-6.10.4/work/usr/bin/ghc -o genapply -package-conf /var/tmp/portage/dev- lang/ghc-6.10.4/work/ghc-6.10.4/libraries/bootstrapping.conf -H32m -O -optc-march=native -opta-march=native -optc-nopie -optl-nopie -opta-Wa,-- noexecstack -w -package pretty -fforce-recomp -fno-PIE GenApply.o ghc: unrecognised flags: -fno-PIE Usage: For basic information, try the `--help' option. make[2]: *** [genapply] Error 1 Failed making boot in genapply: 1 make[1]: *** [boot] Error 1 make: *** [stage1] Error 1 }}} reformatted, sorry -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 08:59:54 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 08:35:14 2009 Subject: [GHC] #3605: Dll's freeze with -threaded In-Reply-To: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> References: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> Message-ID: <060.4760707b43ae3e393b98a63753894958@localhost> #3605: Dll's freeze with -threaded ----------------------------+----------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------+----------------------------------------------- Changes (by NeilMitchell): * failure: => None/Unknown Comment: I've written revised documentation and put it on my blog: http://neilmitchell.blogspot.com/2009/11/haskell-dlls-on-windows.html After a short period of time I'll incorporate any comments, format it properly for the manual, and submit a patch. I had a few questions: Is calling {{{hs_init}}} or {{{startupHaskell}}} preferred? I've gone with {{{hs_init}}} because that's in the FFI spec, but the current examples have both (which is just confusing). Section 11.6.1 (which I left alone) says "it will rewrite occurrence of -lHSfoo on the command line to -lHSfoo.dll". It's really not clear if it's rewriting -l''foo'' to -l''foo''.dll, or -lHS''foo'' to -lHS''foo''.dll - and similarly for the HScool line. Italics to indicate meta variables is very handy. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 09:39:02 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 09:14:20 2009 Subject: [GHC] #3633: Heap size suggestion of > 2145 MB gets ignored In-Reply-To: <042.715300f691a60275dfa2a5a83e344a71@localhost> References: <042.715300f691a60275dfa2a5a83e344a71@localhost> Message-ID: <051.91550747113b55ad580af16538fb874c@localhost> #3633: Heap size suggestion of > 2145 MB gets ignored -----------------------------+---------------------------------------------- Reporter: tim | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * priority: normal => high * owner: => igloo * type: bug => merge * milestone: 6.12 branch => 6.12.2 Comment: Fixed, along with a class of similar bugs: {{{ Thu Nov 19 06:24:22 PST 2009 Simon Marlow * Check upper/lower bounds on various RTS flags (#3633) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 09:47:10 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 09:22:21 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.2cde8c9befeec676fbb967619973ad4d@localhost> #3668: PIE-enabled hardened gcc might broke GHC. ---------------------------+------------------------------------------------ Reporter: secludedsage | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by secludedsage): I don't see any direct information about SRC_LD_OPTS. (Wiki pointed config.mk.in and it says SRC_P_OPTS, but no examples) I tried SRC_LD_OPTS+= -Wl,-nopie and get following: {{{ ------------------------------------------------------------------------ == make boot -r --jobserver-fds=3,4 -j; in /var/tmp/portage/dev-lang/ghc-6.10.4/work/ghc-6.10.4/includes ------------------------------------------------------------------------ Creating ghcplatform.h... Creating ghcautoconf.h... Done. Done. gcc -O -O2 -march=native -pipe -nopie -Wa,--noexecstack -DTABLES_NEXT_TO_CODE -I. -I../rts -c mkDerivedConstants.c -o mkDerivedConstants.o ../utils/mkdependC/mkdependC -f .depend -- -O -O2 -march=native -pipe -nopie -Wa,--noexecstack -DTABLES_NEXT_TO_CODE -I. -I../rts -- mkDerivedConstants.c shell-tools.c gcc -o mkGHCConstants.o -O -O2 -march=native -pipe -nopie -Wa,-- noexecstack -DTABLES_NEXT_TO_CODE -I. -I../rts -c mkDerivedConstants.c -DGEN_HASKELL gcc -o mkGHCConstants -O -O2 -march=native -pipe -nopie -Wa,--noexecstack -DTABLES_NEXT_TO_CODE -I. -I../rts -Wl,-nopie mkGHCConstants.o /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status make[1]: *** [mkGHCConstants] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [stage1] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 10:02:16 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 09:37:28 2009 Subject: [GHC] #3130: copyFile and findExecutable don't work correctly if filename has national symbols In-Reply-To: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> References: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> Message-ID: <056.9dc35699175d590b4c2fb6eb5be028b5@localhost> #3130: copyFile and findExecutable don't work correctly if filename has national symbols ----------------------------------+----------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries/directory | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 Failure: None/Unknown | ----------------------------------+----------------------------------------- Comment (by simonmar): I'm reasonably sure this is fixed in 6.12.1. Could someone test please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 10:51:05 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 10:26:16 2009 Subject: [GHC] #3070: floor(0/0) should not be defined In-Reply-To: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> References: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> Message-ID: <055.dea1e25a3dddc9300675e18d54ee21ad@localhost> #3070: floor(0/0) should not be defined ---------------------------+------------------------------------------------ Reporter: carette | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Prelude | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by simonpj): Jacques We are stalled on this (and I think a couple of other fp-related tickets) because we lack the sophistication in numerical methods to develop the Right Answer, and no consensus has emerged. Would you, and/or others interested in numerical aspects of programming, like to figure out what we should do, make a proposal, and ultimately send us a patch? If it's just left for GHC HQ I fear that nothing may happen. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 11:15:18 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 10:50:30 2009 Subject: [GHC] #3070: floor(0/0) should not be defined In-Reply-To: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> References: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> Message-ID: <055.d097257cd5b609914f3cb5a5285ddc29@localhost> #3070: floor(0/0) should not be defined ---------------------------+------------------------------------------------ Reporter: carette | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Prelude | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by carette): I can do that - but not before mid-January. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 11:27:08 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 11:02:19 2009 Subject: [GHC] #3130: copyFile and findExecutable don't work correctly if filename has national symbols In-Reply-To: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> References: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> Message-ID: <056.e89870e205534e929f9dbe6bcf40f7a2@localhost> #3130: copyFile and findExecutable don't work correctly if filename has national symbols ----------------------------------+----------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries/directory | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 Failure: None/Unknown | ----------------------------------+----------------------------------------- Comment (by shelarcy): Above examples work fine. copyFile:: {{{ C:\home>C:\ghc\ghc-6.13.20091122\bin\runghc.exe Test.hs "copyFile works if second argument has national path." "copyFile doesn't work if second argument has national path." "copyFile doesn't work if first argument has national path." }}} findExecutable:: {{{ C:\home>C:\ghc\ghc-6.13.20091122\bin\runghc.exe Test.hs Just "C:\\tool\\bin\\\12486\12473\12488.exe" }}} So, this bug is fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 11:32:57 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 11:08:08 2009 Subject: [GHC] #3130: copyFile and findExecutable don't work correctly if filename has national symbols In-Reply-To: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> References: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> Message-ID: <056.98f8631ec38d2f15eda0b0e2293f6703@localhost> #3130: copyFile and findExecutable don't work correctly if filename has national symbols ----------------------------------+----------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: libraries/directory | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 Failure: None/Unknown | ----------------------------------+----------------------------------------- Comment (by shelarcy): Replying to [comment:6 shelarcy]: > Above examples work fine. Oops, I used wrong version. So, I tested examples again. {{{ C:\home>C:\ghc\ghc-6.12.0.20091121\bin\runghc.exe Test.hs "copyFile works if second argument has national path." "copyFile doesn't work if second argument has national path." "copyFile doesn't work if first argument has national path." }}} {{{ C:\home>C:\ghc\ghc-6.12.0.20091121\bin\runghc.exe Test.hs Just "C:\\tool\\bin\\\12486\12473\12488.exe" }}} 6.12.1 RC 2 also work fine. This is fixed in 6.12.1, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 11:55:07 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 11:30:19 2009 Subject: [GHC] #3130: copyFile and findExecutable don't work correctly if filename has national symbols In-Reply-To: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> References: <047.da94d19c1a8d4f7956abff60dc99c03d@localhost> Message-ID: <056.ccf5f0bff899aa7610f2e1628d3e1c0c@localhost> #3130: copyFile and findExecutable don't work correctly if filename has national symbols ----------------------------------+----------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.2 Component: libraries/directory | Version: 6.10.1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 Failure: None/Unknown | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Great, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 14:32:02 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 14:07:15 2009 Subject: [GHC] #3684: Missing ghc-pkg options in --help Message-ID: <047.1024f8df520bd9d4665f757c76edb0a3@localhost> #3684: Missing ghc-pkg options in --help ---------------------------------+------------------------------------------ Reporter: kolmodin | Owner: Type: bug | Status: new Priority: normal | Component: ghc-pkg Version: 6.12.1 RC1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ {{{ghc-pkg}}} does not in {{{--help}}} say it can do {{{recache}}}. Any other missing commands? Could also use some trivial line-edits for the commands {{{dot}}} and {{{find-module}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 16:31:21 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 16:06:32 2009 Subject: [GHC] #3589: Recompilation checker doesn't take into account CPP headers In-Reply-To: <047.5d4e10ff362a5a53fb60efa7fea2fd88@localhost> References: <047.5d4e10ff362a5a53fb60efa7fea2fd88@localhost> Message-ID: <056.a09e1bfa7b7cca13ca0797e4e5ff57ea@localhost> #3589: Recompilation checker doesn't take into account CPP headers ---------------------------+------------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) * failure: => None/Unknown Comment: I've got this logic in a build system I wrote. At the moment I need to run GHC with the force recompilation flag to make sure GHC builds when it should, after headers have changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 20:54:14 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 20:29:26 2009 Subject: [GHC] #3685: "double free or corruption" error when running Setup.hs with other GHC in PATH Message-ID: <042.d3a505caff2f54b3cc2a8c83ae993cb8@localhost> #3685: "double free or corruption" error when running Setup.hs with other GHC in PATH -----------------------+---------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: Runtime crash -----------------------+---------------------------------------------------- Inside network-2.2.1.5 source directory: {{{ $ /home/alex/usr/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091121 $ /usr/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 $ echo $PATH /home/alex/.cabal/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/perlbin/site:/usr/bin/perlbin/vendor:/usr/bin/perlbin/core $ /home/alex/usr/bin/ghc --make Setup.hs [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Setup.hs:3:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Linking Setup ... $ ./Setup configure Warning: defaultUserHooks in Setup script is deprecated. Configuring network-2.2.1.5... Setup: fd:5: hGetContents: invalid argument (Invalid or incomplete multibyte or wide character) *** glibc detected *** ./Setup: double free or corruption (!prev): 0x08e21050 *** ======= Backtrace: ========= /lib/libc.so.6(+0x6b6c1)[0xb76166c1] /lib/libc.so.6(+0x6cf18)[0xb7617f18] /lib/libc.so.6(cfree+0x6d)[0xb761af8d] /lib/libc.so.6(+0x1829c)[0xb75c329c] /lib/libc.so.6(iconv_close+0x1c)[0xb75c27ec] ./Setup[0x821f6b9] ======= Memory map: ======== 08048000-082be000 r-xp 00000000 fe:00 1603797 /home/alex/src/network-2.2.1.5/Setup 082be000-082ed000 rwxp 00275000 fe:00 1603797 /home/alex/src/network-2.2.1.5/Setup 082ed000-082f0000 rwxp 00000000 00:00 0 08dbf000-08e4a000 rwxp 00000000 00:00 0 [heap] b6f00000-b6f21000 rwxp 00000000 00:00 0 b6f21000-b7000000 ---p 00000000 00:00 0 b70c8000-b70e5000 r-xp 00000000 08:03 385336 /usr/lib/libgcc_s.so.1 b70e5000-b70e6000 rwxp 0001c000 08:03 385336 /usr/lib/libgcc_s.so.1 b7100000-b7300000 rwxp 00000000 00:00 0 b7391000-b7591000 r-xp 00000000 08:03 396531 /usr/lib/locale/locale- archive b7591000-b7592000 rwxp 00000000 00:00 0 b7592000-b75a7000 r-xp 00000000 08:03 262160 /lib/libpthread-2.11.so b75a7000-b75a8000 r-xp 00014000 08:03 262160 /lib/libpthread-2.11.so b75a8000-b75a9000 rwxp 00015000 08:03 262160 /lib/libpthread-2.11.so b75a9000-b75ab000 rwxp 00000000 00:00 0 b75ab000-b76eb000 r-xp 00000000 08:03 262169 /lib/libc-2.11.so b76eb000-b76ed000 r-xp 00140000 08:03 262169 /lib/libc-2.11.so b76ed000-b76ee000 rwxp 00142000 08:03 262169 /lib/libc-2.11.so b76ee000-b76f1000 rwxp 00000000 00:00 0 b76f1000-b7715000 r-xp 00000000 08:03 262184 /lib/libm-2.11.so b7715000-b7716000 r-xp 00023000 08:03 262184 /lib/libm-2.11.so b7716000-b7717000 rwxp 00024000 08:03 262184 /lib/libm-2.11.so b7717000-b7718000 rwxp 00000000 00:00 0 b7718000-b7762000 r-xp 00000000 08:03 388239 /usr/lib/libgmp.so.3.5.0 b7762000-b7765000 rwxp 00049000 08:03 388239 /usr/lib/libgmp.so.3.5.0 b7765000-b7767000 r-xp 00000000 08:03 262188 /lib/libdl-2.11.so b7767000-b7768000 r-xp 00001000 08:03 262188 /lib/libdl-2.11.so b7768000-b7769000 rwxp 00002000 08:03 262188 /lib/libdl-2.11.so b7769000-b776b000 r-xp 00000000 08:03 262274 /lib/libutil-2.11.so b776b000-b776c000 r-xp 00001000 08:03 262274 /lib/libutil-2.11.so b776c000-b776d000 rwxp 00002000 08:03 262274 /lib/libutil-2.11.so b776d000-b7774000 r-xp 00000000 08:03 262277 /lib/librt-2.11.so b7774000-b7775000 r-xp 00006000 08:03 262277 /lib/librt-2.11.so b7775000-b7776000 rwxp 00007000 08:03 262277 /lib/librt-2.11.so b778c000-b778e000 r-xp 00000000 08:03 184559 /usr/lib/gconv/UTF-32.so b778e000-b778f000 r-xp 00001000 08:03 184559 /usr/lib/gconv/UTF-32.so b778f000-b7790000 rwxp 00002000 08:03 184559 /usr/lib/gconv/UTF-32.so b7790000-b7791000 rwxp 00000000 00:00 0 b7791000-b7792000 r-xp 00000000 00:00 0 [vdso] b7792000-b77ae000 r-xp 00000000 08:03 262276 /lib/ld-2.11.so b77ae000-b77af000 r-xp 0001b000 08:03 262276 /lib/ld-2.11.so b77af000-b77b0000 rwxp 0001c000 08:03 262276 /lib/ld-2.11.so bffe2000-bfff7000 rwxp 00000000 00:00 0 [stack] Aborted }}} Basically, a Setup script compiled with a different GHC than the one that Setup is using fails with a memory error. See attached file for {{{/usr/bin/ghc-pkg dump}}} output. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 23 21:23:39 2009 From: trac at galois.com (GHC) Date: Mon Nov 23 20:58:47 2009 Subject: [GHC] #3686: please remove huge ghc-tarballs/ Message-ID: <050.b4bccaf6c9a8808a0840e4e3f64c6887@localhost> #3686: please remove huge ghc-tarballs/ ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.12.1 RC1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Just prior to ghc-6.12 RC2 the ghc tarball sizes ballooned: {{{ -rw-r--r-- 7821334 2009-11-17 12:27 ghc-6.12.0.20091116-src.tar.bz2 -rw-r--r-- 7822080 2009-11-18 18:37 ghc-6.12.0.20091117-src.tar.bz2 -rw-r--r-- 25473470 2009-11-19 10:30 ghc-6.12.0.20091118-src.tar.bz2 -rw-r--r-- 22538103 2009-11-23 14:14 ghc-6.12.0.20091121-src.tar.bz2 }}} This is largely due to the addition of {{{ghc-tarballs/}}} and particularly {{{mingw/}}}. Can't {{{mingw/}}} and {{{perl/}}} go into a separate extra tarball for people who should want to build on Windows if the ghc project really needs to ship them? This addition really bloats the src distribution in a big way. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 24 05:26:06 2009 From: trac at galois.com (GHC) Date: Tue Nov 24 05:01:16 2009 Subject: [GHC] #706: GHC uses _stub.c files regardless of whether any 'foreign import' decls remain in a .hs file In-Reply-To: <055.48ae21f76b1442654d47b9fd49147ccc@localhost> References: <055.48ae21f76b1442654d47b9fd49147ccc@localhost> Message-ID: <064.89c86da5a269995fe3c984899971360e@localhost> #706: GHC uses _stub.c files regardless of whether any 'foreign import' decls remain in a .hs file -----------------------------------------+---------------------------------- Reporter: ncalexan@uci.edu | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (FFI) | Version: 6.4.1 Resolution: | Keywords: ffi, link Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Comment (by simonpj): Simon and I looked briefly at this: * The `mg_foreign` field of a `ModGuts` records the foreign-stub information * It would be straightforward to add a `Bool` to `ModIface` to record whether there were stubs * The only tricky bit is making use of that `ModIface` field to construct the right `hm_linkable` list of `Linkables`, recorded in `HomeModInfo`. So this is probably not hard to fix; just a bit fiddly to poke around and see what needs to be done. Any volunteers? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 24 05:32:00 2009 From: trac at galois.com (GHC) Date: Tue Nov 24 05:07:08 2009 Subject: [GHC] #451: GHC poor type-checker error message In-Reply-To: <050.1ad7d37d949f4e39b8c05bccbb5e4d15@localhost> References: <050.1ad7d37d949f4e39b8c05bccbb5e4d15@localhost> Message-ID: <059.9b94a58988db32a5419356a903dc5db5@localhost> #451: GHC poor type-checker error message --------------------------------------+------------------------------------- Reporter: isaacdupree | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.4 Resolution: wontfix | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: tcfail140 | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: None => wontfix Comment: I agree that the error message could be better, but fixing that is a research question. Unlike some of the other type-error-message tickets, this one is not egregiously awful, and I can't see a way to improve it much. So I think I'll close the ticket, not because it's vacuous, but because I can't see us fixing it in the forseeable future. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 24 07:17:23 2009 From: trac at galois.com (GHC) Date: Tue Nov 24 06:52:31 2009 Subject: [GHC] #3687: Merge _stub.o files back in to the .o file Message-ID: <051.5329623a4eddfae039053b6416bd32a2@localhost> #3687: Merge _stub.o files back in to the .o file ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ GHC sometimes generates _stub.o files. When it does, ghci doesn't work with compiled files (it forgets to include the _stub.o in the files to link against), and it complicates many building rules (including those inside GHC's makefile). It would be far better if the _stub.o files were merged back in with the original. This is actually reasonably easy: {{{ b <- doesFileExist stub when b $ do let tmp = res <.> "tmp.o" mv obj tmp exec ["ld","-r","-o",obj,tmp,stub] rm stub rm tmp }}} While being mainly a feature request, this enhancement also fixes a bug with GHCi loading files with _stub's, so includes a bug fix for free. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 24 08:15:02 2009 From: trac at galois.com (GHC) Date: Tue Nov 24 07:50:16 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.96ed2f1b308d8c3f469ad081b1f8decb@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris -----------------------------+---------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Os: Solaris | Testcase: Architecture: x86 | Failure: Building GHC failed -----------------------------+---------------------------------------------- Comment (by maeder): log.conf.2.gz was created by accidentally adding log.conf.gz twice (I cannot delete log.conf.2.gz now.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 24 08:22:56 2009 From: trac at galois.com (GHC) Date: Tue Nov 24 07:58:03 2009 Subject: [GHC] #706: GHC uses _stub.c files regardless of whether any 'foreign import' decls remain in a .hs file In-Reply-To: <055.48ae21f76b1442654d47b9fd49147ccc@localhost> References: <055.48ae21f76b1442654d47b9fd49147ccc@localhost> Message-ID: <064.77366df9c7f76e5b81c1e8bc5a061efd@localhost> #706: GHC uses _stub.c files regardless of whether any 'foreign import' decls remain in a .hs file -----------------------------------------+---------------------------------- Reporter: ncalexan@uci.edu | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler (FFI) | Version: 6.4.1 Resolution: | Keywords: ffi, link Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Comment (by igloo): See also #3687 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 24 08:23:01 2009 From: trac at galois.com (GHC) Date: Tue Nov 24 07:58:08 2009 Subject: [GHC] #3687: Merge _stub.o files back in to the .o file In-Reply-To: <051.5329623a4eddfae039053b6416bd32a2@localhost> References: <051.5329623a4eddfae039053b6416bd32a2@localhost> Message-ID: <060.2fea1aeaaaaf466bb2a1f3c70ccb870c@localhost> #3687: Merge _stub.o files back in to the .o file ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Comment: See also #706 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 24 08:31:13 2009 From: trac at galois.com (GHC) Date: Tue Nov 24 08:06:20 2009 Subject: [GHC] #3686: please remove huge ghc-tarballs/ In-Reply-To: <050.b4bccaf6c9a8808a0840e4e3f64c6887@localhost> References: <050.b4bccaf6c9a8808a0840e4e3f64c6887@localhost> Message-ID: <059.f8da31dfd4de96ddf5df682a0e37e908@localhost> #3686: please remove huge ghc-tarballs/ ---------------------------+------------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => Comment: I think the thing to do, if we do something, is to also make an 8M {{{ ghc-6.12.0.20091121-src-non-windows.tar.bz2 }}} Is the possible confusion outweighed by the 15M saving? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 24 12:27:12 2009 From: trac at galois.com (GHC) Date: Tue Nov 24 12:02:21 2009 Subject: [GHC] #451: GHC poor type-checker error message In-Reply-To: <050.1ad7d37d949f4e39b8c05bccbb5e4d15@localhost> References: <050.1ad7d37d949f4e39b8c05bccbb5e4d15@localhost> Message-ID: <059.b62d18eb8dfe64308cdf588facd08805@localhost> #451: GHC poor type-checker error message --------------------------------------+------------------------------------- Reporter: isaacdupree | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.4 Resolution: wontfix | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: tcfail140 | Architecture: Unknown/Multiple Failure: Other | --------------------------------------+------------------------------------- Comment (by isaacdupree): Indeed. I looked at it again. Now that I understand the general modus operandi of Hindley-Milner type inference, I see how it is far from obvious for the type-checker/inferrer/errorer how to make the judgments that I'd been hoping were straightforwards :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Nov 24 14:08:24 2009 From: trac at galois.com (GHC) Date: Tue Nov 24 13:43:32 2009 Subject: [GHC] #3688: getOptions'.parseLanguage(2) went past eof token Message-ID: <044.d2beced56a89b1d13579e33faca75a3a@localhost> #3688: getOptions'.parseLanguage(2) went past eof token ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Keywords: language pragma Os: Windows | Testcase: Architecture: x86 | Failure: GHCi crash ------------------------+--------------------------------------------------- Prelude> :l counter.hs : panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-mingw32): getOptions'.parseLanguage(2) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > The language pragma just contains: {-# LANGUAGE -fglasgow-exts #-} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 03:22:34 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 02:57:44 2009 Subject: [GHC] #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? In-Reply-To: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> References: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> Message-ID: <055.ec969d69264e4a4aea54aaafdc03708a@localhost> #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? ---------------------------+------------------------------------------------ Reporter: Aviator | Owner: judah Type: bug | Status: assigned Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by Aviator): > Do arrow keys work with ghci in your terminal? Yes. > If you run the following command in the shell, does it clear the screen? Yes. > If you run the following command, press the Home key, then press Return, what happens? Pasted output: {{{ aviator@aspire:~$ ghc -e getLine ^[OH "\ESCOH" aviator@aspire:~$ }}} > Finally, the haskeline library (which handles line-reading for ghci) has had several updates since ghc-6.10.4 was released. Can you confirm whether this problem still occurs with the most recent version of haskeline? Okay. I ran ghci-haskeline and the control buttons work! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 04:43:13 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 04:18:19 2009 Subject: [GHC] #3687: Merge _stub.o files back in to the .o file In-Reply-To: <051.5329623a4eddfae039053b6416bd32a2@localhost> References: <051.5329623a4eddfae039053b6416bd32a2@localhost> Message-ID: <060.ce23488da3e199893127814c388adfb3@localhost> #3687: Merge _stub.o files back in to the .o file ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by simonmar): I like this idea better than the fix in #706. Neil: I'm surprised that you say ghci forgets to link the _stub.o files, as far as I'm aware it should just pick up the _stub.o file if it exists (that's the #706 bug). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 04:48:05 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 04:23:18 2009 Subject: [GHC] #3681: hsc2hs wrapper script ignores default flags In-Reply-To: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> References: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> Message-ID: <051.2a15f4c3397722a26a5bcce801d063ec@localhost> #3681: hsc2hs wrapper script ignores default flags ---------------------------+------------------------------------------------ Reporter: nwn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by duncan): * difficulty: => Comment: Sorry, it's not clear to me from the description what the problem is exactly. What default flags? Can you give a concrete example and what you expect to happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 04:49:47 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 04:24:58 2009 Subject: [GHC] #3682: shared libraries not installed executable In-Reply-To: <050.74da172fa23f1ae1ddea30f8c8576c12@localhost> References: <050.74da172fa23f1ae1ddea30f8c8576c12@localhost> Message-ID: <059.f96b0c4d4ab316769be581ffd3fa5c97@localhost> #3682: shared libraries not installed executable -----------------------------+---------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by duncan): * difficulty: => Comment: Right, this is a Cabal issue. We'll want that patch in Cabal upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 04:54:52 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 04:29:58 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF In-Reply-To: <043.bc40a075329f7b63a53340629e65db0f@localhost> References: <043.bc40a075329f7b63a53340629e65db0f@localhost> Message-ID: <052.c77d142cac04de4fcd19cc077c2ff782@localhost> #3677: Optimizer creates stack overflow on filtered CAF ----------------------------+----------------------------------------------- Reporter: jpet | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Comment (by simonpj): Nice report, thanks. Here is a totally self-contained example: {{{ module Main(main) where main = mapM_ print (edi 0) edi :: Integer -> [Integer] edi x | x `mod` 10000000 == 0 = x : edi (x+1) | otherwise = edi (x+1) edi2 :: Integer -> [Integer] edi2 x | x `mod` 10000000 == 0 = x : y | otherwise = y where y = edi2 (x+1) }}} Works in a 1k stack with `edi`, but needs 95k for `edi2`. Two bugs here: * Stack squeezing isn't working right (Simon M will investigate) * The optimiser should probably convert one into the other anyway (Simon PJ will look) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 04:57:27 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 04:32:40 2009 Subject: [GHC] #3605: Dll's freeze with -threaded In-Reply-To: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> References: <051.1aad4f74c417c7c8dcc312c4764dd078@localhost> Message-ID: <060.1227cda5b661bd23a4284423ee7cf91c@localhost> #3605: Dll's freeze with -threaded ----------------------------+----------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:9 NeilMitchell]: > I had a few questions: > > Is calling {{{hs_init}}} or {{{startupHaskell}}} preferred? I've gone with {{{hs_init}}} because that's in the FFI spec, but the current examples have both (which is just confusing). I would use {{{hs_init}}}. The other one is (or should be) deprecated. > Section 11.6.1 (which I left alone) says "it will rewrite occurrence of -lHSfoo on the command line to -lHSfoo.dll". It's really not clear if it's rewriting -l''foo'' to -l''foo''.dll, or -lHS''foo'' to -lHS''foo''.dll - and similarly for the HScool line. Italics to indicate meta variables is very handy. I would also check if this is actually true. I can't immediately see any evidence for it in the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 06:18:24 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 05:53:31 2009 Subject: [GHC] #2979: better support for FFI C wrappers for macros in system headers In-Reply-To: <045.050d142d1954d12d764c4cd94c9c38c8@localhost> References: <045.050d142d1954d12d764c4cd94c9c38c8@localhost> Message-ID: <054.6aad1905d26142113192281898e3b164@localhost> #2979: better support for FFI C wrappers for macros in system headers ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by simonmar): See the thread here for some of the discussion regarding where the best place to put support for this is: * [http://www.haskell.org/pipermail/libraries/2009-August/012426.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 06:20:15 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 05:55:20 2009 Subject: [GHC] #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use In-Reply-To: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> References: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> Message-ID: <051.8caa804ff3c2b32e71d0b72d8032f626@localhost> #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use ---------------------------+------------------------------------------------ Reporter: nwn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by nwn): * summary: hsc2hs wrapper script ignores default flags => hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use Comment: The default flags means $HSC2HS_EXTRA in the script. On OS X, ghc can only build 32 bit binary, so hsc2hs should be operated to build 32bit binary. For example, when I install a package which will build some *.hsc files (e.g. network) with Cabal, I expect hsc2hs will be passed the flags to build 32bit binaries. But Cabal passes --cc flags to hsc2hs, so $HSC2HS_EXTRA's value becomes empty, hsc2hs goes wrong. Because gcc on OS X will build 64bit binary as default. And I think this is the problem about the wrapper script. My wrapper script will ignore $HSC2HS_EXTRA only when specified C compiler to use is not gcc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 07:02:33 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 06:37:38 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.43bd1441ae5652febcc2205abeb443b0@localhost> #3668: PIE-enabled hardened gcc might broke GHC. ---------------------------+------------------------------------------------ Reporter: secludedsage | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by secludedsage): @igloo: i talked to dcoutts and was told to ask you how you set the -optc-m32 stuff for OS X. He said that you will point me the right file to modify and to solve this problem. Thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 09:22:05 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 08:57:10 2009 Subject: [GHC] #3689: GHCi bug on too long input lines Message-ID: <048.d069c56a34d84d5b358ad0d33725dcfd@localhost> #3689: GHCi bug on too long input lines --------------------------+------------------------------------------------- Reporter: harry666t | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Keywords: Os: Linux | Testcase: Architecture: x86 | Failure: GHCi crash --------------------------+------------------------------------------------- This is probably a very strange thing to do, but when you put a really, really, really long line (mine was about 59000 characters long) in a file and try to load the module in ghci, you get an error message: ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): linkBCO: >= 64k insns in BCO The same thing happens when you paste a really long line in the terminal in an interactive GHCi shell. The bug seems to only affect ghci; the module compiles without problems with ghc. I'm using the GHC version from Debian Squeeze. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 09:33:11 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 09:08:21 2009 Subject: [GHC] #3689: GHCi bug on too long input lines In-Reply-To: <048.d069c56a34d84d5b358ad0d33725dcfd@localhost> References: <048.d069c56a34d84d5b358ad0d33725dcfd@localhost> Message-ID: <057.425d78a45c34fd58154d9b4f840fef2d@localhost> #3689: GHCi bug on too long input lines -------------------------+-------------------------------------------------- Reporter: harry666t | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Resolution: duplicate | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: GHCi crash | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => * resolution: => duplicate Comment: Thanks for the report. Happily, this is already fixed (#789). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 09:34:42 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 09:09:46 2009 Subject: [GHC] #3688: getOptions'.parseLanguage(2) went past eof token In-Reply-To: <044.d2beced56a89b1d13579e33faca75a3a@localhost> References: <044.d2beced56a89b1d13579e33faca75a3a@localhost> Message-ID: <053.b071d65c7ff698c1bccc68b705599d1f@localhost> #3688: getOptions'.parseLanguage(2) went past eof token -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Resolution: duplicate | Keywords: language pragma Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: GHCi crash | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => * resolution: => duplicate Comment: Thanks for the report. Happily, this is already fixed (#3212). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 11:07:13 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 10:42:19 2009 Subject: [GHC] #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use In-Reply-To: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> References: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> Message-ID: <051.50deea200de1361d11b355906209f327@localhost> #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use ---------------------------+------------------------------------------------ Reporter: nwn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by duncan): Ah yes ok. So the hsc2hs wrapper script is wrong because it drops the CC flags when the caller specifies where gcc is. Only if the caller does not specify the location of gcc will hsc2hs get called with the correct cc flags. There are probably several places this could be fixed. Longer term it's probably not reasonable for hsc2hs to be hard-coded to a particular target. In principle it should be possible to call it for either 32 or 64bit modes on hosts that support it (or possibly to use a cross- compiler). This suggests that perhaps it is the build managers (eg cabal) that should know which target is in use and then pass flags to tools as appropriate. In the mean time, ghc only supports 32bit on OSX, so it's probably ok to have the `HSC2HS_EXTRA` flags be unconditional. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 13:31:15 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 13:06:28 2009 Subject: [GHC] #3690: GHC panics on a crazy type signature Message-ID: <044.328d1eab731e87d6f2c4e738f2de5572@localhost> #3690: GHC panics on a crazy type signature -------------------------------+-------------------------------------------- Reporter: Alien | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.4 | Keywords: Os: Windows | Testcase: Architecture: x86_64 (amd64) | Failure: Compile-time crash -------------------------------+-------------------------------------------- {{{ x :: [Enum a => (forall a. Num a => a)] x = [] }}} I have NO idea what that would mean or whatever it makes sense at all, but it fails with: {{{ : panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-mingw32): TcTyFuns.flattenType: unexpected PredType }}} And it said I should report it. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 13:48:26 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 13:23:32 2009 Subject: [GHC] #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? In-Reply-To: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> References: <046.ed35e95be7a96e63b4b8b846d18fe80e@localhost> Message-ID: <055.79afc668066f7fdfe70f140cc7f84138@localhost> #3641: ^L Does Not Work Anymore in Interactive Mode for 6.10.x? ---------------------------+------------------------------------------------ Reporter: Aviator | Owner: judah Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by judah): * status: assigned => closed * resolution: => fixed Comment: OK, it sounds like your problems are all resolved by the new version of Haskeline. Since the relevant changes to that library will be used by ghc-6.12.1, I'm marking this as fixed. Please reopen if I misunderstood or if you find any similar problems with ghci-haskeline or ghc-6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 15:43:42 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 15:18:47 2009 Subject: [GHC] #3691: Error message doesn't mention necessary extension in warning Message-ID: <045.4e6de20074a753fbe79a2f142c50f383@localhost> #3691: Error message doesn't mention necessary extension in warning ---------------------------------+------------------------------------------ Reporter: arsenm | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect warning at compile-time ---------------------------------+------------------------------------------ In this example(Taken from [http://www.haskell.org/haskellwiki/GHC/AdvancedOverlap]) with the exception of removing -fglasgow-exts), GHC gives the wrong error message and fails to mention the missing necessary extension (which turns out to be ScopedTypeVariables). If you take the example, and remove -fglasgow-exts and try to only use the minimum required language extensions, {{{ {-# LANGUAGE EmptyDataDecls, MultiParamTypeClasses, FunctionalDependencies, OverlappingInstances, FlexibleInstances, UndecidableInstances #-} }}} GHC fails with the error {{{ wiki.hs:30:12: Could not deduce (Print' flag a) from the context (Print a, ShowPred a flag1, Print' flag1 a) arising from a use of `print'' at wiki.hs:30:12-35 Possible fix: add (Print' flag a) to the context of the instance declaration In the expression: print' (undefined :: flag) In the definition of `print': print = print' (undefined :: flag) In the instance declaration for `Print a' Failed, modules loaded: none. }}} However, it compiles fine if ScopedTypeVariables is added to the list of extensions. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 18:11:51 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 17:46:59 2009 Subject: [GHC] #3692: TcTyFuns.flattenType: unexpected PredType Message-ID: <043.b692713f9a8cc70230a5cc7f658ed0bf@localhost> #3692: TcTyFuns.flattenType: unexpected PredType -------------------------------+-------------------------------------------- Reporter: cdfh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: TcTyFuns PredType panic Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: Compile-time crash -------------------------------+-------------------------------------------- Hello, I've found a bug, however it may be a duplicate of one of these: #2846, #3272, #3592, #3125, #3102 (roughly in order of duplicate-likelihoodness). Here's the code: {{{ type Foo a b = () -> (Bar a => a) class Bar a where {} foo :: Foo a b foo = id (undefined :: Foo a b) }}} And the result of compilation: {{{ $ ghc -fglasgow-exts --make Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for x86_64-unknown-linux): TcTyFuns.flattenType: unexpected PredType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'm running Gentoo Linux, with dev-lang/ghc-6.10.4 (not dev-haskell /haskell-platform) {{{ Linux geneva 2.6.29-gentoo-r5 #1 SMP Sun Jul 12 03:16:58 BST 2009 x86_64 Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz GenuineIntel GNU/Linux }}} I'm afraid I've not tested this against HEAD, since I couldn't get it to build. Note that `foo = undefined :: Foo a b` does not cause GHC to panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Nov 25 20:27:56 2009 From: trac at galois.com (GHC) Date: Wed Nov 25 20:03:00 2009 Subject: [GHC] #414: GHC does not eforce that Main exports main In-Reply-To: <046.38fe8da23abfc42f9ad2cb0e14b8afda@localhost> References: <046.38fe8da23abfc42f9ad2cb0e14b8afda@localhost> Message-ID: <055.8c66c53f5dd47916d11b5bd0440c34a4@localhost> #414: GHC does not eforce that Main exports main ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.10.4 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: mod174 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by seanmcl): * failure: => None/Unknown * version: 6.4.1 => 6.10.4 Comment: Verified it's still a problem in 6.10.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 01:36:10 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 01:11:15 2009 Subject: [GHC] #3693: Show stack traces Message-ID: <043.7c288f8e774d3806292d73b1513892ec@localhost> #3693: Show stack traces ---------------------------------+------------------------------------------ Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Debugging stack overflows can be very difficult, because GHC gives very little information as to exactly what is overflowing. Showing a basic stack dump (on crash, or in the ghci debugger) would be enormously helpful. (Entered after spending two days trying to determine the cause of a stack overflow, before discovering it was a GHC bug [3677], which would have been apparent immediately if I could have only seen a callstack.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 02:00:42 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 01:35:47 2009 Subject: [GHC] #3694: Image link in User's Guide is broken Message-ID: <042.4dce51a64fcceef53092b64072938194@localhost> #3694: Image link in User's Guide is broken ---------------------------------+------------------------------------------ Reporter: jli | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ In section 5.1.1 "Inserting cost centres by hand" of the user's guide, there's an image of a heap profile, but the image doesn't exist. section 5.1.1: http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html#id514538 image link: http://www.haskell.org/ghc/docs/latest/html/users_guide/prof_scc -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 03:33:25 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 03:08:28 2009 Subject: [GHC] #3687: Merge _stub.o files back in to the .o file In-Reply-To: <051.5329623a4eddfae039053b6416bd32a2@localhost> References: <051.5329623a4eddfae039053b6416bd32a2@localhost> Message-ID: <060.78a6938f2a2fb6cb4ccfb1b0f16715be@localhost> #3687: Merge _stub.o files back in to the .o file ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by NeilMitchell): I've got flags like hidir/odir and hisuf/osuf set, so my guess is it's not honouring one of those (probably osuf). I can figure out a test case for that, or if you're just going to merge the _stub.o, I won't need to. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 05:29:14 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 05:04:16 2009 Subject: [GHC] #3687: Merge _stub.o files back in to the .o file In-Reply-To: <051.5329623a4eddfae039053b6416bd32a2@localhost> References: <051.5329623a4eddfae039053b6416bd32a2@localhost> Message-ID: <060.bd5015844d2233d77e10985834b7d5ff@localhost> #3687: Merge _stub.o files back in to the .o file ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by simonmar): I'd appreciate the test case - it may indicate a bug that we need to fix anyway. I'm surprised, since GHC uses the same code find files regardless of what mode it's running in, so the behaviour of -osuf etc. should be exactly the same with GHCi as it is with --make. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 05:33:24 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 05:08:25 2009 Subject: [GHC] #3496: GHC panic while building the base library with Cabal In-Reply-To: <047.5c600ae82cf71150830a6ede7f6640ea@localhost> References: <047.5c600ae82cf71150830a6ede7f6640ea@localhost> Message-ID: <056.1a9cce05d4794753fd30dc98324e2395@localhost> #3496: GHC panic while building the base library with Cabal ---------------------------+------------------------------------------------ Reporter: elliottt | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * owner: => simonmar * failure: => None/Unknown Comment: I'll look into this sometime. Could indicate a real problem somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 05:33:43 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 05:08:45 2009 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@localhost> References: <043.7c288f8e774d3806292d73b1513892ec@localhost> Message-ID: <052.4e191e76bcf3f536492c8a0cb2143dfe@localhost> #3693: Show stack traces ------------------------------+--------------------------------------------- Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Changes (by simonmar): * difficulty: => * milestone: => _|_ Comment: Stack traces are difficult to implement, which is why there isn't one. See e.g. ExplicitCallStack. I've been pondering the use of HPC to generate some tracing information though, possibly for feeding into ThreadScope. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 05:35:23 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 05:10:25 2009 Subject: [GHC] #3571: Bizzarely bloated binaries In-Reply-To: <044.a58781a47fed5e173c154c742b96ee46@localhost> References: <044.a58781a47fed5e173c154c742b96ee46@localhost> Message-ID: <053.d0805280edd1fc194dcb1297a2367b9b@localhost> #3571: Bizzarely bloated binaries ---------------------------+------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * failure: => None/Unknown * milestone: 6.12 branch => 6.12.2 Comment: Let's investigate this for 6.12.2. It's probably normal, but we ought to discover why it's happening and record the knowledge somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 06:26:52 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 06:01:54 2009 Subject: [GHC] #3674: Recognise language pragmas generated by custom pre-processors (run with -F) In-Reply-To: <047.f133953f7994cae1dfd3e6f2c8e5d7e7@localhost> References: <047.f133953f7994cae1dfd3e6f2c8e5d7e7@localhost> Message-ID: <056.9023d3c8fb1fa67f5a8ba0e8b02dc565@localhost> #3674: Recognise language pragmas generated by custom pre-processors (run with -F) -----------------------------------------+---------------------------------- Reporter: dorchard | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Driver | Version: Resolution: | Keywords: customer pre-processor Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | -----------------------------------------+---------------------------------- Changes (by simonmar): * owner: dorchard => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 07:31:08 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 07:06:09 2009 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@localhost> References: <043.7c288f8e774d3806292d73b1513892ec@localhost> Message-ID: <052.70df914f608a0df192e75481c3bb418e@localhost> #3693: Show stack traces ------------------------------+--------------------------------------------- Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by guest): Might it be easy to get non-lexical call stacks? That way you could at least see the chain of "case" statements that forced the thunk producing an error. And some information is better than none at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 10:05:07 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 09:40:08 2009 Subject: [GHC] #3691: Error message doesn't mention necessary extension in warning In-Reply-To: <045.4e6de20074a753fbe79a2f142c50f383@localhost> References: <045.4e6de20074a753fbe79a2f142c50f383@localhost> Message-ID: <054.a0af86e0fab992abb9e839e6bdc85f28@localhost> #3691: Error message doesn't mention necessary extension in warning ------------------------------------------------+--------------------------- Reporter: arsenm | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: invalid | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Changes (by simonpj): * status: new => closed * difficulty: => * resolution: => invalid Comment: The error message looks right to me. GHC can't deduce `(Print' flag a)` from `(Print' flag1 a)`. You may ask why it doesn't choose `flag1` to be equal to `flag`. It doesn't because it's too hard for the type inference engine to do. The declaration {{{ instance (ShowPred a flag, Print' flag a) => Print a where print = print' (undefined::flag) }}} tries to do so, by using "`flag`" in both places, but under Haskell 98 rules the type signature on `undefined` means `undefined :: forall flag. flag`, and that is not what you want. So the language extensions you supplied are not "the minimum required"; you need `ScopedTypeVariables`. I've modified the HaskellWiki page to use LANGUAGE pragmas. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 10:22:58 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 09:57:59 2009 Subject: [GHC] #3691: Error message doesn't mention necessary extension in warning In-Reply-To: <045.4e6de20074a753fbe79a2f142c50f383@localhost> References: <045.4e6de20074a753fbe79a2f142c50f383@localhost> Message-ID: <054.bfb820e870db8efca6b8b419d4697d8a@localhost> #3691: Error message doesn't mention necessary extension in warning ------------------------------------------------+--------------------------- Reporter: arsenm | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: invalid | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Comment (by arsenm): However, the bug I was thinking was more along the lines of it doesn't tell you that you need this language extension to make it work, and not that you shouldn't need ScopedTypeVariables. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 10:34:18 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 10:09:18 2009 Subject: [GHC] #3691: Error message doesn't mention necessary extension in warning In-Reply-To: <045.4e6de20074a753fbe79a2f142c50f383@localhost> References: <045.4e6de20074a753fbe79a2f142c50f383@localhost> Message-ID: <054.99fe6a68fd05723aa686167d477bcb79@localhost> #3691: Error message doesn't mention necessary extension in warning ------------------------------------------------+--------------------------- Reporter: arsenm | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: invalid | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Comment (by simonpj): Maybe I should change the resolution to "wontfix", then, because I have no idea how to suggest the correct extension. I suppose GHC could warn you if the behaviour might change if you added `ScopedTypeVariables`, and suggest that you either add the flag, or use a different type variable name. But that could result in hard-to-understand warnings about perfectly reasonable Haskell 98 programs. Example: {{{ class C a where op :: a -> a op x = ....(foo :: a->a).... }}} This would provoke the warning, since the type signature for 'foo' mentions 'a' which (were you to use `ScopedTypeVariables` would mean the `a` in the class header. Hmm. If people thing this is valuable, it would not be hard to implement. If so, please re-open this ticket as a feature request. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 11:04:41 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 10:39:42 2009 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@localhost> References: <043.7c288f8e774d3806292d73b1513892ec@localhost> Message-ID: <052.467944da76996d175026cc7e0b459089@localhost> #3693: Show stack traces ------------------------------+--------------------------------------------- Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by jpet): The linked-to proposals and discussion are mostly about generating what the stack "would be" if evaluation order had been strict. I'm suggesting what the previous comment does, something much simpler (and IMHO much more useful)--I want to see a dump of the actual stack that actually exists in memory. Walking these stacks is easy, well-defined, and portable; the only obvious obstacle seems to be annotating code with source line and file info. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 12:41:42 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 12:16:44 2009 Subject: [GHC] #3690: GHC panics on a crazy type signature In-Reply-To: <044.328d1eab731e87d6f2c4e738f2de5572@localhost> References: <044.328d1eab731e87d6f2c4e738f2de5572@localhost> Message-ID: <053.c40fe5f26511f6f56c71df357d70df60@localhost> #3690: GHC panics on a crazy type signature --------------------------------------+------------------------------------- Reporter: Alien | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86_64 (amd64) Failure: Compile-time crash | --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => * resolution: => fixed Comment: Thanks for the report. It's fixed in 6.12 and HEAD {{{ sh$ ghc-6.12.0.20091011 -c T3690.hs -XRankNTypes -XFlexibleContexts T3690.hs:1:0: Illegal polymorphic or qualified type: (Enum a) => forall a. (Num a) => a Perhaps you intended to use -XImpredicativeTypes In the type signature for `x': x :: [(Enum a) => (forall a. (Num a) => a)] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 12:59:37 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 12:34:38 2009 Subject: [GHC] #3691: Error message doesn't mention necessary extension in warning In-Reply-To: <045.4e6de20074a753fbe79a2f142c50f383@localhost> References: <045.4e6de20074a753fbe79a2f142c50f383@localhost> Message-ID: <054.3108d1c4a56b3e9bf856ecfdbb9aa413@localhost> #3691: Error message doesn't mention necessary extension in warning ------------------------------------------------+--------------------------- Reporter: arsenm | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Changes (by isaacdupree): * status: closed => reopened * type: bug => feature request * resolution: invalid => Comment: Simon, I think that would be valuable 1) because people might turn on ScopedTypeVariables for some other reason (it's not such a wild extension) and then get confused at the type error 2) because when reading code, it's hard enough to figure out how all the type-variable scoping works -- and twice as hard when you need to understand two different rules that might be in effect. do others agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 15:31:06 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 15:06:11 2009 Subject: [GHC] #3695: GHC-6.12.1-RC2-20091121 build fails when using stage-1 compiler Message-ID: <048.637bc11df320fbea10c8c8161b9f7491@localhost> #3695: GHC-6.12.1-RC2-20091121 build fails when using stage-1 compiler ---------------------------+------------------------------------------------ Reporter: jberthold | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.12.1 RC1 | Keywords: Os: Solaris | Testcase: Architecture: sparc | Failure: Building GHC failed ---------------------------+------------------------------------------------ When trying to build RC2 (20091121) under Solaris 10, I encountered the following error when building the ghc-prim with the stage-1 compiler: ... previous output containing many of these: {{{ /bin/sh: syntax error at line 1: `;' unexpected}}} Then {{{ "inplace/bin/ghc-stage1" -H32m -O -package-name ghc-prim-0.2.0.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist- install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist- install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/autogen/cabal_macros.h -package rts-1.0 -split-objs -package-name ghc-prim -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/ghc-prim/./GHC/Types.hs -o libraries/ghc-prim/dist- install/build/GHC/Types.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 6.12.0.20091121 for sparc-sun-solaris2): Error in array index Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1 make: *** [all] Error 2 }}} Additional information: To get this far, I built from source and installed the following libraries (in custom locations): gcc-4.1.2, gmp-4.3.1, autoconf-2.64, automake-1.11, libiconv-1.11, m4-1.4.12, make-3.81, ncurses-5.7, readline-5.2, sed-4.2.1. Before installing the sed-4.2.1, I hit another error, described in [/trac/ghc/ticket/3683] . This ticket also describes the messages about the {{{';' unexpected}}}. Before failing on GHC/Types.hs, the stage-1 compiler compiled one file, GHC/Generics.hs, and generated dependencies in various packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 15:35:17 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 15:10:31 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.d10628897f671d049935c3f231eb789f@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ---------------------------------+------------------------------------------ Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Os: Solaris | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed ---------------------------------+------------------------------------------ Changes (by jberthold): * cc: berthold@diku.dk (added) * architecture: x86 => Unknown/Multiple Comment: I can confirm one of the above symptoms under Sparc/Solaris 5.10, and fix the other. I tested with 6.12.1 RC2 (downloaded from http://www.haskell.org/ghc/dist/6.12.1-rc2/ ), which has no tag yet. The {{{/bin/sh: syntax error at line 1: `;' unexpected }}} is the same for me. I could '''fix the second error''' by installing my own sed from source (sed-4.2.1), it is related to missing preprocessor support in the stage-1 compiler (no -XCPP, thus fails on first #include encountered). After fixing this failure, however, I hit another one, described separately in [/trac/ghc/ticket/3695] . -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 18:57:41 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 18:32:45 2009 Subject: [GHC] #3696: Incorrect type inferred with -fwarn-missing-signatures and a type class Message-ID: <042.114a9e9c46098b4fa4159f581cedcf51@localhost> #3696: Incorrect type inferred with -fwarn-missing-signatures and a type class ---------------------------------+------------------------------------------ Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Incorrect warning at compile-time ---------------------------------+------------------------------------------ The inferred type using -fwarn-missing-signatures and a type class is too general for top-level values. Here is a simplified example: {{{ {-# OPTIONS -Wall #-} class C a where c :: a instance C Int where c = 37 def = c use :: Int use = def }}} The inferred type reported by GHCi when -fwarn-missing-signatures is enabled is: {{{ Ex.hs:7:0: Warning: Definition but no type signature for `def' Inferred type: def :: a }}} The most general possible type here is {{{C a => a}}}. When asking GHCi for the type of {{{def}}}, it reports {{{Int}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 19:21:55 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 18:56:54 2009 Subject: [GHC] #3697: Method selectors aren't floated out of loops Message-ID: <041.f5e0d472d08f4dccb3e0fe41dd7a6eba@localhost> #3697: Method selectors aren't floated out of loops ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.13 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ Here is a small example: {{{ foo :: Num a => [a] -> [a] foo as = filter (/=0) (map (\x -> x-x) as) }}} Here is the code that the current HEAD generates for the loop: {{{ go_smy = \ (ds_akN :: [a_aiw]) -> case ds_akN of _ { [] -> GHC.Types.[] @ a_aiw; : y_akS ys_akT -> let { x_smA :: a_aiw x_smA = GHC.Num.- @ a_aiw $dNum_ajk y_akS y_akS } in case GHC.Classes./= @ a_aiw lvl_smu x_smA lit_smw of _ { GHC.Bool.False -> go_smy ys_akT; GHC.Bool.True -> GHC.Types.: @ a_aiw x_smA (go_smy ys_akT) } }}} Note that the `Eq` dictionary is inspected by `(/=)` in every loop iteration. Floating out `GHC.Classes./= @ a_aiw lvl_smu` (and, perhaps, `GHC.Num.- @ a_aiw $dNum_ajk`) should solve this. In fact, I wonder why that isn't happening already. Do method selectors have a wrong arity? FWIW, in GHC 6.10 `LiberateCase` moves the method selection out of the loop (not ideal, but it gets the job done) so !NoSlow shows this as a slight performance regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 26 23:36:35 2009 From: trac at galois.com (GHC) Date: Thu Nov 26 23:11:34 2009 Subject: [GHC] #3698: Bad code generated for zip/filter/filter loop Message-ID: <041.1bc18587ecffea6f67a927d7ce3ba4be@localhost> #3698: Bad code generated for zip/filter/filter loop ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.13 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ Here is the program: {{{ zip_filter :: (Num a, Ord a) => a -> [a] -> [a] -> [a] zip_filter x as bs = zipWith (+) (filter ( GHC.Types.[] @ a_aiz T.zip_filter = \ (@ a_aiz) $dNum_ajm $dOrd_ajn eta_B3 eta_B2 eta_B1 -> letrec { go_smr :: [a_aiz] -> [a_aiz] -> [a_aiz] go_smr = \ (ds_ak5 :: [a_aiz]) -> case ds_ak5 of _ { [] -> poly_z_smp @ a_aiz; : y_aka ys_akb -> let { r_smt :: [a_aiz] -> [a_aiz] r_smt = go_smr ys_akb } in case GHC.Classes.< @ a_aiz $dOrd_ajn y_aka eta_B3 of _ { GHC.Bool.False -> r_smt; GHC.Bool.True -> \ (ds_alR :: [a_aiz]) -> case ds_alR of _ { [] -> GHC.Types.[] @ a_aiz; : y_alW ys_alX -> GHC.Types.: @ a_aiz (GHC.Num.+ @ a_aiz $dNum_ajm y_aka y_alW) (r_smt ys_alX) } } }; } in go_smr eta_B2 (GHC.List.filter @ a_aiz (\ (ds_djz :: a_aiz) -> GHC.Classes.< @ a_aiz $dOrd_ajn ds_djz eta_B3) eta_B1) }}} Eta-expanding `go_smr` would result in much better code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 03:36:30 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 03:11:28 2009 Subject: [GHC] #3698: Bad code generated for zip/filter/filter loop In-Reply-To: <041.1bc18587ecffea6f67a927d7ce3ba4be@localhost> References: <041.1bc18587ecffea6f67a927d7ce3ba4be@localhost> Message-ID: <050.b2b0b2a318a901d6e84a06b7e10e992b@localhost> #3698: Bad code generated for zip/filter/filter loop ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ Comment (by guest): Another instance of the irritating arity fixpoint thing. See also #2762, #2902 and stuff at the top of http://hackage.haskell.org/trac/ghc/wiki/Status/SLPJ-Tickets However, even if we had arity fixpoint detection, your function won't get eta-expanded. Reason: GHC.Classes.< might select an expensive operation from the dictionary. If this is the case then you might repeat tons of work. So to eta-expand safely you would need to also detect that go_smr is only ever used applied with a particular ds_ak5. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 03:38:00 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 03:12:58 2009 Subject: [GHC] #3691: Error message doesn't mention necessary extension in warning In-Reply-To: <045.4e6de20074a753fbe79a2f142c50f383@localhost> References: <045.4e6de20074a753fbe79a2f142c50f383@localhost> Message-ID: <054.b32e725c059007220e06f5b8e3ead946@localhost> #3691: Error message doesn't mention necessary extension in warning ------------------------------------------------+--------------------------- Reporter: arsenm | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Comment (by simonpj): OK. But the proposal is: * If `ScopedTypeVariables` is ''off'', you get warnings in situations where something different would happen if you switched it ''on''. Specifically, in situations where you mention a type variable 'a' that would be in scope from some outer binding if `ScopedTypeVariables` was on. The main example is two comments above this one. Another would be {{{ {-# LANGUAGE RankNTypes #-} f :: forall a. f x = ....(foo :: a -> a)... }}} Here the `forall a` would bring 'a' into scope if you had `ScopedTypeVariables`, and hence you'd get a warning on the type signature for `foo` because it mentions 'a'. I don't understand how your (1) and (2) relate to this proposed new behaviour. It just adds a new warning, and one that concerns an extension that the user might never have heard of, so I think it's arguable that any such warning might itself be confusing. But it's the users who matter here. What do you think? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 04:33:26 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 04:08:24 2009 Subject: [GHC] #3698: Bad code generated for zip/filter/filter loop In-Reply-To: <041.1bc18587ecffea6f67a927d7ce3ba4be@localhost> References: <041.1bc18587ecffea6f67a927d7ce3ba4be@localhost> Message-ID: <050.f2463adc20a68cf8107cad7107829fc9@localhost> #3698: Bad code generated for zip/filter/filter loop ---------------------------------+------------------------------------------ Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Runtime performance bug ---------------------------------+------------------------------------------ Comment (by rl): Hmm, yes, I guess it would be good to detect that, too. FWIW, essentially the same code is generated if we make `zip_filter` monomorphic: {{{ zip_filter :: Double -> [Double] -> [Double] -> [Double] }}} Here, we know what `(<)` is so we don't have to detect this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 05:01:10 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 04:36:09 2009 Subject: [GHC] #3699: Wildcards in type functions Message-ID: <060.b01af1dc1c462193a392550aa45e1d6c@localhost> #3699: Wildcards in type functions --------------------------------------+------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown --------------------------------------+------------------------------------- I would like to be able to use wildcards in type synonym family instances, so that I can write: {{{ type instance ErrorAlg (f :>: _) e a = ErrorAlg f e a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 05:29:39 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 05:04:40 2009 Subject: [GHC] #3697: Method selectors aren't floated out of loops In-Reply-To: <041.f5e0d472d08f4dccb3e0fe41dd7a6eba@localhost> References: <041.f5e0d472d08f4dccb3e0fe41dd7a6eba@localhost> Message-ID: <050.299e81deef747b6164e3c2e6bb434b25@localhost> #3697: Method selectors aren't floated out of loops --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Runtime performance bug | --------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => Comment: It's hard to know what the right thing to do here is. At the moment GHC treats `(op d)` as cheap, where `op` is a class operation and `d` is a dictionary. If we don't, we get lots of {{{ f = \d. let h1 = op1 d in \x. ...(h1 x)... }}} So 'f' gets arity 1. And indeed there is some sharing that would be gotten if you had `map (f dInt) xs`, because the selection from `dInt` would happen just once. But in general it's much better to have one function with arity 2 rather than two functions of arity 1. Same thing for a recursive function. If method selection isn't cheap you get lots of {{{ f = \d. let h1 = op1 d in letrec fr = \x. ...(h1 x)...fr x'... in fr }}} If you inline `h1`, we can make `f` have arity 2. So it's a hard call. I suppose that what we ultimately want is: share the method selection if doing so doesn't decrease arity. That could be done by running float-out near the end of optimisation (which it is) with a few twiddles to seek out those method selections. Worth thinking about. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 05:34:59 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 05:10:00 2009 Subject: [GHC] #3700: Being instance of Monoid is not checked Message-ID: <044.de9e3766af280c3cbcb7060720546c65@localhost> #3700: Being instance of Monoid is not checked ------------------------+--------------------------------------------------- Reporter: boris | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.3 | Keywords: Monoid, Writer Os: Windows | Testcase: Architecture: x86 | Failure: Other ------------------------+--------------------------------------------------- It is possible pass not only instances of Monoid to tell function and load the file with GHCi. GHCi shows type f :: (MonadWriter ((a -> b) -> [a] -> [b]) m) => t -> m () {{{ f _ = tell map }}} However, if code is {{{ f = tell map }}} GHCi shows type error(no instance) as expected. It seems very strange that type correctness depends on number of parameters for function that is not used anywhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 05:40:00 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 05:14:59 2009 Subject: [GHC] #3677: Optimizer creates stack overflow on filtered CAF In-Reply-To: <043.bc40a075329f7b63a53340629e65db0f@localhost> References: <043.bc40a075329f7b63a53340629e65db0f@localhost> Message-ID: <052.bea903ff142436482b8fbc8c0bbcfa6e@localhost> #3677: Optimizer creates stack overflow on filtered CAF ----------------------------+----------------------------------------------- Reporter: jpet | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Windows Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonpj * milestone: 6.12 branch => 6.12.2 Comment: Fixed the RTS bit: {{{ Wed Nov 25 04:59:17 PST 2009 Simon Marlow * threadStackOverflow: check whether stack squeezing released some stack (#3677) In a stack overflow situation, stack squeezing may reduce the stack size, but we don't know whether it has been reduced enough for the stack check to succeed if we try again. Fortunately stack squeezing is idempotent, so all we need to do is record whether *any* squeezing happened. If we are at the stack's absolute -K limit, and stack squeezing happened, then we try running the thread again. We also want to avoid enlarging the stack if squeezing has already released some of it. However, we don't want to get into a pathalogical situation where a thread has a nearly full stack (near its current limit, but not near the absolute -K limit), keeps allocating a little bit, squeezing removes a little bit, and then it runs again. So to avoid this, if we squeezed *and* there is still less than BLOCK_SIZE_W words free, then we enlarge the stack anyway. M ./includes/rts/Constants.h +7 M ./rts/Schedule.c -1 +31 M ./rts/ThreadPaused.c +5 }}} Ian: please merge. Simon PJ will investigate whether any simplifier changes are needed here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 05:41:45 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 05:16:45 2009 Subject: [GHC] #2978: Add support for more characters to UnicodeSyntax In-Reply-To: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> References: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> Message-ID: <054.b1e6d28159cb27ae0d32419bc0dc04f0@localhost> #2978: Add support for more characters to UnicodeSyntax ---------------------------+------------------------------------------------ Reporter: porges | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * failure: => None/Unknown * type: feature request => merge Comment: pushed: {{{ Fri Sep 18 06:03:33 PDT 2009 Simon Marlow * Apply patch from #2978: add more Unicode syntax Wed Nov 25 07:36:49 PST 2009 Simon Marlow * add docs for Unicode entities in #2978 }}} we could sneak this into 6.12.1, or otherwise it will have to wait until 6.14.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 09:17:09 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 08:52:09 2009 Subject: [GHC] #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks In-Reply-To: <052.f949c738ea0d9d2b66116addc98fdaed@localhost> References: <052.f949c738ea0d9d2b66116addc98fdaed@localhost> Message-ID: <061.57cbda868f712842e40728a81ad79756@localhost> #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks -----------------------------+---------------------------------------------- Reporter: andrewbirkett | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Fixed (libraries/base): {{{ Wed Nov 25 06:38:22 PST 2009 Simon Marlow * check for size < 0 in mallocForeignPtrBytes and friends (#3514) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 09:58:37 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 09:33:48 2009 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@localhost> References: <047.8e9c859b4db83c0d687094f53af0d886@localhost> Message-ID: <056.967797823ccd825f7e5cbb3b4bddc2df@localhost> #393: functions without implementations -----------------------------------------+---------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: None Resolution: None | Keywords: Difficulty: Moderate (less than a day) | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------------------+---------------------------------- Changes (by simonmar): * difficulty: Easy (less than 1 hour) => Moderate (less than a day) * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 10:08:49 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 09:43:46 2009 Subject: [GHC] #3691: Error message doesn't mention necessary extension in warning In-Reply-To: <045.4e6de20074a753fbe79a2f142c50f383@localhost> References: <045.4e6de20074a753fbe79a2f142c50f383@localhost> Message-ID: <054.5d334e84827c5f97bc18b01917f209db@localhost> #3691: Error message doesn't mention necessary extension in warning ------------------------------------------------+--------------------------- Reporter: arsenm | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Comment (by arsenm): What if there were only a suggestion (perhaps you meant to use ScopedTypeVariables??) if there is some type error concerning a type you use the same name for when it would have been out of scope. For instances, in the example, it complains that it can't deduce (Print a, ShowPred a flag1, Print' flag1 a), but it suggests adding (Print' flag a). In this situation at least, I think it would make sense to see that you tried to use the same name "flag" in 2 places, and the name "flag" was a problem in type checking then it might be a good suggestion. If everything is fine without it, then the warning might be unnecessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 10:32:59 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 10:07:58 2009 Subject: [GHC] #3691: Error message doesn't mention necessary extension in warning In-Reply-To: <045.4e6de20074a753fbe79a2f142c50f383@localhost> References: <045.4e6de20074a753fbe79a2f142c50f383@localhost> Message-ID: <054.73423d8b9c94135fe3d94740006e629c@localhost> #3691: Error message doesn't mention necessary extension in warning ------------------------------------------------+--------------------------- Reporter: arsenm | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Comment (by simonpj): That's a pretty complicated rule. It'd be hard to say precisely when it would "fire", and very far from certain that adding `ScopedTypeVariables` would fix the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 11:47:59 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 11:22:57 2009 Subject: [GHC] #418: throwTo to a thread inside 'block' In-Reply-To: <044.bf7a58746fbda955e298abdfd4e1a463@localhost> References: <044.bf7a58746fbda955e298abdfd4e1a463@localhost> Message-ID: <053.dc9b1c206ada3682e5f780f42755c499@localhost> #418: throwTo to a thread inside 'block' -----------------------------+---------------------------------------------- Reporter: remit | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * failure: => None/Unknown Comment: This bug is still present; I can't think of an easy way to fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 11:48:12 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 11:23:11 2009 Subject: [GHC] #418: throwTo to a thread inside 'block' In-Reply-To: <044.bf7a58746fbda955e298abdfd4e1a463@localhost> References: <044.bf7a58746fbda955e298abdfd4e1a463@localhost> Message-ID: <053.d73538f9fe215ffe4dc5e67ad13c90a7@localhost> #418: throwTo to a thread inside 'block' ------------------------------------------+--------------------------------- Reporter: remit | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 6.4.1 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | ------------------------------------------+--------------------------------- Changes (by simonmar): * failure: None/Unknown => Incorrect result at runtime -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 12:05:31 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 11:40:29 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.046150e4f460c0bef171baab80a3660b@localhost> #3668: PIE-enabled hardened gcc might broke GHC. ---------------------------+------------------------------------------------ Reporter: secludedsage | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by secludedsage): * status: new => closed * resolution: => fixed Comment: sed -i -e "s|wrapped|wrapped ${GHC_CFLAGS}|" ${S}/ghc/ghc.wrapper" This solve it. It is a wrapper problem which is somehow Gentoo specific. Thanks for igloo. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 13:15:36 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 12:50:34 2009 Subject: [GHC] #3668: PIE-enabled hardened gcc might broke GHC. In-Reply-To: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> References: <051.fc2bc37dc406e40bf1e5b1d4649c850b@localhost> Message-ID: <060.ceaefa40fa24c853139900b8dbac8621@localhost> #3668: PIE-enabled hardened gcc might broke GHC. ---------------------------+------------------------------------------------ Reporter: secludedsage | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by simonpj): Great that this is unblocked, but is there anything we should do to GHC or its build system to stop it happening again? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 27 14:10:21 2009 From: trac at galois.com (GHC) Date: Fri Nov 27 13:45:19 2009 Subject: [GHC] #3691: Error message doesn't mention necessary extension in warning In-Reply-To: <045.4e6de20074a753fbe79a2f142c50f383@localhost> References: <045.4e6de20074a753fbe79a2f142c50f383@localhost> Message-ID: <054.2bd7a336fb9b4492fdb554ea5755c652@localhost> #3691: Error message doesn't mention necessary extension in warning ------------------------------------------------+--------------------------- Reporter: arsenm | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Comment (by isaacdupree): Hmm, I think my reasoning is that we *should* discourage people from doing the thing that (Simon's) proposed warning is about. Because it has the potential to be confusing to people. (In two circumstances. "2" is: confusing to people who read the code, who know about !ScopedTypeVariables (and may or may not understand the Haskell98 behavior!), and, being human, they don't remember to check the LANGUAGE pragma/.cabal/makefile to discover correctly whether the extension is in effect. "1" is: confusing for people who copy/paste code or who turn on !ScopedTypeVariables for some other reason, and then have to understand a type error and fix it then by alpha-renaming. I think it would make more sense to warn earlier and make the code get "fixed" while it's being written. Also because, I think it's likely that an average/newish Haskell programmer writing such code was trying to get scoped tyvar behavior and didn't realize that they needed to turn on a flag. ) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 28 14:31:16 2009 From: trac at galois.com (GHC) Date: Sat Nov 28 14:06:12 2009 Subject: [GHC] #3685: "double free or corruption" error when running Setup.hs with other GHC in PATH In-Reply-To: <042.d3a505caff2f54b3cc2a8c83ae993cb8@localhost> References: <042.d3a505caff2f54b3cc2a8c83ae993cb8@localhost> Message-ID: <051.9ed08a1bcd4c7c56cc0b4c035d6b30ac@localhost> #3685: "double free or corruption" error when running Setup.hs with other GHC in PATH ----------------------------+----------------------------------------------- Reporter: ajd | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => * type: bug => merge * owner: => igloo * milestone: => 6.12.1 Comment: Fixed {{{ Wed Nov 25 04:34:35 PST 2009 Simon Marlow * hGetContents: close the handle properly on error Ignore-this: bc37ff678acc6e547dc390285e056eb9 When hGetContents caught an error it was closing the handle and then throwing the exception, without updating the handle with the new closed state. This lead to a double-closed, which was the cause of *** glibc detected *** ./Setup: double free or corruption when iconv_close was called twice on the decoder. See http://hackage.haskell.org/trac/hackage/ticket/609 M ./GHC/IO/Handle/Text.hs -5 +9 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 28 15:42:07 2009 From: trac at galois.com (GHC) Date: Sat Nov 28 15:17:01 2009 Subject: [GHC] #3701: allow existential wrapper newtypes Message-ID: <045.840f456f2d890bcf682319446631153e@localhost> #3701: allow existential wrapper newtypes ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Consider this OO-style thing, a class Compiler, and a most general instance MkCompiler: {{{ class Compiler c where getInstalledPackages :: c -> IO [String] data GHC = GHC { } data NHC = NHC { } ghc :: GHC ghc = GHC { } nhc :: NHC nhc = NHC { } instance Compiler GHC instance Compiler NHC data MkCompiler where MkCompiler :: Compiler c => c -> MkCompiler instance Compiler MkCompiler where getInstalledPackages (MkCompiler c) = getInstalledPackages c compilers :: [MkCompiler] compilers = [MkCompiler ghc, MkCompiler nhc] }}} There's two language features we want to make this really nice: 1. Letting us call the data type `Compiler` rather than `MkCompiler`. That would mean separating the class and type namespaces. 2. Letting us derive the Compiler instance for `MkCompiler`. For the latter we would want either: {{{ newtype MkCompiler where MkCompiler :: Compiler c => c -> MkCompiler deriving Compiler }}} or {{{ data MkCompiler where MkCompiler :: Compiler c => c -> MkCompiler deriving Compiler }}} The advantage of the first is that newtype deriving already exists as a concept so that's nice and consistent. The problem is we do not allow newtypes that use existentials. From an implementation point of view, it's clear that the representations cannot be equal because of the need to store the class dictionary. From a semantic point of view however it's not obvious that existentials with class contexts are illegitimate in newtypes. The underlying implementation would of course have to be an extra layer of boxing, so like data but with the pattern match behaviour newtype. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 28 19:13:15 2009 From: trac at galois.com (GHC) Date: Sat Nov 28 18:48:08 2009 Subject: [GHC] #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet In-Reply-To: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> References: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> Message-ID: <058.3f853bf46cb293b60d4cdbdde8b6d0c4@localhost> #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet ---------------------------+------------------------------------------------ Reporter: mightybyte | Owner: Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by rl): * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: I suspect this is the same bug, I ran across it while working on !NoSlow. Still happens with 6.13.20091126. I suggest setting priority back to normal since we now have a small testcase. {{{ {-# LANGUAGE TemplateHaskell, Rank2Types, FlexibleContexts #-} module T where import Language.Haskell.TH type T a = Eq a => a $(do { reify ''T; return []}) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 28 19:29:42 2009 From: trac at galois.com (GHC) Date: Sat Nov 28 19:04:35 2009 Subject: [GHC] #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet In-Reply-To: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> References: <049.c0071745bb9fd450cac603f8c5f89f94@localhost> Message-ID: <058.52121024459fe0d9ba14cbdd2eb819d7@localhost> #3100: GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet ---------------------------+------------------------------------------------ Reporter: mightybyte | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * priority: low => normal Comment: Thanks for the testcase! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 01:14:18 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 00:49:12 2009 Subject: [GHC] #3700: Being instance of Monoid is not checked In-Reply-To: <044.de9e3766af280c3cbcb7060720546c65@localhost> References: <044.de9e3766af280c3cbcb7060720546c65@localhost> Message-ID: <053.c5b5aa6c79f0c49f81139410acd3a3e1@localhost> #3700: Being instance of Monoid is not checked ----------------------------------------+----------------------------------- Reporter: boris | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.3 Resolution: | Keywords: Monoid, Writer Os: Windows | Testcase: Architecture: x86 | Failure: Other ----------------------------------------+----------------------------------- Comment (by rwbarton): I don't think this is a bug. GHCi should accept the first declaration because later (say in another module) someone might define an instance `Monoid ((a -> b) -> [a] -> [b])` and then want to call the function `f`. The second declaration is rejected due to the monomorphism restriction: since `f` is not defined via a function binding, GHCi must choose a monomorphic type for `f` immediately and it has no way to satisfy the `Monoid` instance. If you turn off the monomorphism restriction by entering `:set -XNoMonomorphismRestriction`, you will find that both definitions are accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 01:33:41 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 01:08:33 2009 Subject: [GHC] #3702: deriving for GADTs Message-ID: <047.6f0e8d7da833492fd6dde2b2297e185b@localhost> #3702: deriving for GADTs ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Component: Documentation Version: 6.12.1 RC1 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ I'm pleased to see that GHC 6.12.1 will include deriving for GADTs. However, I discovered this in a quite accidental way. I tried appending `deriving (Eq, Show)` to the end of my type declaration, without success, and decided to check whether there was a request in Trac for the feature, when I discovered ticket #3012. Sure enough, switching to a standalone deriving clause worked when I compiled my program in GHC 6.12.1 RC1. It would be nice if this feature were more easily discoverable. I think it deserves mention in the release notes. Also, it would be great if the error message for the non-standalone deriving clause (Can't make a derived instance of ... / Constructor ... does not have a Haskell-98 type) suggested the standalone syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 03:04:48 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 02:39:52 2009 Subject: [GHC] #3637: ./configure doesn't understand Gentoo's build/host/target In-Reply-To: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> References: <047.fcebd5e462086e021124f01f2c19fc8c@localhost> Message-ID: <056.dc993739920f8e419ed1469662c432ff@localhost> #3637: ./configure doesn't understand Gentoo's build/host/target ----------------------------------+----------------------------------------- Reporter: kolmodin | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: regression Difficulty: Unknown | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by asuffield): * cc: asuffield@suffields.me.uk (added) * failure: => Building GHC failed Comment: It's not clear what configure is trying to do with the --{host,build,target} arguments here. GNU-style configure scripts are supposed to accept GNU-format configuration triples (as used by config.{sub,guess}) and direct the configure script to set up for a particular mode of cross-compilation. The vendor build scripts pass these arguments because their own "cross compile the distribution" automation knows more about what's going on. There is a cluster of bugs in configure.ac that get this all wrong. Option 1 is "reimplement config.sub", which is wrong unless you're trying to reinvent autoconf. Options 2 and 3 are essentially the same here, both being "we shall not support GNU-style cross compiling", which is probably also wrong. The cross-compile setup code in configure is currently a mess; the autodetection is broken. From eyeballing it, I doubt it works at all. To move forward: * Are there non-obsolete reasons why configure is this way? * Is ghc somehow different from other compilers with regard to cross- compilation? * Was the 6.10 configure logic anything more than legacy gunk to work around bugs in autoconf versions from 10 years ago, which are no longer relevant? * Is there any reason why the whole lot shouldn't be thrown out in favour of the normal autoconf handling? If the answer to all of those is 'no', the solution is trivial. Otherwise, the answers should prove illuminating in how to proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 05:17:01 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 04:51:54 2009 Subject: [GHC] #3703: -ddump-rules does not list all rules in effect Message-ID: <046.cbef6970fc7549dd0b91f6f53e79c1c1@localhost> #3703: -ddump-rules does not list all rules in effect -------------------------------+-------------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown -------------------------------+-------------------------------------------- Hi, the attached code has a function breakOn which calls "break (c==)" from Bytestring. That function has a rewrite rule, rewriting it to "breakChar c". I?d expect "ghc -ddump-rules" to tell me that this function was called, but that is not the case: {{{ $ ghc -O -ddump-rules --make breakOn.hs [1 of 1] Compiling Main ( breakOn.hs, breakOn.o ) ==================== Transformation rules ==================== Local rules Imported rules ==================== Top-level specialisations ==================== Linking breakOn ... }}} But in fact, the rule does fire, as this excert from "ghc -ddump- inlinings" shows: {{{ Considering inlining bytestring-0.9.1.4:Data.ByteString.Char8.breakChar{v r3m} [gid] active: False arg infos [False] interesting continuation BoringCtxt is value: True is cheap: True guidance IF_ARGS 2 [0 0] 4 6 ANSWER = NO }}} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 05:24:19 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 04:59:11 2009 Subject: [GHC] #3703: -ddump-rules does not list all rules in effect In-Reply-To: <046.cbef6970fc7549dd0b91f6f53e79c1c1@localhost> References: <046.cbef6970fc7549dd0b91f6f53e79c1c1@localhost> Message-ID: <055.884e81bfef1ad1d1fc212267d809590f@localhost> #3703: -ddump-rules does not list all rules in effect -------------------------------+-------------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown -------------------------------+-------------------------------------------- Comment (by nomeata): Cale on IRC told me about "-ddump-simple-stats", which does list the rule in question: {{{ $ ghc -O -ddump-simpl-stats --make breakOn.hs [1 of 1] Compiling Main ( breakOn.hs, breakOn.o ) ==================== FloatOut stats: ==================== 0 Lets floated to top level; 0 Lets floated elsewhere; from 0 Lambda groups ==================== FloatOut stats: ==================== 4 Lets floated to top level; 0 Lets floated elsewhere; from 1 Lambda groups ==================== Grand total simplifier statistics ==================== Total ticks: 1147 223 PreInlineUnconditionally 305 PostInlineUnconditionally 131 UnfoldingDone 15 RuleFired 2 0# +# x# 2 ByteString pack/packAddress 1 ByteString specialise break (x==) 2 int2Word# 2 int2Word2Int 2 narrow8Word# 2 ord# 2 word2Int# 39 LetFloatFromLet 1 EtaReduction 340 BetaReduction 93 KnownBranch 11 SimplifierDone Linking breakOn ... }}} I guess I mis-understnad the meaning of -ddump-rules. Either close this bug, or keep it open as a reminder to extend the documentation of "-ddump- rules" in "man ghc" a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 07:26:23 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 07:01:17 2009 Subject: [GHC] #3704: Linking shared libraries broken due to name mismatch Message-ID: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@localhost> #3704: Linking shared libraries broken due to name mismatch ---------------------------------+------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ When trying to link with ghc -shared {{{ $ ghc -v -fPIC -shared -o TestF.so TestF.hs }}} it adds a bunch of arguments of the form -lHSbase-4.2.0.0 to the linker command line {{{ *** Linker: /usr/bin/gcc -v -o TestF.so TestF.o -shared -Wl,-Bsymbolic -Wl,-soname,TestF.so -L/usr/lib/ghc-6.12.0.20091126/base-4.2.0.0 -L/usr/lib/ghc-6.12.0.20091126/integer-gmp-0.2.0.0 -L/usr/lib/ghc-6.12.0.20091126/ghc-prim-0.2.0.0 -L/usr/lib/ghc-6.12.0.20091126 -lHSbase-4.2.0.0 -lHSinteger-gmp-0.2.0.0 -lgmp -lHSghc-prim-0.2.0.0 -lHSffi }}} Unfortunately: {{{ /usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0-ghc6.12.0.20091126.so /usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0.a /usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0_p.a }}} The name of the .so has been mangled to include the compiler version - presumably for ABI reasons. Obviously the bug is that name on the linker command line has not been suitably mangled to match, so the linker goes ahead and tries to use the .a library, which doesn't work at all. {{{ /usr/bin/ld: /usr/lib/ghc-6.12.0.20091126/base-4.2.0.0/libHSbase-4.2.0.0.a(Base__76.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC }}} Tested on linux/amd64, with HEAD and stable snapshot. It may work on linux/i386 due to compatibility hacks in glibc, I haven't checked; it shouldn't work on anything else. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 07:36:09 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 07:11:00 2009 Subject: [GHC] #3704: Using -shared without -dynamic should be rejected on linux In-Reply-To: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@localhost> References: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@localhost> Message-ID: <057.3dc4a56f82b017730d0bbe2367064f82@localhost> #3704: Using -shared without -dynamic should be rejected on linux ---------------------------------+------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Changes (by asuffield): * summary: Linking shared libraries broken due to name mismatch => Using -shared without -dynamic should be rejected on linux Comment: Sigh, always spot it five minutes after typing the thing up. The bug is, more precisely, that using -shared without -dynamic is nonsense on linux - that combination can't be linked, and hence should be rejected. Or better yet, silently corrected to add -dynamic. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 07:44:12 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 07:19:05 2009 Subject: [GHC] #3705: -fPIC without -dynamic silently ignored Message-ID: <048.79f60db856b7d267ec487bb7bef2f0d4@localhost> #3705: -fPIC without -dynamic silently ignored -------------------------------+-------------------------------------------- Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: | Keywords: Os: Linux | Testcase: Architecture: x86_64 (amd64) | Failure: None/Unknown -------------------------------+-------------------------------------------- {{{ $ ghc -fPIC -c -o TestF.o TestF.hs $ ghc -shared -dynamic TestF.so TestF.o /usr/bin/ld: TestF.o: relocation R_X86_64_PC32 against undefined symbol `stg_CAF_BLACKHOLE_info' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status $ ghc -fPIC -dynamic -c -o TestF.o TestF.hs $ ghc -shared -dynamic TestF.so TestF.o $ }}} If you attempt to use -fPIC without -dynamic, then you get non-PIC code in the .o file. This behaviour is surprising and quite useless. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 11:47:21 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 11:22:17 2009 Subject: [GHC] #3705: -fPIC without -dynamic silently ignored In-Reply-To: <048.79f60db856b7d267ec487bb7bef2f0d4@localhost> References: <048.79f60db856b7d267ec487bb7bef2f0d4@localhost> Message-ID: <057.4d3f9a6a3db3147733cd8ccd270edf93@localhost> #3705: -fPIC without -dynamic silently ignored ---------------------------+------------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by duncan): * difficulty: => Comment: It looks like this is behaving as specified. Yes, the message says to use -fPIC, and that'd probably be right if we were talking about C code and gcc. The symbol type R_X86_64_PC32 looks like a PC-relative reference to a symbol it expects to find within the same shared object. That's just what you would expect from -fPIC without -dynamic. Of course what you're doing here is making PIC code that expects to find other symbols within the same shared object, but then linking it in such a way that the other symbols are in an external shared object. That indeed will not work. It should in principle be possible to build the rts and standard libs with -fPIC and without -dynamic. These would be made into .a libs. Then it should be possible to make one huge .so linking in all the Haskell packages and rts. Internally to this big .so, all the symbol references would be PC-relative and not go via the GOT. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 11:47:42 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 11:22:34 2009 Subject: [GHC] #3704: Using -shared without -dynamic should be rejected on linux In-Reply-To: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@localhost> References: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@localhost> Message-ID: <057.f056dd34091a601ddbb2043d5fafd4aa@localhost> #3704: Using -shared without -dynamic should be rejected on linux ---------------------------+------------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by duncan): * difficulty: => Comment: In principle it would work if the static libs were built with -fPIC. You'd then be able to make a huge great .so that links in all the Haskell libs and rts. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 12:21:21 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 11:56:11 2009 Subject: [GHC] #3705: -fPIC without -dynamic silently ignored In-Reply-To: <048.79f60db856b7d267ec487bb7bef2f0d4@localhost> References: <048.79f60db856b7d267ec487bb7bef2f0d4@localhost> Message-ID: <057.44af1bded57297bc2dacf83dca7e73c9@localhost> #3705: -fPIC without -dynamic silently ignored ---------------------------+------------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by asuffield): While true in the general case, we can detect that this particular ghc was built in the normal fashion, and hence can detect the error while parsing the options. Furthermore, this is an "unbreak me" option - it's worth rethinking the defaults here. There don't seem to be any users who want to build gigantic shared libraries containing the rts, while there are probably some users who want to build normal shared libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 14:26:51 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 14:01:46 2009 Subject: [GHC] #3704: Using -shared without -dynamic should be rejected on linux In-Reply-To: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@localhost> References: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@localhost> Message-ID: <057.89698e13238f5a8359b458a5eec74ec3@localhost> #3704: Using -shared without -dynamic should be rejected on linux ---------------------------+------------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by duncan): In this ticket and in #3705, we could produce better diagnostics than linker errors if we tracked how built libs/packages expect to find their external symbols. The thing to track is whether they expect to find them within the same shared object or in a separate shared object. That would also have caught an apparent problem Max ran into when playing with shared libs. This would involve tracking if the object files were built with -dynamic or not (and perhaps -fPIC too). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 15:34:40 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 15:09:33 2009 Subject: [GHC] #3685: "double free or corruption" error when running Setup.hs with other GHC in PATH In-Reply-To: <042.d3a505caff2f54b3cc2a8c83ae993cb8@localhost> References: <042.d3a505caff2f54b3cc2a8c83ae993cb8@localhost> Message-ID: <051.34077834e82104741d5881cf9a0c6c36@localhost> #3685: "double free or corruption" error when running Setup.hs with other GHC in PATH ----------------------------+----------------------------------------------- Reporter: ajd | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Resolution: fixed | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86 Failure: Runtime crash | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 16:10:35 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 15:45:26 2009 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@localhost> References: <043.7c288f8e774d3806292d73b1513892ec@localhost> Message-ID: <052.1fdc46781f7f79ab57090dda3dac19c1@localhost> #3693: Show stack traces ------------------------------+--------------------------------------------- Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by jpet): Sorry, I should have said, "walking these stacks for stack traces seems feasible, since the garbage collector already has to do it." I should know better than to use the word "easy" when suggesting a task for someone else. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 19:26:49 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 19:01:50 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@localhost> References: <056.c6f0034a4d5f342c60f11476270241e0@localhost> Message-ID: <065.72c1e0c1be58bd0b563354a660771902@localhost> #3550: Dynamic libraries don't work on Mac OS/X --------------------------------------------------------------+------------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.11 Resolution: | Keywords: dynamic mac osx Difficulty: Unknown | Os: MacOS X Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------------------------------+------------- Changes (by mwotton): * failure: => None/Unknown Comment: Replying to [comment:7 igloo]: > Too late for 6.12.1, but let's see if this is suitable for a point release in the 6.12 branch. Hi Igloo - is there something holding this and and #3550 up? What can I do to help? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 29 19:30:28 2009 From: trac at galois.com (GHC) Date: Sun Nov 29 19:05:27 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@localhost> References: <056.c6f0034a4d5f342c60f11476270241e0@localhost> Message-ID: <065.b979690b8a797dd1d1040fa5b7a2be34@localhost> #3550: Dynamic libraries don't work on Mac OS/X --------------------------------------------------------------+------------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler | Version: 6.11 Resolution: | Keywords: dynamic mac osx Difficulty: Unknown | Os: MacOS X Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 | Architecture: Unknown/Multiple Failure: None/Unknown | --------------------------------------------------------------+------------- Comment (by mwotton): Replying to [comment:8 mwotton]: > Replying to [comment:7 igloo]: > > Too late for 6.12.1, but let's see if this is suitable for a point release in the 6.12 branch. > > Hi Igloo - is there something holding this and and #3550 up? What can I do to help? sorry, meant http://hackage.haskell.org/trac/hackage/ticket/591 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 04:23:13 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 03:58:02 2009 Subject: [GHC] #3700: Being instance of Monoid is not checked In-Reply-To: <044.de9e3766af280c3cbcb7060720546c65@localhost> References: <044.de9e3766af280c3cbcb7060720546c65@localhost> Message-ID: <053.36b5f6a724693bc68aadac1d4c3379fc@localhost> #3700: Being instance of Monoid is not checked ----------------------------------------+----------------------------------- Reporter: boris | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.3 Resolution: invalid | Keywords: Monoid, Writer Os: Windows | Testcase: Architecture: x86 | Failure: Other ----------------------------------------+----------------------------------- Changes (by boris): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 06:10:59 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 05:45:52 2009 Subject: [GHC] #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use In-Reply-To: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> References: <042.c4b5030684625e3b4acbf7f52bd1fe70@localhost> Message-ID: <051.a4081c34fc6f358732ec88658573270c@localhost> #3681: hsc2hs wrapper script throws away $HSC2HS_EXTRA's value when specified C compiler to use ---------------------+------------------------------------------------------ Reporter: nwn | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: hsc2hs | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: MacOS X Testcase: | Architecture: x86 Failure: Other | ---------------------+------------------------------------------------------ Changes (by simonmar): * priority: normal => high * failure: None/Unknown => Other * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 06:33:16 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 06:08:08 2009 Subject: [GHC] #3684: Missing ghc-pkg options in --help In-Reply-To: <047.1024f8df520bd9d4665f757c76edb0a3@localhost> References: <047.1024f8df520bd9d4665f757c76edb0a3@localhost> Message-ID: <056.b60193614e0202ab7f2e509e48a25c91@localhost> #3684: Missing ghc-pkg options in --help --------------------------------+------------------------------------------- Reporter: kolmodin | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: ghc-pkg | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => * owner: => simonmar * milestone: => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 06:43:17 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 06:18:06 2009 Subject: [GHC] #414: GHC does not eforce that Main exports main In-Reply-To: <046.38fe8da23abfc42f9ad2cb0e14b8afda@localhost> References: <046.38fe8da23abfc42f9ad2cb0e14b8afda@localhost> Message-ID: <055.6671b8f7439776579d7530dd1a66cbac@localhost> #414: GHC does not eforce that Main exports main ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: simonmar Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.10.4 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: mod174 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 06:57:40 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 06:32:34 2009 Subject: [GHC] #3694: Image link in User's Guide is broken In-Reply-To: <042.4dce51a64fcceef53092b64072938194@localhost> References: <042.4dce51a64fcceef53092b64072938194@localhost> Message-ID: <051.e945316561564b18e31d93336433316f@localhost> #3694: Image link in User's Guide is broken --------------------------------+------------------------------------------- Reporter: jli | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Documentation | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 07:06:12 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 06:41:07 2009 Subject: [GHC] #3694: Image link in User's Guide is broken In-Reply-To: <042.4dce51a64fcceef53092b64072938194@localhost> References: <042.4dce51a64fcceef53092b64072938194@localhost> Message-ID: <051.60e1010b7b8185ce92d8c2b7136b7ef7@localhost> #3694: Image link in User's Guide is broken --------------------------------+------------------------------------------- Reporter: jli | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.2 Component: Documentation | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * milestone: 6.12.1 => 6.12.2 Comment: Fixed {{{ Mon Nov 30 11:23:27 GMT 2009 Simon Marlow * Check whether the main function is actually exported (#414) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 07:07:54 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 06:42:45 2009 Subject: [GHC] #414: GHC does not eforce that Main exports main In-Reply-To: <046.38fe8da23abfc42f9ad2cb0e14b8afda@localhost> References: <046.38fe8da23abfc42f9ad2cb0e14b8afda@localhost> Message-ID: <055.6b5d6b9323d86ffc9e42cbcccbdd335b@localhost> #414: GHC does not eforce that Main exports main ---------------------------+------------------------------------------------ Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: lowest | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Resolution: None | Keywords: Difficulty: Unknown | Os: Unknown/Multiple Testcase: mod174 | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * milestone: _|_ => 6.12.2 Comment: Fixed {{{ Mon Nov 30 11:23:27 GMT 2009 Simon Marlow * Check whether the main function is actually exported (#414) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 07:08:33 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 06:43:29 2009 Subject: [GHC] #3694: Image link in User's Guide is broken In-Reply-To: <042.4dce51a64fcceef53092b64072938194@localhost> References: <042.4dce51a64fcceef53092b64072938194@localhost> Message-ID: <051.07e88f60788db5433c5ac4e87c63faae@localhost> #3694: Image link in User's Guide is broken --------------------------------+------------------------------------------- Reporter: jli | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Documentation | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: igloo => simonmar * type: merge => bug * milestone: 6.12.2 => 6.12.1 Comment: Aargh! wrong ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 07:19:55 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 06:54:56 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.c8b14ad91fc79eb1fde9620cc17f6a6b@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Changes (by simonmar): * difficulty: => Comment: We need to know which command is causing the ';' unexpected errors. Perhaps try running make with `-d`? Regarding the sed problem we need to know whether we have introduced a dependency on a particular sed extension, and if so, which sed command is to blame. Jost, you said "missing preprocessor support in the stage-1 compiler", what exactly does that mean? The stage-1 compiler should normally behave exactly as the stage 2 compiler with respect to preprocessor support. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 07:54:18 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 07:29:15 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.bf4c1e45fb56a1b774bec90d96ea924e@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by maeder): "gmake -d" did not reveal anything {{{ ... Reading makefile `utils/unlit/ghc.mk' (search path) (no ~ expansion)... Reading makefile `utils/unlit/dist/build/.depend' (search path) (no ~ expansion)... /bin/sh: syntax error at line 1: `;' unexpected /bin/sh: syntax error at line 1: `;' unexpected ... }}} However, this error is gone if I change in mk/config.mk SHELL from /bin/sh to /bin/bash {{{ SHELL = /bin/bash }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 07:54:51 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 07:29:44 2009 Subject: [GHC] #3705: -fPIC without -dynamic silently ignored In-Reply-To: <048.79f60db856b7d267ec487bb7bef2f0d4@localhost> References: <048.79f60db856b7d267ec487bb7bef2f0d4@localhost> Message-ID: <057.86fc4caa30afe9f9d67dd9c1a72fff07@localhost> #3705: -fPIC without -dynamic silently ignored ---------------------------+------------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by simonmar): Currently the options make sense to someone who understands the implementation, but they make little sense to the user. I suggest we rethink the options, with a focus on the various modes of use that we want to support. e.g. just adding `-dynamic-lib` for building a module to be placed in a shared library would probably be enough: the idea would be that you use `-dynamic-lib` when building the library, and `-dynamic` when building the exe. `-dynamic-lib` would imply `-dynamic`, `-fPIC` where necessary, and `-shared` when linking. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 07:57:41 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 07:32:36 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.dee1178a319e19a6ec0b0a0f7ca5248e@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by simonmar): changing the `SHELL` to bash isn't a satisfactory workaround, the build system is supposed to work with any `/bin/sh`-compatible shell. Perhaps use dtruss to find out what command was being executed? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 08:01:37 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 07:36:27 2009 Subject: [GHC] #3704: Using -shared without -dynamic should be rejected on linux In-Reply-To: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@localhost> References: <048.04c7c9d4780f94b6d12f6cbf7be90e6c@localhost> Message-ID: <057.0d4795d02cdf3781f80aa79b9f4fc88b@localhost> #3704: Using -shared without -dynamic should be rejected on linux ---------------------------+------------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by simonmar): The proposal in #3705 is to add a new flag `-dynamic-lib` for building shared libraries. This would make the common case less error-prone, but leave the more detailed options available for experts who want to experiment with other combinations. Yes we could track information about how each `.o` file was built. That's tricky to implement, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 08:01:37 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 07:36:33 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.b4d5ca2f76dccb928be73ee2aafb098d@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by jberthold): Simon wrote: We need to know which command is causing the ';' unexpected errors. Perhaps try running make with -d? (Simultaneously to Christian...) I have run {{{ make -d }}}. It is not completely clear where the ';' message comes from, however it looks as if the error shows whenever a file {{{ .depend }}} is read in, and when reading {{{ rts/ghc.mk }}}. (And seems there is no dtruss available on this machine, sorry) Regarding the sed problem we need to know whether we have introduced a dependency on a particular sed extension, and if so, which sed command is to blame. Unfortunately, I cannot reproduce this one any more, since I installed my own sed. Both the old log file which I have kept, and Christian's log, show that the stage-1 compiler is invoked without {{{ -XCPP }}} which is the [...] "missing preprocessor support in the stage-1 compiler" [...] This is the -very long- line no. 4466 in the attached log.gz. In my later build with the new sed, the option {{{ -XCPP }}} is added. This is of course only a symptom of the stage-1 compiler being built without cpp support. The stage-2 compiler, if any was buildable, would also not have cpp support. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 08:06:44 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 07:41:33 2009 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@localhost> References: <043.7c288f8e774d3806292d73b1513892ec@localhost> Message-ID: <052.495fd85a05933eea898faaace6fce946@localhost> #3693: Show stack traces ------------------------------+--------------------------------------------- Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by simonmar): Yes you can walk the stack, but the problem is that due to the amount of code transformation that GHC does, it is almost impossible to relate stack frames at runtime to the original code. The code that runs bears little resemblance to the code you wrote in the original program. Case expressions in the compiled code may or may not correspond to case expressions or pattern matches in the original code, and GHC doesn't generally keep track of that information. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 08:16:27 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 07:51:22 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.19d85e4856be361cc67cdd95d7d6caca@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by simonmar): I don't think it's possible to "build stage 1 without CPP support", the problem is more likely to be that the `-XCPP` option just got lost somewhere. My guess is that this has something to do with the `$$(shell ...)` commands in `rules/distdir-way-opts.mk`. You could try replacing, e.g. {{{ $1_$2_$3_HSC2HS_CC_OPTS:=$$(shell for i in $$($1_$2_DIST_CC_OPTS); do echo \'--cflag=$$$$i\'; done) }}} with {{{ $1_$2_$3_HSC2HS_CC_OPTS:=$$($1_$2_DIST_CC_OPTS) }}} and see if that helps (similarly for the other occurrences of `$$(shell ...)` in that file). If that is indeed the problem, then we need to find another fix. I'm guessing that Solaris `/bin/sh` has different quoting semantics from Bash. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 08:43:38 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 08:18:39 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.be8c7d28ab50ce55863732b6c1c5491a@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by jberthold): Simon: I don't think it's possible to "build stage 1 without CPP support", the problem is more likely to be that the -XCPP option just got lost somewhere. I think this might help shed some light on the sed-related problems. I dug up the following line in the log file (line 356): {{{ sed '/^xFlags/,/]/s/^[[:space:]]*([[:space:]]*\("[^"]*"\)[^"]*/ [\1] ++/p;d' \ compiler/main/DynFlags.hs >> utils/ghc-cabal/dist-dummy-ghc/build/dummy- ghc.hs }}} Using /usr/bin/sed, this command yields plain nothing on my machine, using sed-4.1.2 it outputs the expected list of GHC extensions (-X... from DynFlags.hs). The resulting dummy-ghc is used to configure all packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 09:17:27 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 08:52:17 2009 Subject: [GHC] #3684: Missing ghc-pkg options in --help In-Reply-To: <047.1024f8df520bd9d4665f757c76edb0a3@localhost> References: <047.1024f8df520bd9d4665f757c76edb0a3@localhost> Message-ID: <056.9d6bd5c19e02f2fe204a713d9b340da7@localhost> #3684: Missing ghc-pkg options in --help --------------------------------+------------------------------------------- Reporter: kolmodin | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.2 Component: ghc-pkg | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Mon Nov 30 12:20:40 GMT 2009 Simon Marlow * document 'recache' command in the help output (#3684) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 09:18:07 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 08:53:21 2009 Subject: [GHC] #3694: Image link in User's Guide is broken In-Reply-To: <042.4dce51a64fcceef53092b64072938194@localhost> References: <042.4dce51a64fcceef53092b64072938194@localhost> Message-ID: <051.cd575d59cdbc0a7c7b7b8011f17c8201@localhost> #3694: Image link in User's Guide is broken --------------------------------+------------------------------------------- Reporter: jli | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.12.1 Component: Documentation | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Documentation bug | --------------------------------+------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed {{{ Mon Nov 30 13:27:03 GMT 2009 Simon Marlow * Fix the prof_scc.png image in the profiling section (#3694) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 09:20:25 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 08:55:14 2009 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@localhost> References: <043.7c288f8e774d3806292d73b1513892ec@localhost> Message-ID: <052.787ef2be10b4b042d4797ea359d2a9aa@localhost> #3693: Show stack traces ------------------------------+--------------------------------------------- Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by simonpj): I agree with all you say, but I think there's still a case for saying that any stack trace is better than none. It may not be easily explicable to Joe User, but it would give an expert a lot more to go on. It's a bit like attaching a loudspeaker to the memory access pin of a CPU; you can't explain the noises that come out, but you get to recognise them and they can be very helpful. (Don't laugh -- I worked on an Eliot 803 which did this! Well, I'm not sure which pin it was, but it made noises anyway.) In short, I think there's a case for a quick-and-dirty stack trace, if such a thing could be done without much effort. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 09:25:02 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 08:59:57 2009 Subject: [GHC] #3683: could not build ghc-6.12.0.20091121 under solaris In-Reply-To: <045.e5089cca43f6d0feea222b47017c2de3@localhost> References: <045.e5089cca43f6d0feea222b47017c2de3@localhost> Message-ID: <054.08ef400f4f31054900e2af29841d4695@localhost> #3683: could not build ghc-6.12.0.20091121 under solaris ----------------------------------+----------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.12.1 RC1 Resolution: | Keywords: Difficulty: | Os: Solaris Testcase: | Architecture: Unknown/Multiple Failure: Building GHC failed | ----------------------------------+----------------------------------------- Comment (by maeder): Replying to [comment:8 jberthold]: > I dug up the following line in the log file (line 356): > {{{ > sed '/^xFlags/,/]/s/^[[:space:]]*([[:space:]]*\("[^"]*"\)[^"]*/ [\1] ++/p;d' \ > compiler/main/DynFlags.hs >> utils/ghc-cabal/dist-dummy-ghc/build /dummy-ghc.hs > }}} "[:space:]" does not work, but it can be replaced by " ". Instead of my /usr/bin/sed, /usr/xpg4/bin/sed or /opt/csw/bin/gsed works. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 10:56:52 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 10:31:43 2009 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@localhost> References: <043.7c288f8e774d3806292d73b1513892ec@localhost> Message-ID: <052.7b0c347ee79f4eba1ade7a02184b2daf@localhost> #3693: Show stack traces ------------------------------+--------------------------------------------- Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by simonmar): Ok, let's explore what could be done. In gdb you can see the stack like this: {{{ (gdb) p16 $rbp 0x2b265a880368: 0x2b265a87f2c0 0x2b265a880360: 0x748d08 0x2b265a880358: 0x459090 0x2b265a880350: 0x6aafd0 0x2b265a880348: 0x2b265a87f2d1 0x2b265a880340: 0x58afc0 0x2b265a880338: 0x2b265a87f2d1 0x2b265a880330: 0xb6757b 0x2b265a880328: 0xaf04d8 0x2b265a880320: 0xb22c39 0x2b265a880318: 0x2b265a87f328 0x2b265a880310: 0x59dc60 0x2b265a880308: 0x2b2655c4dc18 0x2b265a880300: 0x6abf38 0x2b265a8802f8: 0x2b265a87f328 0x2b265a8802f0: 0x748b88 }}} In the RTS there's also a way to print out stacks, though I don't use it very much. Note this is upside-down compared to the above dump: {{{ (gdb) p printStackChunk( 0x2b265a8802f0,0x2b265a880368) Object 0x2b265a8802f0 = UPDATE_FRAME(0x748b88,0x2b265a87f328) RET_SMALL (0x6abf28) stk[12] (0x2b265a880308) = Word# 47443647716376 RET_SMALL (0x59dc50) stk[10] (0x2b265a880318) = 0x2b265a87f328 stk[9] (0x2b265a880320) = 0xb22c39 stk[8] (0x2b265a880328) = 0xaf04d8 stk[7] (0x2b265a880330) = 0xb6757b stk[6] (0x2b265a880338) = 0x2b265a87f2d1 RET_SMALL (0x58afb0) stk[4] (0x2b265a880348) = 0x2b265a87f2d1 RET_SMALL (0x6aafc0) RET_SMALL (0x459080) Object 0x2b265a880360 = UPDATE_FRAME(0x748d08,0x2b265a87f2c0) }}} You get less information in that there are no symbol names: the RTS doesn't have access to the binary's symbol table. That information is available in the binary, and it might be possible to extract it using the RTS linker (speculation - I don't know how hard this would be in practice). On the other hand, the RTS knows where the boundaries between stack frames are, and it can recognise an UPDATE_FRAME etc. But even with symbol names, you couldn't glean a lot from the trace here. What might help is if we knew which module each of those symbols comes from, but that info isn't available, even in the symbol table. We could add the module name to every symbol, but that would make local symbols much bigger. Perhaps that doesn't matter as these are only local symbols and so symbol lookup isn't actually performed at link time, it just makes the strings bigger in the object files. Someone could do that experiment. Maybe the right thing would be to add some debugging info to the compiled code that doesn't take up any space at runtime, but which the RTS could slurp in if necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 11:07:19 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 10:42:13 2009 Subject: [GHC] #3706: "GHC Commentary" link in HACKING is broken Message-ID: <042.882b10c3a39d4efd239db36fcdf2edfc@localhost> #3706: "GHC Commentary" link in HACKING is broken ---------------------------------+------------------------------------------ Reporter: jli | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.4 | Keywords: broken link Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Documentation bug ---------------------------------+------------------------------------------ The HACKING file links to < http://hackage.haskell.org/trac/wiki/Commentary >, but the correct link (I assume) is < http://hackage.haskell.org/trac/ghc/wiki/Commentary >. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 12:21:39 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 11:56:30 2009 Subject: [GHC] #3691: Error message doesn't mention necessary extension in warning In-Reply-To: <045.4e6de20074a753fbe79a2f142c50f383@localhost> References: <045.4e6de20074a753fbe79a2f142c50f383@localhost> Message-ID: <054.c25c53e4d0b4cbda502d597a08865314@localhost> #3691: Error message doesn't mention necessary extension in warning ------------------------------------------------+--------------------------- Reporter: arsenm | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | ------------------------------------------------+--------------------------- Comment (by simonpj): It took me a while to parse, but I understand Isaac to be saying: * Isaac supports the proposal described above under "But the proposal is..." Isaac's argument is: we should encourage people to avoid code whose behaviour would change with `ScopedTypeVariables`. I agree. Anyone else? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 12:36:03 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 12:10:57 2009 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@localhost> References: <043.7c288f8e774d3806292d73b1513892ec@localhost> Message-ID: <052.f3a59e23bb9204f799703567015b9915@localhost> #3693: Show stack traces ------------------------------+--------------------------------------------- Reporter: jpet | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.10.4 Resolution: | Keywords: Difficulty: | Os: Unknown/Multiple Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown | ------------------------------+--------------------------------------------- Comment (by simonpj): Apart from update/exception frames, the stack mainly consists of frames pushed by 'case'. If we put a string into each return-info-table (much as we do already for constructors, I think), then we could record (a) module, (b) top-level function (c) case binder... and that'd be plenty. It'd bloat our binaries a bit but I'm betting it would not be much. An alternative could be to do this only if you compile with -debug or -ticky. But that would lose part of the benefit, I'm guessing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 13:07:40 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 12:42:30 2009 Subject: [GHC] #3707: deriving Data, Typeable for empty data decls Message-ID: <046.c30e37289f0c475ce8f5491c63ad50b1@localhost> #3707: deriving Data, Typeable for empty data decls ---------------------------------+------------------------------------------ Reporter: seanmcl | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Keywords: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Empty data decls are useful for things like phantom types. However, deriving (Data, Typeable) does not work with them, so if you want to use them with generics you must do something like the following: data PredTag instance Typeable PredTag where typeOf _ = G.mkTyConApp (G.mkTyCon "PredTag") [] Surely GHC could derive this for us! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 30 18:24:01 2009 From: trac at galois.com (GHC) Date: Mon Nov 30 17:58:51 2009 Subject: [GHC] #3705: -fPIC without -dynamic silently ignored In-Reply-To: <048.79f60db856b7d267ec487bb7bef2f0d4@localhost> References: <048.79f60db856b7d267ec487bb7bef2f0d4@localhost> Message-ID: <057.c7cc674539192670798fad7440ac5f6a@localhost> #3705: -fPIC without -dynamic silently ignored ---------------------------+------------------------------------------------ Reporter: asuffield | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Difficulty: | Os: Linux Testcase: | Architecture: x86_64 (amd64) Failure: None/Unknown | ---------------------------+------------------------------------------------ Comment (by duncan): Replying to [comment:4 simonmar]: > Currently the options make sense to someone who understands the implementation, but they make little sense to the user. True and true. When I first started on the shared lib hacking I was convinced that we did not need all of -dynamic, -fPIC and -shared. But it turns out all the combinations make sense for something. Even -dynamic need not imply -fPIC or vice versa. > I suggest we rethink the options, with a focus on the various modes of use that we want to support. e.g. just adding `-dynamic-lib` for building a module to be placed in a shared library would probably be enough: the idea would be that you use `-dynamic-lib` when building the library, and `-dynamic` when building the exe. > > `-dynamic-lib` would imply `-dynamic`, `-fPIC` where necessary, and `-shared` when linking. Yep, that works. The docs will have to present it well so that it reduces confusion rather than adding to it by adding yet another similar-named option. Note that this only really helps people in the case that they're making shared libs for integration with C code. For constructing Haskell packages there are a bunch more conventions they must follow to make it work (in particular getting the right lib name). Also, I still think there's a case to be made for adding some extra consistency info so that we get better diagnostics when linking incompatible stuff. This stuff is certainly confusing, even when you know how it works. The key thing to track about a built package/object is whether inter-package references are expected to be in the same or a different shared object. -- Ticket URL: GHC The Glasgow Haskell Compiler