From simonpj at microsoft.com Thu Nov 1 04:47:47 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Nov 1 04:45:10 2007 Subject: [Haskell] Image manipulation In-Reply-To: <20071101011516.GA3654@localhost.localdomain> References: <000c01c81a6b$98ea3d90$cabeb8b0$@com> <625b74080710291539s44840388j39eadd1b7e2d6462@mail.gmail.com> <200710310854.l9V8sX1u007441@ripper.it.kth.se> <87d4uvr4fj.fsf@nmd9999.imr.no> <20071101011516.GA3654@localhost.localdomain> Message-ID: [Redirecting to ghc-bugs] | > I'm not sure if the GC hack proposed by Wadler? that lets the garbage | > collector replace "fst (a,b)" with "a" (and similar for other unchecked | > selectors) counts as optimistic evaluation, but I wonder what the | > status of this is. GHC doesn't seem to do it, and I wonder if there | > is any particular reason? Too specific? | | GHC nominally does do it (look for 'selector thunks' in the RTS and | commentary), but it doesn't work and we don't know why. | | http://hackage.haskell.org/trac/ghc/ticket/1038 That bug is alleged to be fixed. Do you think it isn't? Simon From ketil+haskell at ii.uib.no Thu Nov 1 05:03:32 2007 From: ketil+haskell at ii.uib.no (Ketil Malde) Date: Thu Nov 1 05:00:56 2007 Subject: [Haskell] Image manipulation In-Reply-To: (Simon Peyton-Jones's message of "Thu\, 1 Nov 2007 08\:47\:47 +0000") References: <000c01c81a6b$98ea3d90$cabeb8b0$@com> <625b74080710291539s44840388j39eadd1b7e2d6462@mail.gmail.com> <200710310854.l9V8sX1u007441@ripper.it.kth.se> <87d4uvr4fj.fsf@nmd9999.imr.no> <20071101011516.GA3654@localhost.localdomain> Message-ID: <87hck6pcbf.fsf@nmd9999.imr.no> Simon Peyton-Jones writes: > | GHC nominally does do it (look for 'selector thunks' in the RTS and > | commentary), but it doesn't work and we don't know why. > | > | http://hackage.haskell.org/trac/ghc/ticket/1038 > That bug is alleged to be fixed. Do you think it isn't? I'm not sure to what extent the fix should cover my case, but if I may restate it, what I certainly found was that by replacing my partitioning function breaks p = groupBy (const (not.p)) by breaks :: (a -> Bool) -> [a] -> [[a]] breaks p (x:xs) = let first = x : takeWhile (not.p) xs rest = dropWhile (not.p) xs in rest `par` first : if null rest then [] else breaks p rest breaks _ [] = [] space consumption was drastically reduced -- as long as I compile with -smp. Previous space consumption appeared to be linear in the largest partition (although I made no accurate measurements). -k -- If I haven't seen further, it is by standing in the footprints of giants From trac at galois.com Thu Nov 1 07:00:19 2007 From: trac at galois.com (GHC) Date: Thu Nov 1 06:57:40 2007 Subject: [GHC] #1811: liberate case needs an independent threshold In-Reply-To: <047.1be3df80e1950b8bf84aedd7dcf27549@localhost> References: <047.1be3df80e1950b8bf84aedd7dcf27549@localhost> Message-ID: <056.c9bceea3351d6a98b1afb3b059ad11c2@localhost> #1811: liberate case needs an independent threshold -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: simonmar => * summary: liberate case causes code duplication => liberate case needs an independent threshold Comment: I re-did the measurements and got roughly consistent results for x86 and x86_64. * This patch did fix the particular case of code explosing I noticed, but it seems to have had little effect on anything else. Code size for nofib dropped by <1%. * Turning off liberate-case for the libraries reduces code size for nofib by 5%. The threshold for liberate-case is currently shared with spec-constr, and is set too high at 200. We need to be able to control the threshold for liberate-case independently of spec-constr, so I'm renaming this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 1 07:03:30 2007 From: trac at galois.com (GHC) Date: Thu Nov 1 07:00:50 2007 Subject: [GHC] #1818: Code size increase vs. 6.6.1 Message-ID: <047.29fbfe8c48a7e251205ebcb2f6270931@localhost> #1818: Code size increase vs. 6.6.1 -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Code size for 6.8.1 has increased around 20% compared to 6.6.1. Find out why, and fix it. Measurements taken for nofib compiled with -O, libraries compiled with -O2. Possibly relevant tickets: #1811 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 1 08:13:13 2007 From: trac at galois.com (GHC) Date: Thu Nov 1 08:10:33 2007 Subject: [GHC] #1819: x86 native codegen implements float2int# incorrectly Message-ID: <047.e2b833a8c1a9fca3579c67ff40fc410c@localhost> #1819: x86 native codegen implements float2int# incorrectly -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler (NCG) | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: arith005 (see description) Architecture: x86 | Os: Unknown -------------------------------+-------------------------------------------- `float2Int#` is supposed to truncate towards zero, but the x86 native codegen implements it as rounding (or rather, whatever rounding mode the x87 FPU is set to, which is normally rounding). The right thing appears to be to save/restore the x87 control word around the conversion operation, and temporarily set it to truncation. This is what gcc does. Code generated by gcc for truncation: {{{ fnstcw -2(%ebp) movw -2(%ebp), %ax movb $12, %ah movw %ax, -4(%ebp) flds 8(%ebp) fldcw -4(%ebp) fistpl -8(%ebp) fldcw -2(%ebp) movl -8(%ebp), %eax }}} Test case: {{{ import GHC.Exts main = print (f2i (-2.9)) {-# NOINLINE f2i #-} f2i :: Float -> Int f2i (F# x) = I# (float2Int# x) }}} Also `arith005` triggers this, when -O is on and the libraries were compiled with `-fasm`. Related: #1254 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 1 08:22:06 2007 From: trac at galois.com (GHC) Date: Thu Nov 1 08:19:26 2007 Subject: [GHC] #1820: Windows segfault-catching only works for the main thread Message-ID: <047.7ca539e672ab08a35be7d52badf17eec@localhost> #1820: Windows segfault-catching only works for the main thread -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Runtime System | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: derefnull(ghci), divbyzero(ghci) Architecture: Unknown | Os: Windows -------------------------------+-------------------------------------------- On Windows, the RTS tries to catch segmentation faults and divide-by-zero exceptions using structured exception handling in `rts/Main.c`. Unfortunately this only works for the main thread, so if the exception occurs in another thread it won't be caught. GHCi runs all its computations in a separate thread, hence `derefnull(ghci)` and `divbyzero(ghci)` are failing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 1 16:04:24 2007 From: trac at galois.com (GHC) Date: Thu Nov 1 16:02:19 2007 Subject: [GHC] #1226: Add flags --full-flag-help and --print-docdir In-Reply-To: <044.6dc8606b5b04e81a01eca3b1719deb81@localhost> References: <044.6dc8606b5b04e81a01eca3b1719deb81@localhost> Message-ID: <053.1213684da6100682923f52f5345717cb@localhost> #1226: Add flags --full-flag-help and --print-docdir -----------------------------+---------------------------------------------- Reporter: igloo | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.8 branch Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by guest): Replying to [comment:5 guest]: > just so that this doesn't get lost: there's a simple xslt file to extract text for a --full-flag-help option here > > http://www.haskell.org/pipermail/cvs-ghc/2007-September/038560.html a patch implementing flag reference command line help with simple search, close to what was suggested in comment:5, was sent to cvs-ghc: http://www.haskell.org/pipermail/cvs-ghc/2007-October/039184.html here is the patch description: {{{ add flag --flags (FIX #1226) Ticket #1226 calls for a '--full-flag-help' flag, presenting the users guide's flag reference or man page in text format. Since a man page isn't much good on windows, and a full listing of flags isn't all that helpful, either, i've implemented a slight refinement of these suggestions: ghc --flags [
:] lists flags containing substring in sections containing substring
examples: ghc --flags : lists the full flag reference ghc --flags @ lists section headers only (because @ doesn't occur in flags) ghc --flags Prof: lists flags in the 'Profiling options' section ghc --flags ghci lists flags mentioning ghci in all sections }}} claus -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Nov 1 18:11:45 2007 From: trac at galois.com (GHC) Date: Thu Nov 1 18:09:39 2007 Subject: [GHC] #1791: -M option does not work In-Reply-To: <044.abdddbf09447556bb749e2aa1d8c6598@localhost> References: <044.abdddbf09447556bb749e2aa1d8c6598@localhost> Message-ID: <053.4177fc6aebbc29b80fe6a0faddebc94f@localhost> #1791: -M option does not work ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.8 branch Component: Runtime System | Version: 6.8 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: outofmem2 | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by guest): * status: closed => reopened * type: merge => bug * resolution: fixed => Comment: I actually expected to get an exception stating "out of heap", like it also works for stack overflows. I have a catch all exception catcher, but this one isn't triggered. Also the actual output doesn't state it's an exception, so I guess it really is not. So, I am reopening it again. Again, to be clear: I want that {{{ Control.Exception.catch action (\exception -> do appendFile "/home/me/exception" (show exception) return Nothing) }}} where action contains the code that overflows the heap does not result in a complete program failure, it should just be a _local_ problem (i.e. an exception). This also means that the test case is likely to be wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 2 06:01:53 2007 From: trac at galois.com (GHC) Date: Fri Nov 2 05:59:12 2007 Subject: [GHC] #1821: Parser or lexer mess-up Message-ID: <046.cf097a693fa1ac0c5dfad7ed75735fe3@localhost> #1821: Parser or lexer mess-up -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- This program gives a parse error: {{{ module Par where f x = x where -- ######### x86_64 machine code: g y = y h y = y }}} With the HEAD we get: {{{ Par.hs:7:8: parse error on input `=' }}} This is killing the stage2 build of the HEAD, in `ByteCodeFFI`: {{{ ghci/ByteCodeFFI.lhs:444:26: parse error on input `=' }}} The problem is something to do with the comment (!). Remove it, and all is fine. I think something to do with Haddock. But surely comments should not mess up code? Programmers unaware of Haddock will not even look at the comments when trying to correct parse errors! Happily 6.8 seems ok. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 2 08:59:36 2007 From: trac at galois.com (GHC) Date: Fri Nov 2 08:57:27 2007 Subject: [GHC] #1226: Add flags --full-flag-help and --print-docdir In-Reply-To: <044.6dc8606b5b04e81a01eca3b1719deb81@localhost> References: <044.6dc8606b5b04e81a01eca3b1719deb81@localhost> Message-ID: <053.39c7e4cd5d308bae6e6d529bec778874@localhost> #1226: Add flags --full-flag-help and --print-docdir -----------------------------+---------------------------------------------- Reporter: igloo | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.8 branch Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by simonmar): I was tempted to turn the man page into `.txt` and spit that out in response to `ghc --full-help` or whatever. Then you have `grep` and `more` to inspect the output. Isn't that much simpler? No extra tools are required, the `.txt` would come with the Windows distribution. Turning the man page into `.txt` is a simple matter of `nroff -mandoc -c -Tascii ghc.1` (if I recall correctly). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 2 09:27:58 2007 From: trac at galois.com (GHC) Date: Fri Nov 2 09:25:52 2007 Subject: [GHC] #886: Profiling doesn't work with -threaded In-Reply-To: <045.4eeb420dca9023055216aedeee61b5e7@localhost> References: <045.4eeb420dca9023055216aedeee61b5e7@localhost> Message-ID: <054.8132879066c7871b7effeb772ce40823@localhost> #886: Profiling doesn't work with -threaded ----------------------------+----------------------------------------------- Reporter: Lemmih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.8 branch Component: Runtime System | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by guest): It must cause problem when someone want to optimise Haskell program. If a programmer find that program is slow, then he profile and try to optimise it.H e find bottleneck long computing function, and he use thread to fix performance problem (Of course, bottleneck isn't memory efficiency in this case). But now he can't profile his proram again. forkOS cause error without -threaded option.par can work without -threaded option, but profiler doesn't report correct result. That's too bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 2 09:38:57 2007 From: trac at galois.com (GHC) Date: Fri Nov 2 09:36:48 2007 Subject: [GHC] #1226: Add flags --full-flag-help and --print-docdir In-Reply-To: <044.6dc8606b5b04e81a01eca3b1719deb81@localhost> References: <044.6dc8606b5b04e81a01eca3b1719deb81@localhost> Message-ID: <053.cc4aa7d218950c9e0702e1f0ba62ca9f@localhost> #1226: Add flags --full-flag-help and --print-docdir -----------------------------+---------------------------------------------- Reporter: igloo | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.8 branch Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by guest): Replying to [comment:7 simonmar]: > I was tempted to turn the man page into `.txt` and spit that out in response to `ghc --full-help` or whatever. Then you have `grep` and `more` to inspect the output. Isn't that much simpler? a `.txt` version of `ghc.1` might be useful as response to `ghc --help` (merging usage and man page), or even as a separate `--full-help`. but it doesn't help much with finding flags: * grep is find on windows, but the man page isn't really suited for either, due to each flag spanning several lines * more on windows doesn't seem to support search * finding sections is more a job for awk's `/begin/,/end/` than for grep, and is awkward even on unix, more so on windows (without awk) you'll find that the `flagref.txt` is both simpler to generate than the man page and simpler in format (one line per flag, making it suitable for grep/find, and for simple substring matching in `Main.hs`). and since the substring matching is built-in, usage requires neither grep, nor find, nor more, nor awk. what could be simpler than that? and how would you do things like the following three queries with your man-page to `.txt` suggestion, with only windows tools? {{{ $ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --flags :@ Flag reference Help and verbosity options Which phases to run Alternative modes of operation Redirecting output Keeping intermediate files Temporary files Finding imports Interface file options Recompilation checking Interactive-mode options Packages Language options Warnings Optimisation levels Individual optimisations Profiling options Program coverage options Haskell pre-processor options C pre-processor options C compiler options Code generation options Linking options Replacing phases Forcing options to particular phases Platform-specific options External core file options Compiler debugging options Misc compiler options $ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --flags Interactive: Interactive-mode options Flag | Description | Static/Dynamic | Reverse -ignore-dot-ghci | Disable reading of .ghci files | static | - -read-dot-ghci | Enable reading of .ghci files | static | - -fbreak-on-exception | Break on any exception thrown | dynamic | -fno- break-on-exception -fbreak-on-error | Break on uncaught exceptions and errors | dynamic | -fno-break-on-error -fprint-evld-with-show | Enable usage of Show instances in :print | dynamic | -fno-print-evld-with-show -fno-print-bind-result | Turn off printing of binding results in GHCi | dynamic | - $ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --flags :type Flag reference Help and verbosity options Which phases to run Alternative modes of operation Redirecting output Keeping intermediate files Temporary files Finding imports Interface file options Recompilation checking Interactive-mode options Packages Language options -XGADTs | Enable generalised algebraic data types. | dynamic | -XNoGADTs -XTypeFamilies | Enable type families. | dynamic | -XNoTypeFamilies -XScopedTypeVariables | Enable lexically-scoped type variables. Implied by -fglasgow-exts. | dynamic | -XNoScopedTypeVariables -XPatternSignatures | Enable pattern type signatures. | dynamic | -XNoPatternSignatures -XUnliftedFFITypes | Enable unlifted FFI types. | dynamic | -XNoUnliftedFFITypes -XLiberalTypeSynonyms | Enable liberalised type synonyms. | dynamic | -XNoLiberalTypeSynonyms -XNoRank2Types | Enable rank-2 types. | dynamic | -XNoRank2Types -XRankNTypes | Enable rank-N types. | dynamic | -XNoRankNTypes -XTypeOperators | Enable type operators. | dynamic | -XNoTypeOperators -XGeneralizedNewtypeDeriving | Enable newtype deriving. | dynamic | -XNoGeneralizedNewtypeDeriving -XTypeSynonymInstances | Enable type synonyms. | dynamic | -XNoTypeSynonymInstances -XMultiParamTypeClasses | Enable multi parameter type classes. | dynamic | -XNoMultiParamTypeClasses Warnings -fwarn-deprecations | warn about uses of functions & types that are deprecated | dynamic | -fno-warn-deprecations -fwarn-type-defaults | warn when defaulting happens | dynamic | -fno- warn-type-defaults Optimisation levels Individual optimisations Profiling options Program coverage options Haskell pre-processor options C pre-processor options C compiler options Code generation options Linking options Replacing phases Forcing options to particular phases Platform-specific options External core file options Compiler debugging options -ddump-tc | Dump typechecker output | dynamic | - -ddump-types | Dump type signatures | dynamic | - -ddump-tc-trace | Trace typechecker | dynamic | - Misc compiler options }}} claus -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 2 10:03:24 2007 From: trac at galois.com (GHC) Date: Fri Nov 2 10:01:13 2007 Subject: [GHC] #1822: Panic in template haskell Message-ID: <044.ee08e08803700b95c663a361c0274a73@localhost> #1822: Panic in template haskell ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: x86 | Os: Linux ---------------------------------+------------------------------------------ The attached files using TH cause a panic (there's an erroneous apostrophe on line 50 of Test_gen.hs) ghc --make Test_use.hs ... ghc-6.6.1: panic! (the 'impossible' happened) (GHC version 6.6.1 for i386-unknown-linux): nameModule stuff{v aJu} (this is ghc-6.6.1 from the Fedora 7 ghc-6.6.1-3.fc7 rpm, which is the latest available) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 2 10:05:13 2007 From: trac at galois.com (GHC) Date: Fri Nov 2 10:03:10 2007 Subject: [GHC] #1822: Panic in template haskell In-Reply-To: <044.ee08e08803700b95c663a361c0274a73@localhost> References: <044.ee08e08803700b95c663a361c0274a73@localhost> Message-ID: <053.dc66e597f361aeee4252628896f181ce@localhost> #1822: Panic in template haskell ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------+--------------------------------------------- Changes (by guest): * cc: jon.fairbairn@cl.cam.ac.uk (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 2 10:09:39 2007 From: trac at galois.com (GHC) Date: Fri Nov 2 10:07:19 2007 Subject: [GHC] #1823: GADTs and scoped type variables don't work right Message-ID: <046.981e6dd1b8fe0fafb375234b6a911fa1@localhost> #1823: GADTs and scoped type variables don't work right ----------------------------------------+----------------------------------- Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: gadt/scoped.hs Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- In this program, which is also in the testsuite as `gadt/scoped.hs`, all three definitions of g should work {{{ {-# OPTIONS_GHC -XGADTs -XScopedTypeVariables -XPatternSignatures #-} module GADT where data C x y where C :: a -> C a a data D x y where D :: C b c -> D a c ------- All these should be ok -- Rejected! g1 :: forall x y . C x y -> () -- C (..) :: C x y -- Inside match on C, x=y g1 (C (p :: y)) = () -- OK! g2 :: forall x y . C x y -> () -- C (..) :: C x y -- Inside match on C, x=y g2 (C (p :: x)) = () -- Rejected! g3 :: forall x y . D x y -> () -- D (..) :: D x y -- C (..) :: C sk y -- sk = y -- p :: sk g3 (D (C (p :: y))) = () }}} But they don't. The reason is that the "refinement" is applied to the environment only after checking an entire pattern; but the refinement is needed during checking the pattern if scoped type variables are to work right. I don't propose to fix this, because it'll come out in the wash when we get rid of type refinements in favour of equality constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 2 10:15:06 2007 From: trac at galois.com (GHC) Date: Fri Nov 2 10:12:58 2007 Subject: [GHC] #886: Profiling doesn't work with -threaded In-Reply-To: <045.4eeb420dca9023055216aedeee61b5e7@localhost> References: <045.4eeb420dca9023055216aedeee61b5e7@localhost> Message-ID: <054.d6392d23ff749705f33d93db5a216423@localhost> #886: Profiling doesn't work with -threaded ----------------------------+----------------------------------------------- Reporter: Lemmih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.8 branch Component: Runtime System | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by guest): And I think this problem affect Data Parallel Haskell developping process. It seem that Data Parallel Haskell generate ndp package's code when vectorising Parallel Array. * http://darcs.haskell.org/ghc/compiler/vectorise/VectBuiltIn.hs But ndp can't build with perf or default build. * http://www.nabble.com/combination-not-supported:-Threaded-Profiling- when-building-NDP-library-t4472936.html This cause problem when someone tries to use Data Parallel Haskell. "Comleted" message isn't in Milestone 2, so I think development is late. But WorkPlan suggests us that Data Parallel Haskell's ndp system will be release near future. * [wiki:DataParallel/WorkPlan] So we'll up against this situation soonly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 2 10:17:51 2007 From: trac at galois.com (GHC) Date: Fri Nov 2 10:15:44 2007 Subject: [GHC] #1791: heap overflow should generate an exception In-Reply-To: <044.abdddbf09447556bb749e2aa1d8c6598@localhost> References: <044.abdddbf09447556bb749e2aa1d8c6598@localhost> Message-ID: <053.9fc41a27f4ce7daa8a9340347d2a7037@localhost> #1791: heap overflow should generate an exception -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.8 branch Component: Runtime System | Version: 6.8 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: outofmem2 | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: reopened => new * owner: igloo => * type: bug => feature request * summary: -M option does not work => heap overflow should generate an exception Comment: Correct - heap overflow doesn't currently generate an exception. It's something we should really do, but it isn't completely clear how to do it. For example, in order to run the exception handler, you need some heap space. So perhaps you want a "soft" and a "hard" limit on heap space, and to get an exception when the "soft" limit is reached. Another question is: which thread(s) should get the exception? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 2 12:55:44 2007 From: trac at galois.com (GHC) Date: Fri Nov 2 12:53:35 2007 Subject: [GHC] #1791: heap overflow should generate an exception In-Reply-To: <044.abdddbf09447556bb749e2aa1d8c6598@localhost> References: <044.abdddbf09447556bb749e2aa1d8c6598@localhost> Message-ID: <053.5aeffd8e6bca32ffaa012b472fc4da61@localhost> #1791: heap overflow should generate an exception -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.8 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: outofmem2 | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: 6.8 branch => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Nov 2 13:05:56 2007 From: trac at galois.com (GHC) Date: Fri Nov 2 13:03:49 2007 Subject: [GHC] #1822: Panic in template haskell In-Reply-To: <044.ee08e08803700b95c663a361c0274a73@localhost> References: <044.ee08e08803700b95c663a361c0274a73@localhost> Message-ID: <053.d059abd3f0ee6ce06ec7d73c51076846@localhost> #1822: Panic in template haskell ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------+--------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Happily, I think this is fixed in 6.8: {{{ Test_gen.hs:50:66: Stage error: the non-top-level quoted name 'stuff must be used at the same stage at which is is bound In the expression: 'stuff In the expression: ('stuff, VarE s) In the second argument of `RecUpdE', namely `[('stuff, VarE s)]' }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Fri Nov 2 23:52:12 2007 From: conal at conal.net (Conal Elliott) Date: Fri Nov 2 23:49:27 2007 Subject: =?windows-1252?q?Re=3A_=5BGHC=5D_=231712=3A_unknown_symbol_=93gl?= =?windows-1252?q?utGet=94?= In-Reply-To: <074.9516eab873ea1fff15af2e414550b3fa@localhost> References: <065.b6ed7b12defb8965a01b63493858f588@localhost> <074.9516eab873ea1fff15af2e414550b3fa@localhost> Message-ID: I'm getting this same symptom with the 20071102 mingw32 binary snapshot. I installed the OpenGL and FreeGLUT headers & libs from Cygwin. Any suggestions? - Conal bash-3.2$ which ghc /cygdrive/c/ghc/ghc-6.8.1.20071102/bin/ghc bash-3.2$ ghc -package GLUT Hello.hs compilation IS NOT required c:/Haskell/packages\GLUT-2.1.1.1\ghc-6.8.1.20071102/libHSGLUT-2.1.1.1.a( Begin.o)(.text+0x1d3):fake: undefined reference to `glutGet' ... On 10/28/07, GHC wrote: > > #1712: unknown symbol "glutGet" > > -------------------------------------------+-------------------------------- > Reporter: g9ks157k@acme.softbase.org | Owner: > Type: bug | Status: new > Priority: normal | Milestone: 6.8.1 > Component: Compiler | Version: 6.8 > Severity: normal | Resolution: > Keywords: | Difficulty: Unknown > Os: Linux | Testcase: > Architecture: x86 | > > -------------------------------------------+-------------------------------- > Changes (by igloo): > > * owner: Sven Panne => > * milestone: Not GHC => 6.8.1 > > Comment: > > Aha, I hadn't noticed that this was from a bindist. OK, the problem is > that we weren't copying the .buildinfo files into the bindist, so we > didn't have the info to fill in the necessary ld-options etc. Hopefully > tonight's bindist will work. > > By the way, Simon Marlow: The x86_64 builds seem to be missing GLUT, and > the i386 builds missing ALUT and OpenAL, presumably all due to missing C > libraries. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20071102/a89b6763/attachment.htm From conal at conal.net Fri Nov 2 23:55:27 2007 From: conal at conal.net (Conal Elliott) Date: Fri Nov 2 23:52:42 2007 Subject: =?windows-1252?q?Re=3A_=5BGHC=5D_=231712=3A_unknown_symbol_=93gl?= =?windows-1252?q?utGet=94?= In-Reply-To: References: <065.b6ed7b12defb8965a01b63493858f588@localhost> <074.9516eab873ea1fff15af2e414550b3fa@localhost> Message-ID: strangely, i can run the program under ghci. though my ghci session is wedged after i close the program. On 11/2/07, Conal Elliott wrote: > > I'm getting this same symptom with the 20071102 mingw32 binary snapshot. > I installed the OpenGL and FreeGLUT headers & libs from Cygwin. Any > suggestions? - Conal > > bash-3.2$ which ghc > /cygdrive/c/ghc/ghc- 6.8.1.20071102/bin/ghc > bash-3.2$ ghc -package GLUT Hello.hs > compilation IS NOT required > c:/Haskell/packages\GLUT-2.1.1.1\ghc-6.8.1.20071102/libHSGLUT-2.1.1.1.a( > Begin.o)(.text+0x1d3):fake: undefined reference to `glutGet' > ... > > On 10/28/07, GHC wrote: > > > #1712: unknown symbol "glutGet" > > > > -------------------------------------------+-------------------------------- > > Reporter: g9ks157k@acme.softbase.org | Owner: > > Type: bug | Status: new > > Priority: normal | Milestone: 6.8.1 > > Component: Compiler | Version: 6.8 > > Severity: normal | Resolution: > > Keywords: | Difficulty: Unknown > > Os: Linux | Testcase: > > Architecture: x86 | > > -------------------------------------------+-------------------------------- > > > > Changes (by igloo): > > > > * owner: Sven Panne => > > * milestone: Not GHC => 6.8.1 > > > > Comment: > > > > Aha, I hadn't noticed that this was from a bindist. OK, the problem is > > that we weren't copying the .buildinfo files into the bindist, so we > > didn't have the info to fill in the necessary ld-options etc. Hopefully > > tonight's bindist will work. > > > > By the way, Simon Marlow: The x86_64 builds seem to be missing GLUT, and > > > > the i386 builds missing ALUT and OpenAL, presumably all due to missing C > > libraries. > > > > -- > > Ticket URL: > > GHC > > The Glasgow Haskell Compiler > > _______________________________________________ > > Glasgow-haskell-bugs mailing list > > Glasgow-haskell-bugs@haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20071102/3e2f8cc9/attachment-0001.htm From trac at galois.com Sat Nov 3 03:00:54 2007 From: trac at galois.com (GHC) Date: Sat Nov 3 02:58:45 2007 Subject: [GHC] #1741: Threaded RTS must use processor affinity and processor information In-Reply-To: <044.e4defb5de192ad7951ca4bf955f5c177@localhost> References: <044.e4defb5de192ad7951ca4bf955f5c177@localhost> Message-ID: <053.c1198d81a4cc040a331f7897887a9423@localhost> #1741: Threaded RTS must use processor affinity and processor information ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: task | Status: new Priority: normal | Milestone: 6.8 branch Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Comment (by guest): Replying to [comment:2 simonmar]: > One problem with setting `-N` to something other than 1 by default is that `System.Posix.forkProcess` only works with `-N1`, so if you use that function then you need to fix `-N1` somehow (probably with a hook). I'm not sure I want to contemplate making `forkProcess` work for larger values of N. I suspect `forkProcess` is rare, and we might want to deprecate it anyway. Does anyone have opinion about it? I think that if someone want to use -threaded option, he want to use more than 2-core normally. So setting -N to 1 by default isn't good solution. I think that writing about this problem on Haddock System.Posix.forkProcess document, and then deprecating `forkProcess` is better solution. Because if someone can't find `forkProcess` problem in document, he cann't decide to use `forkProcess` or not. His program works well with default -N1, but he suddenly encounts problem when setting option -N to parallelize his program. That isn't good. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 3 11:30:04 2007 From: trac at galois.com (GHC) Date: Sat Nov 3 11:27:18 2007 Subject: [GHC] #1824: Make an extension flag for postfix operators Message-ID: <044.3feac532d20baf671d78343c6784773a@localhost> #1824: Make an extension flag for postfix operators ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Parser) | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- From this thread: http://www.haskell.org/pipermail/cvs- ghc/2007-November/039289.html {{{ > 2 while looking up 8.3.7, i saw this note in 8.3.6, on > postfix operators: > > "(No Haskell 98 programs change their behaviour, of course.)" > > like so many "of course" notes, this is wrong, of course;-) > haskell98 has seq, and that makes eta-expansion observable. > > $ /cygdrive/c/ghc/ghc-6.4.1/bin/ghc -e > 'let (!) a = undefined in (undefined !) `seq` True' > True > > $ /cygdrive/c/ghc/ghc-6.6.1/bin/ghc -e > 'let (!) a = undefined in (undefined !) `seq` True' > *** Exception: Prelude.undefined Good point. We probably ought to make it an extension and give it a -X flag anyway; I don't think (without having looked at the code) it should be hard. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Nov 3 12:30:42 2007 From: trac at galois.com (GHC) Date: Sat Nov 3 12:28:29 2007 Subject: [GHC] #1824: Make an extension flag for postfix operators In-Reply-To: <044.3feac532d20baf671d78343c6784773a@localhost> References: <044.3feac532d20baf671d78343c6784773a@localhost> Message-ID: <053.db56768391046860baee9efbca631984@localhost> #1824: Make an extension flag for postfix operators -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Parser) | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by guest): actually, since this has been default behaviour in 6.6.1, and in hugs for quite a bit longer, it doesn't seem to have bitten anyone, so i was just asking for the docs to be amended. claus -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 03:20:35 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 05:01:27 2007 Subject: [GHC] #1825: standalone deriving for typeable fails Message-ID: <049.5809fb5e9141c3e792314e93f41d7b88@localhost> #1825: standalone deriving for typeable fails ---------------------------+------------------------------------------------ Reporter: jpbernardy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ---------------------------+------------------------------------------------ {{{ import Data.Typeable data D a = C1 a | C2 (D a) deriving instance Typeable a => Typeable (D a) -- deriving Typeable x = show $ typeOf (undefined::D Int) main = print x }}} yields: {{{ [1 of 1] Compiling Main ( T.hs, T.o ) ghc-6.8.1: panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-unknown-linux): No match in record selector Var.tcTyVarDetails }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 08:34:44 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 08:32:28 2007 Subject: [GHC] #1826: unable to list source for should never occur Message-ID: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost> #1826: unable to list source for should never occur --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- I get the very unhelpful "unable to list source for ". I would like to get one of the following two responses, the last one is best. {{{ Do this and that to list source }}} {{{ We currently cannot list source, because you did and that Do you still want to list source although it requires to do that and that(for example automatically recompiling and reexecuting it until the same program point) [Y/n]? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 08:35:06 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 08:32:50 2007 Subject: [GHC] #1826: unable to list source for should never occur In-Reply-To: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost> References: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost> Message-ID: <053.55332ee68a4adb76bca1dd1c348fc8a5@localhost> #1826: unable to list source for should never occur -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by guest): * cc: iampure@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 12:55:33 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 12:53:18 2007 Subject: [GHC] #1827: :print panics GHCi Message-ID: <044.a0660831f23b7993165edfe4aa23a7cf@localhost> #1827: :print panics GHCi -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.1 Component: GHCi | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Multiple | Os: Unknown -------------------------+-------------------------------------------------- After starting GHCi, using the debugger to print certain functions causes a panic. For example, the following statements all cause GHCi to panic and quit: {{{ :print (+) :print print :print log }}} Other functions, such as {{{head}}}, {{{tail}}}, and {{{fst}}} are shown by the debugger properly as {{{}}}, with no error. This behavior is identical on PPC and i386 platforms, running OS X (10.4/10.5 respectively). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 14:08:36 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 14:06:21 2007 Subject: [GHC] #1827: :print panics GHCi with overloaded values In-Reply-To: <044.a0660831f23b7993165edfe4aa23a7cf@localhost> References: <044.a0660831f23b7993165edfe4aa23a7cf@localhost> Message-ID: <053.a9db70b4d128a7b065bc729430490481@localhost> #1827: :print panics GHCi with overloaded values ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by sorear): * summary: :print panics GHCi => :print panics GHCi with overloaded values * os: Unknown => Multiple * milestone: 6.8.1 => Comment: Thanks very much for the report. To GHC HQ: I can reproduce this with any value whose type has class constraints, on GHC 6.7.20070829, on Linux/i386. To the reporter: If you put an e-mail address in the Reporter field, you will receive e-mail notification on comments or status changes; this is much easier than re-checking the tracker! Also, the Milestone field is for internal triage and is not intended to be set by reporters. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 15:17:31 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 15:15:14 2007 Subject: [GHC] #1828: ghc doesn't properly quote space-containing paths on Windows. Message-ID: <044.0f307f5f1e39684f3d892d325b5ad8c8@localhost> #1828: ghc doesn't properly quote space-containing paths on Windows. -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Multiple | Os: Windows -------------------------+-------------------------------------------------- 1) Install ghc 6.8.1 on Windows XP to "C:\Program Files\ghc\".[[BR]] 2) Run `ghc newton.hs` (any hs file should work here) from your home directory. Output :[[BR]] {{{ 'C:\Program' is not recognized as an internal or external command, operable program or batch file. C:\Program Files\ghc\bin/windres: no resources }}} Something somewhere in the compilation process seems to try to run something in "C:\Program Files\ghc\" but, even though the program it wants to run has spaces in its path, it doesn't quote it properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 15:31:53 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 15:29:03 2007 Subject: [GHC] #1829: Fix test case outofmem for PPC Mac OS X Message-ID: <050.0750d4282895aec58996bdef44f636fd@localhost> #1829: Fix test case outofmem for PPC Mac OS X ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: outofmem Architecture: powerpc | Os: MacOS X ----------------------------+----------------------------------------------- Running validate on my PPC Mac OS X has for some time reported {{{ Unexpected failures: arrow(normal) arrowrun003(normal) divbyzero(normal) outofmem(normal) }}} with detailed report for outofmem(normal) {{{ =====> outofmem(normal)cd ./rts && '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling- and-copying-20070713_1212/ghc/compiler/stage2/ghc-inplace' -no-recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -o outofmem outofmem.hs >outofmem.comp.stderr 2>&1 cd ./rts && ./outofmem outofmem.run.stdout 2>outofmem.run.stderr Actual stderr output differs from expected: --- ./rts/outofmem.stderr.normalised 2007-11-04 16:09:33.000000000 +0100 +++ ./rts/outofmem.run.stderr.normalised 2007-11-04 16:09:33.000000000 +0100 @@ -1 +1 @@ -outofmem: out of memory +outofmem: memory allocation failed (requested 1074790400 bytes) *** unexpected failure for outofmem(normal) }}} This is clearly a simple case of an error message that differs in a non- essential way. The attached patch supplies a specific stderr output file for powerpc_apple_darwin to fix this problem. With this change, validate reports {{{ OVERALL SUMMARY for test run started at Sun Nov 4 19:25:15 CET 2007 1988 total tests, which gave rise to 7591 test cases, of which 0 caused framework failures 5932 were skipped 1582 expected passes 74 expected failures 0 unexpected passes 3 unexpected failures Unexpected failures: arrow(normal) arrowrun003(normal) divbyzero(normal) }}} so at least, no harm seems to be done by this patch. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 16:03:14 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 16:00:59 2007 Subject: [GHC] #1830: Automatic derivation of Lift Message-ID: <044.3eb409743bc4021eb94e63cb46f573bc@localhost> #1830: Automatic derivation of Lift --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: Template Haskell Version: 6.8.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- This feature request was brought up in this template-haskell thread[1]: There are apparently two implementation alternatives: 1) Merge Ian's th-lift library[2] with the mainstream template-haskell library 2) Implement "instance Data a => Lift a" (requires allowing undecidable and overlapping instances) in template-haskell. Since Data can be derived automatically by GHC, such an instance would imply automatic derivation of Lift as well. [1] http://www.haskell.org/pipermail/template- haskell/2007-October/000635.html [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/th-lift-0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 16:36:21 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 16:34:07 2007 Subject: [GHC] #1827: :print panics GHCi with overloaded values In-Reply-To: <044.a0660831f23b7993165edfe4aa23a7cf@localhost> References: <044.a0660831f23b7993165edfe4aa23a7cf@localhost> Message-ID: <053.159154c702201335c98cb8fefafaf543@localhost> #1827: :print panics GHCi with overloaded values ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Comment (by scsibug@imap.cc): Replying to [comment:1 sorear]: > Thanks very much for the report. > > To GHC HQ: I can reproduce this with any value whose type has class constraints, on GHC 6.7.20070829, on Linux/i386. > > To the reporter: If you put an e-mail address in the Reporter field, you will receive e-mail notification on comments or status changes; this is much easier than re-checking the tracker! Also, the Milestone field is for internal triage and is not intended to be set by reporters. Thanks for the tips. I was logged in as guest accidentally. Greg Heartsfield -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 17:32:32 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 17:30:15 2007 Subject: [GHC] #1831: reify never provides the declaration of variables Message-ID: <044.a26292943bffdeb4bdb3ded03525ce1f@localhost> #1831: reify never provides the declaration of variables ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 6.8.1 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- The information returned by reify when provided a variable Name is {{{ VarI Name Type (Maybe Dec) Fixity }}} The Dec part, due to be nested in Maybe, is clearly optional. In fact, according to Language.Haskell.TH.Syntax: {{{ -- Nothing for lambda-bound variables, and -- for anything else TH can't figure out -- E.g. [| let x = 1 in $(do { d <- reify 'x; .. }) |] }}} However, the typechecker (TcSplice module) always returns Nothing. So it's simply not implemented. I suggest either implementing the feature or removing the Dec part of VarI. Either way, the type should be consistent with the features offered in TH. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 17:33:19 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 17:36:06 2007 Subject: [GHC] #1831: reify never provides the declaration of variables In-Reply-To: <044.a26292943bffdeb4bdb3ded03525ce1f@localhost> References: <044.a26292943bffdeb4bdb3ded03525ce1f@localhost> Message-ID: <053.997106376f09ccce8dca3d370de963ed@localhost> #1831: reify never provides the declaration of variables ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------+------------------------------------------ Changes (by guest): * cc: alfonso.acosta@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 19:51:18 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 19:49:05 2007 Subject: [GHC] #1692: GLUT timedCallback fires twice In-Reply-To: <061.d698001f3455c11cda9f1f4fdc7bdeb4@localhost> References: <061.d698001f3455c11cda9f1f4fdc7bdeb4@localhost> Message-ID: <070.1f1eda1b57ba1f1366f27c3aff9a1081@localhost> #1692: GLUT timedCallback fires twice ------------------------------------+--------------------------------------- Reporter: richardg@richardg.name | Owner: sven.panne@aedion.de Type: task | Status: new Priority: normal | Milestone: Not GHC Component: None | Version: 6.2.2 Severity: normal | Resolution: Keywords: Darlazru | Difficulty: Unknown Testcase: Darlazru | Architecture: powerpc Os: MacOS X | ------------------------------------+--------------------------------------- Changes (by Evanvtu): * component: libraries (other) => None * testcase: => Darlazru * version: 6.6.1 => 6.2.2 * architecture: x86 => powerpc * keywords: => Darlazru * type: bug => task Comment: http://wrrrbwwfrbeeb.host.com desk3 [url=http://wrrsbwwfrbeeb.host.com]desk4[/url] [link=http://wrrabwwfrbeeb.host.com]desk6[/link] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 21:05:07 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 21:02:54 2007 Subject: [GHC] #1808: type families: impossible happened, at runtime in GHCi In-Reply-To: <044.23d947ae58e490e14ad04f2f0cd07bb9@localhost> References: <044.23d947ae58e490e14ad04f2f0cd07bb9@localhost> Message-ID: <053.621ecca4417a6b7cda49477883581378@localhost> #1808: type families: impossible happened, at runtime in GHCi ----------------------+----------------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by chak): * owner: => chak Comment: Probably the same problem as #1754. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 21:10:20 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 21:08:07 2007 Subject: [GHC] #1809: type families: difference in type-checking between compile-time and run-time In-Reply-To: <044.879122f54c5461e5758b1573a08f9e47@localhost> References: <044.879122f54c5461e5758b1573a08f9e47@localhost> Message-ID: <053.12d2bb7bb9559f0b7b274080fd83f707@localhost> #1809: type families: difference in type-checking between compile-time and run- time ----------------------+----------------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by chak): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Nov 4 21:18:53 2007 From: trac at galois.com (GHC) Date: Sun Nov 4 21:16:43 2007 Subject: [GHC] #1815: Occurs check error from equality constraint In-Reply-To: <044.12ef3f0044b7bf4b638b448ce311cbef@localhost> References: <044.12ef3f0044b7bf4b638b448ce311cbef@localhost> Message-ID: <053.306c96bb7acfb65d8f07f3d9404e0b81@localhost> #1815: Occurs check error from equality constraint -------------------------------------+-------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by chak): * owner: => chak * milestone: => 6.10 branch Comment: At the moment type families/equality constraints are not fully integrated with GADTs yet. This should change soon and then this problem should also go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 05:09:36 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 05:07:26 2007 Subject: [GHC] #366: incomplete patterns and GADT In-Reply-To: <045.78fabe56a37c24d921b345c081d108ef@localhost> References: <045.78fabe56a37c24d921b345c081d108ef@localhost> Message-ID: <054.608b0cf7027d1a863dc2fb35eea2149e@localhost> #366: incomplete patterns and GADT -----------------------------+---------------------------------------------- Reporter: nobody | Owner: nobody Type: feature request | Status: assigned Priority: normal | Milestone: 6.10 branch Component: None | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Unknown Testcase: tc215 | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * cc: drl@cs.cmu.edu (added) * milestone: 6.8 branch => 6.10 branch Comment: Dan Licata is planning to work on this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 05:42:12 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 05:39:53 2007 Subject: [GHC] #1243: Linking error of ALUT In-Reply-To: <044.2feffd6ddf35892ecb5ad72d01a1acf8@localhost> References: <044.2feffd6ddf35892ecb5ad72d01a1acf8@localhost> Message-ID: <053.afbb4eda5a2061b49858bdb23e726bda@localhost> #1243: Linking error of ALUT -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Comment (by guest): Okay, I know what is a problem. freealut changes calling convention from stdcall to ccall on Windows. And then configure.ac can't choice correct calling convention. I tested old version, so I can't find this problem. attachment:"alut-windows.patch" is solution of this problem. And I know this problem is same as OpenAL's one (#1140). So I hope fixing both problem at once. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 05:42:44 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 05:40:25 2007 Subject: [GHC] #1226: Add flags --full-flag-help and --print-docdir In-Reply-To: <044.6dc8606b5b04e81a01eca3b1719deb81@localhost> References: <044.6dc8606b5b04e81a01eca3b1719deb81@localhost> Message-ID: <053.f9355bcc72a4b56a353d8263e0e53dd0@localhost> #1226: Add flags --full-flag-help and --print-docdir -----------------------------+---------------------------------------------- Reporter: igloo | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.8 branch Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by simonmar): I object quite strongly to the idea that it is our job to compensate for the lack of good text manipulation tools on Windows. We should not bloat GHC with functionality that can easily be provided by other tools. Anyone using the command line on Windows will pretty quickly run into its limitations and install Cygwin or something else. In any case, a more Windows-y thing to do would be to pop up a web browser on the flag index page. Then if you're using Firefox you can use `/string` to search. The easiest thing we could do is to add a link to the start menu group for GHC pointing directly to the flag index. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 05:43:04 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 05:40:45 2007 Subject: [GHC] #1243: Linking error of ALUT In-Reply-To: <044.2feffd6ddf35892ecb5ad72d01a1acf8@localhost> References: <044.2feffd6ddf35892ecb5ad72d01a1acf8@localhost> Message-ID: <053.bfc7ef16205ee615bacedf4a9c99154e@localhost> #1243: Linking error of ALUT -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -------------------------------+-------------------------------------------- Changes (by guest): * cc: shelarcy@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 05:59:58 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 05:57:44 2007 Subject: [GHC] #1826: unable to list source for should never occur In-Reply-To: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost> References: <044.f94ec6280873c17dbdd2473c81e3b4a3@localhost> Message-ID: <053.ba7e0d6af6ab1fef4aa9c547bdb0e57d@localhost> #1826: unable to list source for should never occur -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * milestone: => 6.8 branch Comment: Ok, would this help? {{{ Source location of exception is unknown, try `:back` and then `:list`. }}} or if you're not using `:trace` it would suggest doing that first. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 06:07:20 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 06:04:27 2007 Subject: [GHC] #1829: Fix test case outofmem for PPC Mac OS X In-Reply-To: <050.0750d4282895aec58996bdef44f636fd@localhost> References: <050.0750d4282895aec58996bdef44f636fd@localhost> Message-ID: <059.53de6af1cb310381db87c94ff5940008@localhost> #1829: Fix test case outofmem for PPC Mac OS X -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: outofmem | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: ok, I'll apply -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 06:10:33 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 06:08:21 2007 Subject: [GHC] #1827: :print panics GHCi with overloaded values In-Reply-To: <044.a0660831f23b7993165edfe4aa23a7cf@localhost> References: <044.a0660831f23b7993165edfe4aa23a7cf@localhost> Message-ID: <053.5cc9ce3fac09c64ffa718c50d1d12670@localhost> #1827: :print panics GHCi with overloaded values ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by simonmar): * milestone: => 6.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 07:21:17 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 07:18:39 2007 Subject: [GHC] #1195: Build error on MacOSX (Intel) 10.4.8 for HEAD from 2007-03-05 when compiling with ghc-6.6 In-Reply-To: <057.719a01964090b36cbdf61fcc731a9550@localhost> References: <057.719a01964090b36cbdf61fcc731a9550@localhost> Message-ID: <066.bfd8e657cc5f900f32329d834ab80f2f@localhost> #1195: Build error on MacOSX (Intel) 10.4.8 for HEAD from 2007-03-05 when compiling with ghc-6.6 --------------------------------+------------------------------------------- Reporter: nominolo@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.2 Component: libraries/base | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | --------------------------------+------------------------------------------- Comment (by simonmar): Thomas, I presume this isn't happening for you any more? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 07:24:23 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 07:21:49 2007 Subject: [GHC] #716: Unloading a dll generated by GHC doesn't free all resources In-Reply-To: <061.51e2f862f63d8c201b1536a263740851@localhost> References: <061.51e2f862f63d8c201b1536a263740851@localhost> Message-ID: <070.cc782a7ad60f92bb9a44ccf7353c5f9f@localhost> #716: Unloading a dll generated by GHC doesn't free all resources ------------------------------------+--------------------------------------- Reporter: lennart@augustsson.net | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.6.2 Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------+--------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: The only remaining issue related to this is #1663, as far as I know. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 07:26:44 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 07:24:06 2007 Subject: [GHC] #738: ghc can't load files with selinux Enforcing In-Reply-To: <065.24a0770a4c910c3e35b946b29e1c1608@localhost> References: <065.24a0770a4c910c3e35b946b29e1c1608@localhost> Message-ID: <074.e1411d5edf7d8ace99a25feab2847ff5@localhost> #738: ghc can't load files with selinux Enforcing ----------------------------------------+----------------------------------- Reporter: jon.fairbairn@cl.cam.ac.uk | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.8 branch Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: selinux | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Changes (by simonmar): * milestone: 6.6.2 => 6.8 branch Comment: This will become important as more distributions turn on SELinux. #793 is the ticket for switching to `libffi`, currently pending someone doing a feasibilty study. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 07:28:37 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 07:25:44 2007 Subject: [GHC] #1165: clausify has a space leak with -O2 In-Reply-To: <047.9a2110feac38c1b58140592ead6d6ceb@localhost> References: <047.9a2110feac38c1b58140592ead6d6ceb@localhost> Message-ID: <056.20ce82a7c9dd97ff489d162e1d2e0b21@localhost> #1165: clausify has a space leak with -O2 -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.2 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: nofib/spectral/clausify | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: confirmed as not present in 6.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 07:31:10 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 07:28:16 2007 Subject: [GHC] #1168: nofib/spectral/calendar is mis-optimised In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@localhost> References: <047.1e9bce153303809272446b6c0aede02d@localhost> Message-ID: <056.4c382f70f9125e0eb1a5926ac0e53d1c@localhost> #1168: nofib/spectral/calendar is mis-optimised -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: nofib/spectral/calendar | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonmar): * milestone: 6.6.2 => _|_ Comment: I don't think we're going to fix this any time soon. The simplifier is eta-expanding `State#` lambdas on purpose, because it's often critical for good performance of IO code, but it does risk re-computation in some cases, and this is one of those cases. Leaving the bug open because it is a real bug, someday we might implement something a bit more refined (e.g. arity analysis). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 08:57:40 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 08:54:47 2007 Subject: [GHC] #1829: Fix test case outofmem for PPC Mac OS X In-Reply-To: <050.0750d4282895aec58996bdef44f636fd@localhost> References: <050.0750d4282895aec58996bdef44f636fd@localhost> Message-ID: <059.864de103493edb4499074cd59826b284@localhost> #1829: Fix test case outofmem for PPC Mac OS X -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: outofmem | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 09:28:27 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 09:25:47 2007 Subject: [GHC] #1825: standalone deriving for typeable fails In-Reply-To: <049.5809fb5e9141c3e792314e93f41d7b88@localhost> References: <049.5809fb5e9141c3e792314e93f41d7b88@localhost> Message-ID: <058.fcfb58c3547a0396cbb7b0480988973d@localhost> #1825: standalone deriving for typeable fails ------------------------+--------------------------------------------------- Reporter: jpbernardy | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------+--------------------------------------------------- Changes (by simonpj): * owner: => simonpj * milestone: => 6.8.2 Comment: Oh bother! The deriving for `Typeable` is unique. If you use the `deriving` clause on the `data` decl, you'll get this instance: {{{ instance Typeable1 D where typeOf1 _ = mkTyConApp (mkTyCon "D") [] }}} So that's what the user should write in a standalone deriving clause too. thus {{{ deriving instance Typeable1 D }}} (There's a uniform instance for type applications.) Sadly, GHC 6.8.1 rejects the above because "`Typeable1` is not a derivable class". Ok so this is broken and there's no workaround. I will milestone it for 6.8.1. What I propose is to require you to write "`deriving instance Typeable1 D`". That's not as obvious as the declaration you started with, but it fits with the current impl, and with the (current) Typeable design; see Section 7.4 of [http://www.cs.vu.nl/boilerplate/gmap2.pdf the second SYB paper]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 09:39:16 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 09:36:27 2007 Subject: [GHC] #1825: standalone deriving for typeable fails In-Reply-To: <049.5809fb5e9141c3e792314e93f41d7b88@localhost> References: <049.5809fb5e9141c3e792314e93f41d7b88@localhost> Message-ID: <058.5c00629c57c115bf91db951015301f3d@localhost> #1825: standalone deriving for typeable fails ------------------------+--------------------------------------------------- Reporter: jpbernardy | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------+--------------------------------------------------- Comment (by simonpj): PS: a smaller program that generates the error, when compiled with `-dcore-lint` is: {{{ {-# OPTIONS -dcore-lint -XDeriveDataTypeable -XStandaloneDeriving #-} module Foo where data D a = C1 a | C2 (D a) deriving instance Typeable a => Typeable (D a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 10:01:03 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 09:58:11 2007 Subject: [GHC] #1825: standalone deriving for typeable fails In-Reply-To: <049.5809fb5e9141c3e792314e93f41d7b88@localhost> References: <049.5809fb5e9141c3e792314e93f41d7b88@localhost> Message-ID: <058.082e35d5134c3f8fbae1a9dfc446f434@localhost> #1825: standalone deriving for typeable fails ------------------------+--------------------------------------------------- Reporter: jpbernardy | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------+--------------------------------------------------- Comment (by igloo): Is it hard to do the same magic for "deriving instance Typeable ..." that is done for "data ... deriving Typeable"? It seems a bit unpleasant that the same thing doesn't work in both cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 10:57:16 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 10:54:57 2007 Subject: [GHC] #1501: Panic in RegisterAlloc In-Reply-To: <044.f7c3918326114c19463f5f9e9eea6707@localhost> References: <044.f7c3918326114c19463f5f9e9eea6707@localhost> Message-ID: <053.a8a92a45cecdac8924e18157753b2a3a@localhost> #1501: Panic in RegisterAlloc ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (NCG) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: cmm002 | Architecture: x86 Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 11:01:22 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 10:58:33 2007 Subject: [GHC] #1574: Broken link testing In-Reply-To: <056.4175938f47088948409e38405f44cd8f@localhost> References: <056.4175938f47088948409e38405f44cd8f@localhost> Message-ID: <065.bb60f24f07d9fb41214c0698f28be77b@localhost> #1574: Broken link testing -------------------------------+-------------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.8.2 Component: Documentation | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * summary: Broken link => Broken link testing * type: bug => feature request * milestone: => 6.8.2 Comment: The case you give has been fixed. I'm not sure what's best for automatic testing (if you include links to external sites). Do we really want to do it every night? How would we handle transient failures? We should probably do something, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 11:06:23 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 11:03:30 2007 Subject: [GHC] #1579: instance Read Integer contradicts Haskell98 In-Reply-To: <051.6921aabdfe30316c83b43a5f181003cc@localhost> References: <051.6921aabdfe30316c83b43a5f181003cc@localhost> Message-ID: <060.20afeef499cf786393a710c3b36752cb@localhost> #1579: instance Read Integer contradicts Haskell98 ----------------------------+----------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch Comment: Thanks for the report; there's also a bug in bugs.xml (in the users guide) about Read Integer allowing hexadecimal and octal values. We should either fix these in 6.10 (the next chance we have) or convince Haskell' to agree with us. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 11:15:11 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 11:12:17 2007 Subject: [GHC] #1588: unrequested generalized newtype deriving? In-Reply-To: <043.164cb560745758311708c93e889e5a5e@localhost> References: <043.164cb560745758311708c93e889e5a5e@localhost> Message-ID: <052.b99a44a3415e489228a191ef47b9f4a3@localhost> #1588: unrequested generalized newtype deriving? ----------------------+----------------------------------------------------- Reporter: SamB | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.1 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo * milestone: => 6.8.1 Comment: Thanks for the report; these both give me: {{{ No instance for (Eq (m (Maybe a))) arising from the 'deriving' clause of a data type declaration at z.hs:2:0-70 Possible fix: add an instance declaration for (Eq (m (Maybe a))) When deriving the instance for (Eq (MaybeT m a)) }}} with GHC 6.8.1. I'll add your testcase to the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 11:20:45 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 11:18:38 2007 Subject: [GHC] #1592: Unexpected boxing in generated code In-Reply-To: <043.c04e3bd244a4eae851af8c18594bf095@localhost> References: <043.c04e3bd244a4eae851af8c18594bf095@localhost> Message-ID: <052.c875d483b00a714a47b801e1d42b7c82@localhost> #1592: Unexpected boxing in generated code ----------------------+----------------------------------------------------- Reporter: neil | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch Comment: Simon's argument that GHC is doing the right thing sounds right to me; should we close this bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 11:25:49 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 11:22:55 2007 Subject: [GHC] #1603: a miscompilation of (`rem` 0x40000000)::Int with -O -fvia-C In-Reply-To: <051.236bdfc382b4b8b333be4e1f7b023bf9@localhost> References: <051.236bdfc382b4b8b333be4e1f7b023bf9@localhost> Message-ID: <060.40953551ce07689960c2ea3b6a76a510@localhost> #1603: a miscompilation of (`rem` 0x40000000)::Int with -O -fvia-C --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: => 6.8.2 Comment: Thanks for the report. Confirmed on amd64/Linux with GHC 6.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 11:29:49 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 11:27:30 2007 Subject: [GHC] #1605: hppa port -- gmp handed misaligned memory In-Reply-To: <044.7ca61f85138b90c0e193b83a232b3207@localhost> References: <044.7ca61f85138b90c0e193b83a232b3207@localhost> Message-ID: <053.8e0dcba62f874f40caa6f5af561de05b@localhost> #1605: hppa port -- gmp handed misaligned memory ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: GMP | Difficulty: Easy (1 hr) Testcase: | Architecture: hppa Os: HPUX | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => 6.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 11:32:43 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 11:29:49 2007 Subject: [GHC] #1612: GHC_PACKAGE_PATH and $topdir bug In-Reply-To: <047.68efe858edf43056de08968f61a7dc37@localhost> References: <047.68efe858edf43056de08968f61a7dc37@localhost> Message-ID: <056.359ed2463a0e0087ce3fac4805d19434@localhost> #1612: GHC_PACKAGE_PATH and $topdir bug ----------------------+----------------------------------------------------- Reporter: eivuokko | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch Comment: Thanks for the report. We probably shouldn't change this in the 6.8 branch, although it is unlikely it would affect anyone. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 11:34:03 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 11:31:09 2007 Subject: [GHC] #1617: :types (or :browse! ) - browse plain types, not in context, for IDEs In-Reply-To: <044.6ad0239c71e1dc43b5fbf507cda8ca1a@localhost> References: <044.6ad0239c71e1dc43b5fbf507cda8ca1a@localhost> Message-ID: <053.31b0323ebde11b153d6850bc5f24c057@localhost> #1617: :types (or :browse! ) - browse plain types, not in context, for IDEs ---------------------+------------------------------------------------------ Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 11:53:07 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 11:50:48 2007 Subject: [GHC] #1617: :types (or :browse! ) - browse plain types, not in context, for IDEs In-Reply-To: <044.6ad0239c71e1dc43b5fbf507cda8ca1a@localhost> References: <044.6ad0239c71e1dc43b5fbf507cda8ca1a@localhost> Message-ID: <053.f765e616f78c575bbd7c21b486ce77bb@localhost> #1617: :types (or :browse! ) - browse plain types, not in context, for IDEs ---------------------+------------------------------------------------------ Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Comment (by guest): the latest version of a patch (under review) implementing :browse!, among other things, is here http://www.haskell.org/pipermail/cvs-ghc/2007-October/039131.html there is a separate issue with the order of :browse output, which hampers testing (#1799). for reference, this ticket lists three issues, of which my patch fixes the first two: - missing children - missing info about qualified imports - incorrect (old) browse* info after :reload the third issue is likely to be in the same corner as ordering #1799 (on the theory that a fresh load/reload ought to bring in items in export order instead of leaving items already in there from previous usage, with out-of-order uniqueIds). claus -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 12:02:42 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 11:59:53 2007 Subject: [GHC] #1619: The RTS chokes on SIGPIPE (happens with runInteractiveCommand) In-Reply-To: <044.b1c078255d6a68ad73f85282a9d62782@localhost> References: <044.b1c078255d6a68ad73f85282a9d62782@localhost> Message-ID: <053.34d90cd63230ae4ae2aa032985c5cd4f@localhost> #1619: The RTS chokes on SIGPIPE (happens with runInteractiveCommand) ----------------------------+----------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 12:03:59 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 12:01:41 2007 Subject: [GHC] #1621: GHCi wrong execution time report In-Reply-To: <044.547081dc40bbb750c3a7c7bbe4e4a502@localhost> References: <044.547081dc40bbb750c3a7c7bbe4e4a502@localhost> Message-ID: <053.18f53601fcaf52478f196021d5662239@localhost> #1621: GHCi wrong execution time report ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------+------------------------------------------------------ Old description: > Hello, > > using latest GHC 6.6.1 binary package for windows, I've received > strange information about execution time for the module below. > > My machine: OS WinXP Pro SP2, Intel Core 2, 2GB RAM. > > How to reproduce error: > > :set +s > :set -02 > :cd > :l Primes > > Then running > take 10000 primes1 > take 10000 primes2 > take 10000 primes3 > take 10000 primes1' > take 10000 primes2' > take 10000 primes3' > > Results seem to be correct, but the execution time reported no. First > column is the GHCi report, the second column is th stop-watch data (just > to correlate). No other task, except core windows, was running at the > moment. > > GHCi Stop-watch > 236.03 672.2 > 63.52 63.9 > 63.01 64.0 > 1098.75 671.0 > -365.07 65.2 // it's not a typo, really minus three hundred and > sixty five > 63.59 63.6 > > Best regards, > > Dusan > > --------- > module Primes ( > primes1 > ,primes2 > ,primes3 > ,primes2' > ,primes3' > ) where > > candidates = map (\x -> (True,x)) [2..] > candidates' = [2..] > > skipmap f toSkip list = domap toSkip list > where > domap n (x:xs) > | n > 1 = x : domap (n-1) xs > | True = f x : domap toSkip xs > domap _ [] = [] > > primes1 = sieve candidates > where > sieve (pp@(isp,p):xs) > | isp = p : (sieve $ skipmap (\(_,v) -> (False,v)) p xs) > | True = sieve xs > > primes1' = sieve candidates' > where > sieve (p:xs) > | p > 0 = p : (sieve $ skipmap (\n -> if n>0 then (-n) else n) p > xs) > | True = sieve xs > > > sieve (p:xs) = p : sieve [y | y <- xs, y `mod` p /= 0] > sieve' (p:xs) = p : sieve [y | y <- xs, y `mod` p > 0] > > primes2 = sieve [2..] > primes3 = 2 : sieve [3,5..] > > primes2' = sieve' [2..] > primes3' = 2 : sieve' [3,5..] New description: Hello, using latest GHC 6.6.1 binary package for windows, I've received strange information about execution time for the module below. My machine: OS WinXP Pro SP2, Intel Core 2, 2GB RAM. How to reproduce error: {{{ :set +s :set -02 :cd :l Primes }}} Then running {{{ take 10000 primes1 take 10000 primes2 take 10000 primes3 take 10000 primes1' take 10000 primes2' take 10000 primes3' }}} Results seem to be correct, but the execution time reported no. First column is the GHCi report, the second column is th stop-watch data (just to correlate). No other task, except core windows, was running at the moment. {{{ GHCi Stop-watch 236.03 672.2 63.52 63.9 63.01 64.0 1098.75 671.0 -365.07 65.2 // it's not a typo, really minus three hundred and sixty five 63.59 63.6 }}} Best regards, Dusan --------- {{{ module Primes ( primes1 ,primes2 ,primes3 ,primes2' ,primes3' ) where candidates = map (\x -> (True,x)) [2..] candidates' = [2..] skipmap f toSkip list = domap toSkip list where domap n (x:xs) | n > 1 = x : domap (n-1) xs | True = f x : domap toSkip xs domap _ [] = [] primes1 = sieve candidates where sieve (pp@(isp,p):xs) | isp = p : (sieve $ skipmap (\(_,v) -> (False,v)) p xs) | True = sieve xs primes1' = sieve candidates' where sieve (p:xs) | p > 0 = p : (sieve $ skipmap (\n -> if n>0 then (-n) else n) p xs) | True = sieve xs sieve (p:xs) = p : sieve [y | y <- xs, y `mod` p /= 0] sieve' (p:xs) = p : sieve [y | y <- xs, y `mod` p > 0] primes2 = sieve [2..] primes3 = 2 : sieve [3,5..] primes2' = sieve' [2..] primes3' = 2 : sieve' [3,5..] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 12:13:36 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 12:11:19 2007 Subject: [GHC] #1641: Binders generated by instance deriving are affected by -auto-all In-Reply-To: <045.bc1ef364192e47328bae6a907ad26026@localhost> References: <045.bc1ef364192e47328bae6a907ad26026@localhost> Message-ID: <054.c3af5bfff11c11efdadedbc40ad12c78@localhost> #1641: Binders generated by instance deriving are affected by -auto-all ----------------------+----------------------------------------------------- Reporter: sorear | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8 branch Comment: Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 12:15:56 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 12:13:53 2007 Subject: [GHC] #1643: Unnecessary dictionaries In-Reply-To: <044.dfd526e50359185d2424b94d8c791a9c@localhost> References: <044.dfd526e50359185d2424b94d8c791a9c@localhost> Message-ID: <053.4bc5d6de61d5d47223e307d187f18909@localhost> #1643: Unnecessary dictionaries ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8 branch Comment: Depending on how invasive the fix is, this might not be suitable for the 6.8 branch, but I'll put it there for now anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 12:18:33 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 12:16:22 2007 Subject: [GHC] #1645: {-# SPECIALIZE #-} doesn't In-Reply-To: <044.a66239f3cca2f19dfae526bd6257e8cd@localhost> References: <044.a66239f3cca2f19dfae526bd6257e8cd@localhost> Message-ID: <053.352a41684798cf535ceb315d46e35072@localhost> #1645: {-# SPECIALIZE #-} doesn't ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch Comment: Thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 12:22:59 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 12:20:40 2007 Subject: [GHC] #1646: : panic! (the 'impossible' happened) In-Reply-To: <044.1e8b19fa7dab55635d07e0830763b70f@localhost> References: <044.1e8b19fa7dab55635d07e0830763b70f@localhost> Message-ID: <053.1e912dd0a46806b1b1ee48599d70563a@localhost> #1646: : panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8.2 Comment: This is waiting for someone to try to reproduce it. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ASN1-0.0.1 has dependencies HUnit, NewBinary, QuickCheck, base, mtl. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 12:33:01 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 12:30:19 2007 Subject: [GHC] #1647: Using -fdicts-strict flag causes Core Lint error In-Reply-To: <067.8af6cf06fabf5acdf49f68ce59933274@localhost> References: <067.8af6cf06fabf5acdf49f68ce59933274@localhost> Message-ID: <076.14fa7a8b224db78de1a90c6fe3cc069a@localhost> #1647: Using -fdicts-strict flag causes Core Lint error ------------------------------------------+--------------------------------- Reporter: chevalier@alum.wellesley.edu | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.7 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: => 6.10 branch Comment: Thanks for the report. I'll leave the decision of whether it should be removed or fixed to someone else... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 12:52:27 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 12:49:35 2007 Subject: [GHC] #1655: System.Posix.User.getGroupEntryForName incorrect error for non-existent group In-Reply-To: <044.3bd86eb8bb738687ac431ae1f2ae848e@localhost> References: <044.3bd86eb8bb738687ac431ae1f2ae848e@localhost> Message-ID: <053.c862dfbcf491f9aea0870857be49dece@localhost> #1655: System.Posix.User.getGroupEntryForName incorrect error for non-existent group ----------------------------+----------------------------------------------- Reporter: Eelis | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: libraries/unix | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo * milestone: => 6.8.2 Comment: The problem is when an error doesn't occur, but the name requested can't be found. The throwErrorIfNonZero_ doesn't happen, because 0 is returned, but the throwErrnoIfNull throws errno. We should throw something else in this situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 13:58:23 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 13:56:11 2007 Subject: [GHC] #1663: Critical sections not deallocated In-Reply-To: <044.e45b59b77fcdfa48fccebaa71d977584@localhost> References: <044.e45b59b77fcdfa48fccebaa71d977584@localhost> Message-ID: <053.4338feb25977ee796d4cc37da9555e0c@localhost> #1663: Critical sections not deallocated ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Runtime System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => 6.8.2 Comment: Thanks for the report; this looks like it ought to be easy to fix, so let's aim to do it for 6.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 14:03:59 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 14:01:45 2007 Subject: [GHC] #1684: impossible happened when compiling darcs with GADTs. In-Reply-To: <056.cae23306f919bc14d4404862d4e8da81@localhost> References: <056.cae23306f919bc14d4404862d4e8da81@localhost> Message-ID: <065.85b167ab12729e3c75be2952ab4a0397@localhost> #1684: impossible happened when compiling darcs with GADTs. -------------------------------+-------------------------------------------- Reporter: droundy@darcs.net | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.8.2 Comment: Possibly related to #1646. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 14:04:13 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 14:01:55 2007 Subject: [GHC] #1646: : panic! (the 'impossible' happened) In-Reply-To: <044.1e8b19fa7dab55635d07e0830763b70f@localhost> References: <044.1e8b19fa7dab55635d07e0830763b70f@localhost> Message-ID: <053.dae749c68ff8dde05a999867c3e1d245@localhost> #1646: : panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ----------------------+----------------------------------------------------- Comment (by igloo): Possibly related to #1684. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 14:21:48 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 14:19:30 2007 Subject: [GHC] #1697: GHC 6.6.1 fails to build on Arch Linux, 64-bit In-Reply-To: <044.0fb4a909e896e195b081e7853879e66b@localhost> References: <044.0fb4a909e896e195b081e7853879e66b@localhost> Message-ID: <053.905f08f18fb99d39b51651be21f49bdc@localhost> #1697: GHC 6.6.1 fails to build on Arch Linux, 64-bit ------------------------------------------------------+--------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: build 64-bit multiple definition closure | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ------------------------------------------------------+--------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We don't have a way to contact the submitter, so I'm going to assume this is a duplicate of #1427 and thus fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 14:28:31 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 14:25:38 2007 Subject: [GHC] #1646: : panic! (the 'impossible' happened) In-Reply-To: <044.1e8b19fa7dab55635d07e0830763b70f@localhost> References: <044.1e8b19fa7dab55635d07e0830763b70f@localhost> Message-ID: <053.c18722d28f07376bcba5a1ca32076690@localhost> #1646: : panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ----------------------+----------------------------------------------------- Comment (by guest): Testing null e-mail address for Trac's guest account. Sorry for the noise. Paul Heinlein -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 14:29:41 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 14:26:48 2007 Subject: [GHC] #1646: : panic! (the 'impossible' happened) In-Reply-To: <044.1e8b19fa7dab55635d07e0830763b70f@localhost> References: <044.1e8b19fa7dab55635d07e0830763b70f@localhost> Message-ID: <053.62579a193d3fbd857432cdf23afc3545@localhost> #1646: : panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ----------------------+----------------------------------------------------- Comment (by guest): Another test. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Nov 5 14:43:37 2007 From: trac at galois.com (GHC) Date: Mon Nov 5 14:40:54 2007 Subject: [GHC] #1728: generic classes broken In-Reply-To: <059.1482de2bc4b5dd40a00134250d3e693d@localhost> References: <059.1482de2bc4b5dd40a00134250d3e693d@localhost> Message-ID: <068.1712e00186c8c7afb57d4dd38d16bd9b@localhost> #1728: generic classes broken ----------------------------------+----------------------------------------- Reporter: klee@cs.tu-berlin.de | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------+----------------------------------------- Old description: > I failed to get generic classes working with snapshot > ghc-6.8.0.20070920-i386-unknown-linux.tar.bz2. > > I tried the following module: > > --- > module Gen where > > import Data.Generics > > class Equal a where > equal :: a -> a -> Bool > equal {| Unit |} Unit Unit = True > equal {| u :+: v |} (Inl x) (Inl y) = equal x y > equal {| u :+: v |} (Inr x) (Inr y) = equal x y > equal {| u :+: v |} _ _ = False > equal {| u :*: v |} (x1 :*: x2) (y1 :*: y2) = equal x1 y1 && equal > x2 y2 > > instance Equal Bool > --- > > and got > > --- > klee@romulus:~/tmp> ghci -fglasgow-exts -XGenerics > GHCi, version 6.8.0.20070920: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Prelude> :l Gen.hs > [1 of 1] Compiling Gen ( Gen.hs, interpreted ) > > Gen.hs:13:0: > Can't find interface-file declaration for variable > GHC.Base.$gfromBool > Probable cause: bug in .hi-boot file, or inconsistent .hi file > Use -ddump-if-trace to get an idea of which file caused the error > In the first argument of `a', namely `(GHC.Base.$gfromBool b)' > In the first argument of `(\ a -> a)', namely > `(a (GHC.Base.$gfromBool b))' > In the expression: (\ a -> a) (a (GHC.Base.$gfromBool b)) > Failed, modules loaded: none. > --- New description: I failed to get generic classes working with snapshot ghc-6.8.0.20070920-i386-unknown-linux.tar.bz2. I tried the following module: --- {{{ module Gen where import Data.Generics class Equal a where equal :: a -> a -> Bool equal {| Unit |} Unit Unit = True equal {| u :+: v |} (Inl x) (Inl y) = equal x y equal {| u :+: v |} (Inr x) (Inr y) = equal x y equal {| u :+: v |} _ _ = False equal {| u :*: v |} (x1 :*: x2) (y1 :*: y2) = equal x1 y1 && equal x2 y2 instance Equal Bool }}} --- and got --- {{{ klee@romulus:~/tmp> ghci -fglasgow-exts -XGenerics GHCi, version 6.8.0.20070920: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :l Gen.hs [1 of 1] Compiling Gen ( Gen.hs, interpreted ) Gen.hs:13:0: Can't find interface-file decl