From trac at galois.com Mon Jan 1 10:54:46 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1077: documentation error and omission Message-ID: <071.3d99ff25768abf8c5be29dd11eefbea4@localhost> #1077: documentation error and omission ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 6.6 Severity: trivial | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Multiple ------------------------------+--------------------------------------------- 1. broken link in the building guide in: http://www.haskell.org/ghc/docs/latest/html/building/sec-build- checks.html points to: http://www.haskell.org/ghc/docs/latest/set/bug-reporting.html This is what I see: {{{ Not Found The requested URL /ghc/docs/latest/set/bug-reporting.html was not found on this server. Apache/2.0.46 (Red Hat) Server at www.haskell.org Port 80 }}} 2. automake not mentioned in "building and developing GHC". I think it deserves a mention next to autoconf, here: http://www.haskell.org/ghc/docs/latest/html/building/sec-pre-supposed.html I found that running autoreconf fails without it. Here's the output I got before installing automake: {{{ micky@cellar:/build/ghc$ autoreconf Can't exec "aclocal": No such file or directory at /usr/bin/autoreconf line 176. Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 176. Can't exec "automake": No such file or directory at /usr/bin/autoreconf line 177. Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 177. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 1 11:42:56 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1078: Using X11 through ffi on windows does not work Message-ID: <071.c6188bd489b4229961960123f24870a0@localhost> #1078: Using X11 through ffi on windows does not work -------------------------+-------------------------------------------------- Reporter: Azmo | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 6.6 Severity: blocker | Keywords: X11 ffi windows Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Windows -------------------------+-------------------------------------------------- When using the X11 Xlib through the ffi instead of using the existing binding on linux it works fine. On windows it does not. I have written similar programs, with the same result. I have had no problems like this before. I link with the "libX11-6" library, which comes with X11 for cygwin. the "libX11-6" is the only choise. Can not find anything else to use. This particular lib works fine if writing an equivalent program in C and explicitly linking with it using GCC. Strangely, if the argument to XOpenDisplay is wrong, the function actually returns, and with a 0, which makes sense since it failed. Same result on linux, but this is the only case where it actually works on windows. If the argument is 0, then the function seems to correctly read the DISPLAY environment variable, and then if that is invalid the function returns 0, otherwise the program crashes/hangs. ---- A program that uses ffi to access the X11 Xlib. Works fine on linux, but on win2k + cygwin: * using: > ghc --make no_c_test.hs -ffi -L"Y:\cygwin\usr\X11R6\lib" -llibX11-6 -fglasgow-exts when run, it crashes with: "The instruction at "0x00000000" referenced memory at "0x00000000". The memory could not be "read". * using: > (same as above, but adding any of: -fvia-C -O -O2 ) when run, it seems to go into an infinite loop after printing "before". {{{ import Foreign.C.String (withCString, CString) import Foreign.Ptr (Ptr) import Foreign.C.Types (CInt) foreign import ccall safe "XOpenDisplay" openDisplay :: CString -> IO (Ptr DisplayStruct) foreign import ccall safe "XCloseDisplay" closeDisplay :: Ptr DisplayStruct -> IO CInt data DisplayStruct main :: IO () main = do withCString "localhost:0.0" $ \cstr -> do print "before" p <- openDisplay cstr print "after" closeDisplay p print "done" }}} ---- Another example, but instead partially using C code. Works fine on linux, but not on windows. If writing the program entirely in C, it works. But if replacing main in the C program with a call from haskell code through ffi, then it does not work anymore. c-file: {{{ #include #include void ProgFunc(){ printf("ProgFunc starting\n"); Display *dpy = XOpenDisplay(":0.0"); printf("dpy: 0x%x\n", (unsigned int)dpy); } /* it works if using this main. (thus only C code compiled with GCC) main() { ProgFunc(); return 0; } */ }}} haskell-file: {{{ import System.IO foreign import ccall unsafe "ProgFunc" progFunc :: IO () main :: IO () main = do print "before c" progFunc print "after c" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 2 04:23:18 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #743: -M limit exceeded by a factor of 2 In-Reply-To: <071.b8d20b534d8e7dc8513b1471729a7070@localhost> References: <071.b8d20b534d8e7dc8513b1471729a7070@localhost> Message-ID: <080.bc0166de9ae5163e0d5635df6df76003@localhost> #743: -M limit exceeded by a factor of 2 ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by ketil@ii.uib.no): * resolution: => fixed * status: new => closed Comment: I've finally gotten around to build ghc 6.6 with the recent patch for this problem, and it appears the problem has been fixed. My program (rbr) now stick within the specified heap, until it OOMs (as expected). Thanks! -k -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 2 08:49:04 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #744: ghc-pkg lies about location of haddock-interfaces and haddock-html In-Reply-To: <071.4631d79eca057b4e5feef0df2637ad9b@localhost> References: <071.4631d79eca057b4e5feef0df2637ad9b@localhost> Message-ID: <080.216b2d2ab07da0313b076a729f4c8cbc@localhost> #744: ghc-pkg lies about location of haddock-interfaces and haddock-html ---------------------------+------------------------------------------------ Reporter: avatar@hot.ee | Owner: panne Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Documentation | Version: 6.4.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: N/A | Architecture: Multiple Os: Linux | ---------------------------+------------------------------------------------ Changes (by panne): * resolution: => fixed * status: assigned => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 2 10:05:12 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1079: refinement for GHC's support of UTF-8 encoding Message-ID: <071.4e4d04a6baba59972cfc85844cdbc33b@localhost> #1079: refinement for GHC's support of UTF-8 encoding --------------------------------+------------------------------------------- Reporter: mukai@jmuk.org | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: major | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- From 6.6, GHC supports UTF-8 encoding in the source programs. GHC can read UTF-8 files and convert them into Unicode characters. However, there are no support to read/print them. For example, we can compile the following program, {{{ main = putStrLn "?" }}} but we only get `B', the least 8bit of the character `?' (U+3042). Because of this incompleteness, we cannot print any non-ascii characters without converting for the case of writing Haskell codes with UTF-8. Although it is easy to write converting functions for this purpose, such converting should be supported by the compiler. IMHO, desired approach is similar to Hugs. In Hugs, when printing non- ascii characters, it first converts the characters to UTF-8 octets and then prints them. However, with binary-mode Handle, it just print characters without convert. This behavior will be acceptable for many haskell programmers. -- Ticket URL: GHC The Glasgow Haskell Compiler From bill.mill+haskell at gmail.com Tue Jan 2 10:15:04 2007 From: bill.mill+haskell at gmail.com (Bill Mill) Date: Thu Jul 19 09:48:02 2007 Subject: Visual Haskell's Hello, World Message-ID: It seems trivial, but I think the contents of main.hs in the Visual Haskell default project should include a getChar: module Main where main = do putStrLn "Hello, world!" getChar The first thing a user is going to do on installation is hit the "build and execute" button, and the default project displays a window which then closes before the user can see if anything's happened. -Bill Mill bill.mill at gmail.com From trac at galois.com Tue Jan 2 11:21:47 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1068: Trunk broken on deriving Typeable In-Reply-To: <071.1891f46d3553db3bb5aede95bdbec43a@localhost> References: <071.1891f46d3553db3bb5aede95bdbec43a@localhost> Message-ID: <080.d258f2b57af8d876ee2a646c71f0d20a@localhost> #1068: Trunk broken on deriving Typeable ---------------------------------+------------------------------------------ Reporter: audreyt@audreyt.org | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: drv013 | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Changes (by simonpj): * resolution: => fixed * testcase: => drv013 * status: new => closed Comment: Fixed, thank you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ndmitchell at gmail.com Tue Jan 2 14:40:50 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Jul 19 09:48:02 2007 Subject: Visual Haskell's Hello, World In-Reply-To: References: Message-ID: <404396ef0701021140i7c4110xe680f2523a73b819@mail.gmail.com> Hi Bill, > It seems trivial, but I think the contents of main.hs in the Visual Haskell > default project should include a getChar: Then people will wonder why their app has stopped, and get very confused. A much better solution would be for GHC in Visual Studio to pause at the end of a console application and give the user a "program terminated, press any key to finish" message. Ideally at the end of every program, not just for the sample one. Thanks Neil From trac at galois.com Tue Jan 2 15:38:53 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1025: -ddump-minimal-imports works wrongly In-Reply-To: <071.7c52338398d65e6db9feefd21314034e@localhost> References: <071.7c52338398d65e6db9feefd21314034e@localhost> Message-ID: <080.7d5d10645d7b90a2ff2be3a35a1b514c@localhost> #1025: -ddump-minimal-imports works wrongly ---------------------------+------------------------------------------------ Reporter: maeder@tzi.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Comment (by simonpj): Can you give us a repo case please? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 04:11:30 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <071.6cf7cc82140ee52541ddda45994b1f58@localhost> References: <071.6cf7cc82140ee52541ddda45994b1f58@localhost> Message-ID: <080.0aaa660b1ef57bc2d4b419260af149d9@localhost> #1074: -fwarn-unused-imports complains about wrong import ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * milestone: => _|_ * severity: normal => minor Comment: Good bug report. Alas, it's not easy to fix. Here's why. To report unused imports, GHC gathers up all the entities that are referred to (Names, in GHC's terminology). But that doesn't say *how* they are referred to, so it does not distinguish 'ap' from 'Control.Monad.ap'. In this case, the import of Control.Monad is indeed required, because the reference was a qualified one. So really this exposes an architectural shortcoming in the way GHC reports unused imports. Of course it's fixable, but it'd be non-trivial, so don't hold your breath. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 04:44:45 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1054: Not in scope test failures In-Reply-To: <071.31b19e336a8c05258307c0d8227f09b0@localhost> References: <071.31b19e336a8c05258307c0d8227f09b0@localhost> Message-ID: <080.2ce53364dc7897998b8ef3a9f7b0ef1e@localhost> #1054: Not in scope test failures ----------------------------------------------------------------------------------------------------------+ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: TH_genEx, TH_repGuard, TH_repGuardOutput, TH_spliceInst, arrowcase1, cc012, mod49, tcfail077 | Architecture: Unknown Os: Unknown | ----------------------------------------------------------------------------------------------------------+ Comment (by simonpj): I have fixed c012, mod49, tcfail077. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From eivuokko at gmail.com Wed Jan 3 05:23:33 2007 From: eivuokko at gmail.com (Esa Ilari Vuokko) Date: Thu Jul 19 09:48:02 2007 Subject: Visual Haskell's Hello, World In-Reply-To: References: Message-ID: Hi Bill, On 1/2/07, Bill Mill wrote: > It seems trivial, but I think the contents of main.hs in the Visual Haskell > default project should include a getChar: > > module Main where > > main = do > putStrLn "Hello, world!" > getChar > > The first thing a user is going to do on installation is hit the "build and > execute" button, and the default project displays a window which then closes > before the user can see if anything's happened. I don't have Visual Studio or Visual Haskell installed right now, but I recall that for most languages there is two ways to run a program: debug and non-debug. For haskell these would be the same at the moment. But there's also another diffrence: non-debug leaves console window open after running the program. I think typical key bindings are F5 for debug run, and Ctrl+F5 for non-debug. Best regards, Esa Ilari Vuokko From trac at galois.com Wed Jan 3 05:25:36 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1053: Message order random due to sorting by uniques In-Reply-To: <071.b4135c6331b051bc89f9a580fdf3b3b2@localhost> References: <071.b4135c6331b051bc89f9a580fdf3b3b2@localhost> Message-ID: <080.219ee90dd5e11398b918dc52295f9ded@localhost> #1053: Message order random due to sorting by uniques -------------------------------------+-------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: Simple2 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * resolution: => fixed * status: new => closed Comment: Fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 07:09:01 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1080: Arrows desguaring does not take account of bindings in patterns Message-ID: <071.d5ca1c35d76845f0df8e39088a1eb459@localhost> #1080: Arrows desguaring does not take account of bindings in patterns -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: Ross Paterson Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- The test arrows/should_compile/arrowcase1 is failing Lint. The bug is in the desugarer. Here?s a smaller test case: {{{ h :: ArrowChoice a => Int -> a (Int,Int) Int h x = proc (y,z) -> case compare x y of GT -> returnA -< z+x }}} The type checker turns the case into {{{ case compare x y of GT { p77 = plusInt } -> returnA -< p77 z x }}} Here p77 is a local binding for the (+) operation. In general, patterns can contain bindings (used to discharge constraints that are bound by the pattern). In this case the binding isn?t strictly necessary, but in general it is ? consider existentials. It?s equivalent to adding a ?let? around the RHS, but since the patters are perhaps nested, and one pattern might use a constraint that is bound by another, the pattern is the right place to attach the binding. This has come up because GHC is binding things a little earlier than before, but an existential would have exposed it before. The trouble is that the suspicious-looking replaceLeaves code in DsArrows (line 528 or so) doesn?t know about these bindings. I don?t understand DsArrows at all. Indeed the whole Arrows code feels smelly to me. Maybe we tried to share too much code? I'm hoping Ross will look at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 07:10:00 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1080: Arrows desguaring does not take account of bindings in patterns In-Reply-To: <071.d5ca1c35d76845f0df8e39088a1eb459@localhost> References: <071.d5ca1c35d76845f0df8e39088a1eb459@localhost> Message-ID: <080.75f34e923ebd92ddc8ff9a309c04bd0a@localhost> #1080: Arrows desguaring does not take account of bindings in patterns ------------------------+--------------------------------------------------- Reporter: simonpj | Owner: Ross Paterson Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: arrowcase1 | Architecture: Unknown Os: Unknown | ------------------------+--------------------------------------------------- Changes (by simonpj): * testcase: => arrowcase1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 07:16:38 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1054: Not in scope test failures In-Reply-To: <071.31b19e336a8c05258307c0d8227f09b0@localhost> References: <071.31b19e336a8c05258307c0d8227f09b0@localhost> Message-ID: <080.e8be8f548851d62f7f3faf066e8ff666@localhost> #1054: Not in scope test failures ----------------------------------------------------------------------------------------------------------+ Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: TH_genEx, TH_repGuard, TH_repGuardOutput, TH_spliceInst, arrowcase1, cc012, mod49, tcfail077 | Architecture: Unknown Os: Unknown | ----------------------------------------------------------------------------------------------------------+ Changes (by simonpj): * resolution: => fixed * status: new => closed Comment: I've fixed the rest, except for arrowcase1, for which I've created a new bug report (#1080) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 08:06:17 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1025: -ddump-minimal-imports works wrongly In-Reply-To: <071.7c52338398d65e6db9feefd21314034e@localhost> References: <071.7c52338398d65e6db9feefd21314034e@localhost> Message-ID: <080.b7a0b421b479bd56d818f1b39856826d@localhost> #1025: -ddump-minimal-imports works wrongly ---------------------------+------------------------------------------------ Reporter: maeder@tzi.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Comment (by maeder@tzi.de): get and install shellac {{{http://www.eecs.tufts.edu/~rdocki01/projects/shellac-0.5-source.tar.gz}}}. Compile the attached module: {{{ maeder@turing:~/haskell/examples> ghc --make -no-recomp -ddump-minimal- imports B.hs [1 of 1] Compiling B ( B.hs, B.o ) B.hs:1:0: Failed to load interface for `System.Console.Shell.Commands': it is hidden (in package Shellac-0.5) }}} The cause is the use of the data constructor {{{File}}}. Without {{{-fforce-recomp}}} (or {{{-no-recomp}}}) the module is not recompiled if it was successfully compiled before without {{{-ddump- minimal-imports}}} {{{B.hs}}} {{{ module B where import System.Console.Shell a :: File a = File "bla" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 09:00:03 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1031: ghc 6.6 impossible happened In-Reply-To: <071.dea00bde82d97fe650b10ea2cf2f7d1f@localhost> References: <071.dea00bde82d97fe650b10ea2cf2f7d1f@localhost> Message-ID: <080.95bc0e5a4f1776c81728991aa4345913@localhost> #1031: ghc 6.6 impossible happened ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * cc: => ahey@iee.org Comment: Adrian Hey writes: I seem to have hit this problem. (I think, at least I'm getting a very similar incomprehensible error message :-) I tried using bang patterns instead of `seq` like this: {{{ let a0_ = f a0 a in a0_ `seq` (# l,hl,a0_,r,hr #) }}} becomes .. {{{ let !a0_ = f a0 a in (# l,hl,a0_,r,hr #) }}} but I still get the same error. The attachment should show the problem (in Windows using Build.BAT). The problem occurs in the HSet module (and maybe others). BTW, regarding the urgency of this, a solution is not particularly urgent for me as it's part of a generalised tries lib which probably needs at least another months work or so before it's ready for prime time, and seeing as at the end of the week I'm going away until end of Feb it probably won't be a real show stopper until about April (and even then it'll only stop a lib that noone is currently dependent on, not even me :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 09:52:57 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1072: Core Lint Errors: in result of Desugar In-Reply-To: <071.69dfef419693354b28e85e887f53cb3e@localhost> References: <071.69dfef419693354b28e85e887f53cb3e@localhost> Message-ID: <080.2f78a6580eb0196e5415c9776b28df13@localhost> #1072: Core Lint Errors: in result of Desugar ----------------------+----------------------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonpj): * severity: normal => minor * version: 6.6 => 6.7 * owner: => simonpj Comment: Excellent example. This is the same problem as the failure in maessen_hashtab. It's also closely related to #930 Here's what is happening (mainly notes to me). The newtype for WrapIOMonad is getting "trimmed" by `TidyPgm`; but occurrences of WrapIOMonad in the types of Ids are *not* trimmed. Then when we compare types, the comparing function (Type.coreEqType) looks through the newtype on one side but not the other. I've made a temporary solution for GHC 6.6, by making coreEqType first expand synonyms and notes, then look for equal `TyCons`, then expand newtypes. But it's a hack, and can be fooled (by nested newtypes, for example). The hack is enough to make this program work, however. The HEAD has a different solution: do not make newtypes transparent at all. I think that works ok, but I'm still uneasy about the fact that a given `TyCon` can appear in two different forms in the same compilation. So I'm going to leave this open, but at low priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 09:53:20 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #930: ghc-6.6: panic! (the 'impossible' happened) mkWWcpr: not a product GHC-Brian-6.5.1:IdInfo.IdInfo{tc rfD} In-Reply-To: <071.f27bedd3994f05043b5a02816323ccde@localhost> References: <071.f27bedd3994f05043b5a02816323ccde@localhost> Message-ID: <080.d50bc1d07e4fdc35c9af618cb025a820@localhost> #930: ghc-6.6: panic! (the 'impossible' happened) mkWWcpr: not a product GHC- Brian-6.5.1:IdInfo.IdInfo{tc rfD} ------------------------+--------------------------------------------------- Reporter: briansmith | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------+--------------------------------------------------- Changes (by simonpj): * testcase: => Comment: See also #1072 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 10:37:46 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #995: Needless call to fromInteger for literals In-Reply-To: <071.ecd463caac15904824f69b2a1655a23f@localhost> References: <071.ecd463caac15904824f69b2a1655a23f@localhost> Message-ID: <080.0753c2d3c0d8607f6dfd09b4e02cb85b@localhost> #995: Needless call to fromInteger for literals ----------------------+----------------------------------------------------- Reporter: wolfgang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by simonpj): * resolution: => fixed * status: new => closed Comment: Good bug. Turns out that there was a mistake in the optimiser, where it dealt with cast expressions. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 11:27:57 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1081: HGL indefinite pause with "thread blocked indefinitely" message Message-ID: <071.17ce0eb3f351bd914dca627634964858@localhost> #1081: HGL indefinite pause with "thread blocked indefinitely" message -------------------------+-------------------------------------------------- Reporter: calvins | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Keywords: hgl thread deadlock Difficulty: Unknown | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- As discussed on haskell-cafe , the program below sometimes pauses indefinitely when run, and seems to be a result of some kind of deadlock issue. Behavior has been observed on the following platforms/versions: 1) GNU/Linux (2.6.18 kernel, gcc-4.1.1), ghc-6.6, hgl-3.1, xorg-x11-7.1 (on both single core and multi-core x32). 2) Mac OS X, ghc-6.4.2, x11-1.1 and hgl-3.1. {{{ module Main where import Graphics.SOE main = runGraphics ( do w <- openWindow "Snowflake Fractal" (600, 600) fillStar w 300 125 256 (cycle $ enumFrom Blue) spaceClose w ) spaceClose w = do k <- getKey w if k == ' ' then closeWindow w else spaceClose w minSize = 2 :: Int fillStar :: Window -> Int -> Int -> Int -> [Color] -> IO () fillStar w x y h clrs | h <= minSize = return () fillStar w x y h clrs = do drawInWindow w (withColor (head clrs) (polygon [t1p1,t1p2,t1p3,t1p1])) drawInWindow w (withColor (head clrs) (polygon [t2p1,t2p2,t2p3,t2p1])) sequence_ $ map recur [t1p1,t1p2,t1p3,t2p1,t2p2,t2p3] where tanPiOverSix = tan(pi/6) :: Float halfSide = truncate $ tanPiOverSix * fromIntegral h hFrag = truncate $ tanPiOverSix * tanPiOverSix * fromIntegral h (t1p1,t1p2,t1p3) = ((x, y), (x-halfSide, y+h),(x+halfSide, y+h)) (t2p1,t2p2,t2p3) = ((x-halfSide, y+hFrag),(x, y+h+hFrag),(x+halfSide, y+hFrag)) reVert y = y - ((h - hFrag) `div` 3) recur pnt = fillStar w (fst pnt) (reVert (snd pnt)) (h`div`3) (tail clrs) }}} The problematic behavior, observed with ghci and also a ghc-compiled binary -- but not with Hugs (March 2005) -- is that sometimes the rendering pauses at various places and does not continue rendering until some kind of ui event occurs. Moving the mouse or typing any key but space (which exits) causes the rendering to continue. When the pause occurs, the following message is printed to the console: "thread blocked indefinitely". Please let me know if you need any further information. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jan 3 11:43:08 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1081: HGL indefinite pause with "thread blocked indefinitely" message In-Reply-To: <071.17ce0eb3f351bd914dca627634964858@localhost> References: <071.17ce0eb3f351bd914dca627634964858@localhost> Message-ID: <080.190b701d5df628f6d69b74a370787c56@localhost> #1081: HGL indefinite pause with "thread blocked indefinitely" message ---------------------------------+------------------------------------------ Reporter: calvins | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: hgl thread deadlock | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Comment (by calvins): I meant "single core and multi-core x86 (32-bit)" instead of "single core and multi-core x32" above. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 00:28:23 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1082: Documentation missing from MacOS PPC binary Message-ID: <071.91323d2019255a91c4b19cb661ca43de@localhost> #1082: Documentation missing from MacOS PPC binary ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: powerpc | Os: MacOS X ------------------------------+--------------------------------------------- The installation from the MacOS PPC binary distribution works fine but ends with {{{ ======================================================================= Installation of ghc-6.6 was successful. To use, add /usr/local/bin to your PATH. For documentation, see /usr/local/share/ghc-6.6/html/index.html ======================================================================= }}} However, there is no documentation there, nor does {{{make html}}} work. And unfortunately for us who often work offline, there doesn't seem to be a separate download for the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 04:44:19 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1083: ghci says a module wasn't loaded under debugging mode when in fact it was Message-ID: <071.d0092f4b73309f7aab9a75b5453cf508@localhost> #1083: ghci says a module wasn't loaded under debugging mode when in fact it was ----------------------------+----------------------------------------------- Reporter: mnislaih | Owner: mnislaih Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: GHCi | Version: 6.6 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Unknown ----------------------------+----------------------------------------------- When loading an empty module like the following: {{{ main = putStr "hola" }}} ghci will refuse to set a breakpoint saying that the module is not loaded under debugging mode {{{ pepe:~/code/snippets$ ghci -fdebugging main ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.7, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. [1 of 1] Compiling Main ( main.hs, interpreted ) Ok, modules loaded: Main. *Main> :break add Main 1 *** Exception: Module main:Main was not loaded under debugging mode. Enable debugging mode and reload it *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 04:51:08 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1084: Improve coalescing of dynamic breakpoints in the ghci debugger Message-ID: <071.b1d7f9cd79443be29419b37b502ac59a@localhost> #1084: Improve coalescing of dynamic breakpoints in the ghci debugger ----------------------------+----------------------------------------------- Reporter: mnislaih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.8 Component: GHCi | Version: 6.6 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Unknown ----------------------------+----------------------------------------------- (or disable it altogether) Right now coalescing of breakpoints works at instrumentation time by: 1. Not inserting a breakpoint if there are no local bindings in the site 1. Removing adjacent breakpoints, i.e. removing one of them (not implemented yet) 1. adhoc case: if we are about to insert a breakpoint but the subexpresion is a HsLet, then don't. Proposal is to disable cases 1 and 3 and implement case 2 using rewriting rules. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 05:05:44 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1084: Improve coalescing of dynamic breakpoints in the ghci debugger In-Reply-To: <071.b1d7f9cd79443be29419b37b502ac59a@localhost> References: <071.b1d7f9cd79443be29419b37b502ac59a@localhost> Message-ID: <080.e458e78529ba31fd3a3f07f2bd47d51f@localhost> #1084: Improve coalescing of dynamic breakpoints in the ghci debugger ----------------------+----------------------------------------------------- Reporter: mnislaih | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.8 Component: GHCi | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by mnislaih): * status: new => assigned * owner: => mnislaih * type: task => bug Comment: The problem with case 1 is that it can create confusion for the user. It can be too aggressive for instance, preventing the setting of a breakpoint in main if there are no local bindings: {{{ main = putStr "hola" }}} Case 3 is there because the breakpoint that gets inserted in the body of the let expression renders the coalesced one innecesary. However, this interacts badly with desugaring of list comprehensions, and is a bit too ad-hoc. This makes impossible to set a breakpoint in gen (from queens.hs in the nofib suite): {{{ gen n = [ (q:b) | b <- gen (n-1), q <- [1..nq], safe q 1 b] }}} Another option may be to extend the desugaring of list comprehensions to have it insert a breakpoint in the body if in debugging mode (but no internal/system bindings should show up in the breakpoint). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 05:11:06 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:02 2007 Subject: [GHC] #1083: ghci says a module wasn't loaded under debugging mode when in fact it was In-Reply-To: <071.d0092f4b73309f7aab9a75b5453cf508@localhost> References: <071.d0092f4b73309f7aab9a75b5453cf508@localhost> Message-ID: <080.454baaf4082f744edc0ae534981f1ce8@localhost> #1083: ghci says a module wasn't loaded under debugging mode when in fact it was ----------------------+----------------------------------------------------- Reporter: mnislaih | Owner: mnislaih Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: GHCi | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by mnislaih): Observe that there are no breakpoints because of coalescing, as explained in ticket #1084. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 05:25:31 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS Message-ID: <071.f2e5c5f7708f6538f8516c3f8ea20dcd@localhost> #1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS ---------------------------------+------------------------------------------ Reporter: mnislaih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.8 Component: Runtime System | Version: 6.6 Severity: normal | Keywords: Difficulty: Moderate (1 day) | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------+------------------------------------------ Currently, from the closure we get its info table address, and since those are static for Constr closures, we use a hashtable (defined in Linker.c) to relate symbol names obtained when linking and the addresses. The proposal is to extend the info table with a field for the symbol name, making this process much more straightforward. The trade-off is that this will augment the size of binaries a bit, so we could make this 'labelling' of info tables optional via a flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 05:26:14 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS In-Reply-To: <071.f2e5c5f7708f6538f8516c3f8ea20dcd@localhost> References: <071.f2e5c5f7708f6538f8516c3f8ea20dcd@localhost> Message-ID: <080.51914573b28c986ce652606df8752b41@localhost> #1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS ----------------------------+----------------------------------------------- Reporter: mnislaih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.8 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by mnislaih): Does this explanation make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 05:28:31 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS In-Reply-To: <071.f2e5c5f7708f6538f8516c3f8ea20dcd@localhost> References: <071.f2e5c5f7708f6538f8516c3f8ea20dcd@localhost> Message-ID: <080.cba409e367b36fe66956d23820e51d1f@localhost> #1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS ----------------------------+----------------------------------------------- Reporter: mnislaih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.8 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by mnislaih): I wonder if then there would be special versions of the libs compiled under this 'debugging' flag, as currently happens for the profiling libs. Would the increment in size be big enough to justify this inconvenience? Most probably not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 10:16:47 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1086: unix package cannot be compiled with -fasm, due to lstat() Message-ID: <071.1540abc18f6439a2712f95713d072020@localhost> #1086: unix package cannot be compiled with -fasm, due to lstat() -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: libraries/unix | Version: 6.6 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- On some systems (eg. Linux with glibc) lstat is a macro, so calling it directly via the FFI doesn't work when using the NCG. We should create a stub wrapper for lstat(). See [http://www.haskell.org/pipermail/glasgow-haskell-bugs/2006- December/007900.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 10:37:48 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1042: Floating point exception In-Reply-To: <071.6129ca626045912d2903729d98277b21@localhost> References: <071.6129ca626045912d2903729d98277b21@localhost> Message-ID: <080.cc586df4bcf61c2f29ee6cf88ff16a47@localhost> #1042: Floating point exception ----------------------+----------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): None of the arithmetic operations on `Int` check for overflow, they all wrap around modulo the size of the `Int` type, so it seems to me we should be consistent and yield 0 for this case. Haskell 98 says that overflow is implementation-defined, so it's up to us what we do. Anyway, the place is `GHC.Real`, in the the `Integral` instance for `Int`. Also the various other integral types in `GHC.Int` need the same treatment. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 11:36:16 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1067: assertion failure in Schedule.c In-Reply-To: <071.3150dff0d9afe5da9548c87b3e92ff0e@localhost> References: <071.3150dff0d9afe5da9548c87b3e92ff0e@localhost> Message-ID: <080.6f1701baa62b18d763eb6879ba5cafc6@localhost> #1067: assertion failure in Schedule.c ----------------------------+----------------------------------------------- Reporter: ms43 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'll take it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jan 4 11:59:02 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1047: Increase gurantees of semantics of block/unblock/throwTo In-Reply-To: <071.42c3860600bc70dcf3ce7cefa342468b@localhost> References: <071.42c3860600bc70dcf3ce7cefa342468b@localhost> Message-ID: <080.db071439b8013515ca08ddfbf73e977d@localhost> #1047: Increase gurantees of semantics of block/unblock/throwTo ----------------------------+----------------------------------------------- Reporter: ChrisKuklewicz | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: concurrency | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: As far as I can tell, the semantics in the paper don't have the guarantee that you're looking for either: there's no requirement that the Receive rule in the semantics '''must''' fire if an exception is waiting. Also, the paper is based on an asynchronous version of `throwTo`, so things are quite different in various ways. I think you're reading a different version of the paper though, in the version on my web page here [http://www.haskell.org/~simonmar/papers/async.pdf], section 7.2 is called "Symmetric process abstractions" and doens't seem to talk about this. Still, I'm going to make the improvement suggested, since it's a good idea and easy to do (I just noticed how easy). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 5 07:36:15 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1067: assertion failure in Schedule.c In-Reply-To: <071.3150dff0d9afe5da9548c87b3e92ff0e@localhost> References: <071.3150dff0d9afe5da9548c87b3e92ff0e@localhost> Message-ID: <080.6bcc74033c831b246fe2de966004a988@localhost> #1067: assertion failure in Schedule.c ----------------------------+----------------------------------------------- Reporter: ms43 | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * resolution: => fixed * status: new => closed Comment: Fixed, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 5 08:59:28 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1047: Increase gurantees of semantics of block/unblock/throwTo In-Reply-To: <071.42c3860600bc70dcf3ce7cefa342468b@localhost> References: <071.42c3860600bc70dcf3ce7cefa342468b@localhost> Message-ID: <080.2705e2be4dea9dd881bdc0103285230d@localhost> #1047: Increase gurantees of semantics of block/unblock/throwTo ------------------------------+--------------------------------------------- Reporter: ChrisKuklewicz | Owner: simonmar Type: task | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.6 Severity: normal | Resolution: fixed Keywords: concurrency | Difficulty: Unknown Testcase: conc065, conc066 | Architecture: Multiple Os: Multiple | ------------------------------+--------------------------------------------- Changes (by simonmar): * resolution: => fixed * testcase: => conc065, conc066 * status: new => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 5 09:20:17 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1071: The Graphics.X11 library for windows using Cygwin/X In-Reply-To: <071.04997a0bb1dea0ee9ed1c32decbdebba@localhost> References: <071.04997a0bb1dea0ee9ed1c32decbdebba@localhost> Message-ID: <080.3b0d4cf808de7e3ababac36301cf7dd7@localhost> #1071: The Graphics.X11 library for windows using Cygwin/X -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: Keywords: X11 binding | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Windows | -------------------------------+-------------------------------------------- Changes (by simonmar): * difficulty: Moderate (1 day) => Unknown * milestone: 6.6.1 => Not GHC * severity: blocker => normal * priority: high => normal Comment: True - in theory there's no reason we can't supply the X11 package on Windows. However, there are serious practical difficulties. We don't have a set of X11 client libraries that we can use. There are libraries for Cygwin, but GHC is not compiled as a Cygwin application so we can't use those libraries. There's an X server that is non-cygwin, but no client libraries: [http://freedesktop.org/wiki/Xming] If you where we can get a set of X11 client libraries that we can build against, then please let us know. Presumably these would have to be shipped with the X11 package too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 5 09:27:49 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1075: ghci unhandled exception on startup (memory access violation) In-Reply-To: <071.ed018432859bfb95e8a7b91690d468b1@localhost> References: <071.ed018432859bfb95e8a7b91690d468b1@localhost> Message-ID: <080.7cf0de77788a6e2bed90332ba817893f@localhost> #1075: ghci unhandled exception on startup (memory access violation) ------------------------------------+--------------------------------------- Reporter: edbriggs@optonline.net | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ------------------------------------+--------------------------------------- Comment (by simonmar): Perhaps the same as #885. Try turning off Data Execution Prevention (see #885 for instructions), could you confirm that this fixes the bug for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 5 09:28:29 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1075: ghci unhandled exception on startup (memory access violation) In-Reply-To: <071.ed018432859bfb95e8a7b91690d468b1@localhost> References: <071.ed018432859bfb95e8a7b91690d468b1@localhost> Message-ID: <080.3ab1768e8fa584569e4ca03307155b37@localhost> #1075: ghci unhandled exception on startup (memory access violation) ------------------------------------+--------------------------------------- Reporter: edbriggs@optonline.net | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ------------------------------------+--------------------------------------- Old description: > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > Loading package base ... linking ... done. > > (JIT debugger invoked) Unhandled exception at 0x0233f988 in ghc.exe: > 0xC0000005: Access violation. > > This has never worked. Attempted following installation of the msi. > OS Version Windows Server 2003 SP1, 32 bit > > Disassembly > > 0233F97C add eax,200h > 0233F981 add byte ptr [eax],al > 0233F983 add byte ptr [edi],cl > 0233F985 add byte ptr [eax],al > 0233F987 db 00h > 0233F988 mov esi,dword ptr [ebp] << here > 0233F98B add ebp,4 > 0233F98E jmp dword ptr [ebp] > > EAX = 0141E010 EBX = 00D963C8 ECX = 00000001 EDX = 014B49D4 ESI = > 0242947C EDI = 014B49D0 EIP = 0233F988 ESP = 0022DED0 EBP = 01A3AF6C EFL > = 00010246 New description: {{{ ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. (JIT debugger invoked) Unhandled exception at 0x0233f988 in ghc.exe: 0xC0000005: Access violation. }}} This has never worked. Attempted following installation of the msi. OS Version Windows Server 2003 SP1, 32 bit {{{ Disassembly 0233F97C add eax,200h 0233F981 add byte ptr [eax],al 0233F983 add byte ptr [edi],cl 0233F985 add byte ptr [eax],al 0233F987 db 00h 0233F988 mov esi,dword ptr [ebp] << here 0233F98B add ebp,4 0233F98E jmp dword ptr [ebp] EAX = 0141E010 EBX = 00D963C8 ECX = 00000001 EDX = 014B49D4 ESI = 0242947C EDI = 014B49D0 EIP = 0233F988 ESP = 0022DED0 EBP = 01A3AF6C EFL = 00010246 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 5 09:32:16 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1076: runhaskell crash with .hi/.o files in the directory In-Reply-To: <071.bd967e6a99c05563037af5f6e38b2774@localhost> References: <071.bd967e6a99c05563037af5f6e38b2774@localhost> Message-ID: <080.254d9c8e594e4a5e1cf514717e618ad7@localhost> #1076: runhaskell crash with .hi/.o files in the directory ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ----------------------+----------------------------------------------------- Old description: > I've been playing around with the ICFP "universal machine" puzzle > (http://icfpcontest.org/task.shtml) > For prototyping, I'm using runhaskell as a "script engine" from the SciTE > editor on Win32. I'm running Windows XP Home 2002 SP2 with the package > GHC6.6 downloaded from haskell.org. > > I have some leftover .o/.hi files from compiling a previous version the > project via the command line. If I delete those, the problem goes away. > > I'll attach a zip of the directory contents as a repro case if the bug > tracker allows me to. > > >runhaskell um.hs > trying to Allocate array of size 0.. > trying to Abandon size 0 allocation.. > trying to Allocate size 11.. > trying Array Index on allocated array.. > trying Amendment of allocated array.. > checking Amendment of allocated array.. > trying Alloc(a,a) and amending it.. > comparing multiple allocations.. > pointer arithmetic.. > check old allocation.. > simple tests ok! > um.hs: internal error: interpretBCO: unknown or unimplemented opcode > 22656 > (GHC version 6.6 for i386_unknown_mingw32) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > > This application has requested the Runtime to terminate it in an unusual > way. > Please contact the application's support team for more information. > >Exit code: 3 New description: I've been playing around with the ICFP "universal machine" puzzle (http://icfpcontest.org/task.shtml) For prototyping, I'm using runhaskell as a "script engine" from the SciTE editor on Win32. I'm running Windows XP Home 2002 SP2 with the package GHC6.6 downloaded from haskell.org. I have some leftover .o/.hi files from compiling a previous version the project via the command line. If I delete those, the problem goes away. I'll attach a zip of the directory contents as a repro case if the bug tracker allows me to. {{{ >runhaskell um.hs trying to Allocate array of size 0.. trying to Abandon size 0 allocation.. trying to Allocate size 11.. trying Array Index on allocated array.. trying Amendment of allocated array.. checking Amendment of allocated array.. trying Alloc(a,a) and amending it.. comparing multiple allocations.. pointer arithmetic.. check old allocation.. simple tests ok! um.hs: internal error: interpretBCO: unknown or unimplemented opcode 22656 (GHC version 6.6 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. >Exit code: 3 }}} Comment (by simonmar): Possibly the same as #1013. Is it possible to reproduce the bug from scratch? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 5 09:39:47 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1078: Using X11 through ffi on windows does not work In-Reply-To: <071.c6188bd489b4229961960123f24870a0@localhost> References: <071.c6188bd489b4229961960123f24870a0@localhost> Message-ID: <080.19e926ad3520f90b0028ca7c61f4002f@localhost> #1078: Using X11 through ffi on windows does not work -----------------------------+---------------------------------------------- Reporter: Azmo | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 6.6 Severity: blocker | Resolution: wontfix Keywords: X11 ffi windows | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------+---------------------------------------------- Changes (by simonmar): * resolution: => wontfix * status: new => closed Comment: I don't think this can possibly work. You can't link to the Cygwin X11 libraries, because GHC on Windows does not produce Cygwin executables - see #1071. The partial Haskell/C solution ''might'' work, but you'll probably need to use Cygwin's gcc to compile the C file and to link the final executable. You might need to put the Haskell code in a DLL, I'm not sure. I'm going to close this bug, since we already have a feature request (#1071). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 5 10:40:24 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1081: HGL indefinite pause with "thread blocked indefinitely" message In-Reply-To: <071.17ce0eb3f351bd914dca627634964858@localhost> References: <071.17ce0eb3f351bd914dca627634964858@localhost> Message-ID: <080.9bd9ba1781edc83ba921834f3c8b6246@localhost> #1081: HGL indefinite pause with "thread blocked indefinitely" message ---------------------------------+------------------------------------------ Reporter: calvins | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.6 Severity: normal | Resolution: Keywords: hgl thread deadlock | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * component: Compiler => libraries (other) * milestone: => Not GHC Comment: I believe I've fixed some of the issues here, but there may be more. * The X11 library didn't provide a way to call XInitThreads, required for multithreaded clients. (now added, and called from `HGL.runGraphics` if necessary). * The XNextEvent function wasn't imported ''safe'', so it blocked the other threads. However, with these fixes, the program still hangs on startup until the first event is received. I'm not sure why - the two active threads both appear to be waiting in `XNextEvent`, so the program really is waiting for an event. Maybe an HGL expert is needed here (is there one?). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 5 10:48:18 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS In-Reply-To: <071.f2e5c5f7708f6538f8516c3f8ea20dcd@localhost> References: <071.f2e5c5f7708f6538f8516c3f8ea20dcd@localhost> Message-ID: <080.601623ca4d79f982b093b2e05d897990@localhost> #1085: Redesign of the scheme for getting the datacon symbol name of a closure in the RTS ----------------------------+----------------------------------------------- Reporter: mnislaih | Owner: Type: task | Status: new Priority: normal | Milestone: 6.8 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by simonmar): No, we definitely don't want to build all the libs twice! This only affects constructors, so the binary size increase should be minimal. We'll just live with it. Besides, we already derive `Data` for lots of types, and that instance already contains these strings - perhaps we could arrange to share them? The right way is to make a new kind of info table for constructors, just as we currently have `StgFunInfoTable` for functions, and `StgRetInfoTable` for return addresses. The constructor info table would have a single extra field, containing a pointer to the name of the constructor (in UTF-8, of course). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 5 11:40:31 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1082: Documentation missing from MacOS PPC binary In-Reply-To: <071.91323d2019255a91c4b19cb661ca43de@localhost> References: <071.91323d2019255a91c4b19cb661ca43de@localhost> Message-ID: <080.10298e5f0e0687d15e55368860f95f38@localhost> #1082: Documentation missing from MacOS PPC binary ---------------------------+------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ---------------------------+------------------------------------------------ Comment (by guest): Ahh...there *is* a separate download for documentation for offline use (e.g., gzipped HTML), but it only appears on the documentation page, not the download page. So it's less a missing-functionality issue than a website usability issue. Perhaps the documentation downloads should be mentioned on the download page. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jan 5 11:46:20 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1082: Documentation missing from MacOS PPC binary In-Reply-To: <071.91323d2019255a91c4b19cb661ca43de@localhost> References: <071.91323d2019255a91c4b19cb661ca43de@localhost> Message-ID: <080.730645df365191ca90cf844238293365@localhost> #1082: Documentation missing from MacOS PPC binary ---------------------------+------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ---------------------------+------------------------------------------------ Comment (by guest): And now I see that there is the download page I went to (http://haskell.org/ghc/download_ghc_66.html) which *doesn't* mention documentation and a download page that *does* mention documentation (http://www.haskell.org/ghc/download.html). I think adding mention of downloadable documentation to the 6.6 page and fixing the Makefile to mention documentation only if it installs it should be enough to close this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From jpeliz at icmc.usp.br Fri Jan 5 12:48:54 2007 From: jpeliz at icmc.usp.br (Jorge Marques Pelizzoni) Date: Thu Jul 19 09:48:03 2007 Subject: Visual Haskell (VS2005): stuck when building with Parsec Message-ID: <15100.200.158.224.184.1168019334.squirrel@mail2.icmc.usp.br> Hi, all! I've been using Visual Haskell 0.2 (though the About window claims 0.1) with Visual Studio 2005 for some time and it's quite a tool. However, I can't get it to build any project importing Text.ParserCombinators.Parsec. Even building the na?vest of all projects (in attachment) won't complete. However, building in the command line (just "ghc Main.hs") works fine. Thanks in advance. Cheers, Jorge M. Pelizzoni ICMC - Universidade de S?o Paulo -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.zip Type: application/x-zip-compressed Size: 4068 bytes Desc: not available Url : http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20070105/2a13f094/bug.bin From trac at galois.com Fri Jan 5 20:41:08 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1087: Bang pattern parsing with infix ops Message-ID: <071.a5fd1da3a1a464a3669f9eb5afccc128@localhost> #1087: Bang pattern parsing with infix ops ----------------------------------+----------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.6 Severity: normal | Keywords: bang patterns Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- {{{ $ ghci -fbang-patterns -- Ok Prelude> let at a !b = False in at 1 2 False Prelude> let (.!.) a !b = False in 1 .!. 2 False -- ~ patterns are ok Prelude> let a `at` ~b = False in at 1 2 False Prelude> let a .!. ~b = False in 1 .!. 2 False Prelude> let ~a .!. b = False in 1 .!. 2 False -- Parse error if we combine bang patterns with infix decls: Prelude> let a .!. !b = False in 1 .!. 2 :1:10: parse error on input `!' Prelude> let a `at` !b = False in at 1 2 :1:11: parse error on input `!' Prelude> let !a .!. b = False in 1 .!. 2 :1:5: Parse error in pattern }}} So looks like ops and infix declarations are missing a case for bang patterns. -- Don -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jan 6 07:01:49 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1088: : internal error: interpretBCO: unknown or unimplemented opcode Message-ID: <071.6e772d2d30b7f58940175e1daf7175d7@localhost> #1088: : internal error: interpretBCO: unknown or unimplemented opcode ---------------------------------------------+------------------------------ Reporter: matthew at wellquite dot org | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: x86 | Os: Linux ---------------------------------------------+------------------------------ I did try to post this to glasgow-haskell-bugs@haskell.org before christmas because I could not log into trac but as a non-subscriber it was "moderated" and never appeared... (Although architecture is set to x86, this also occurs on x86_64) I'm not sure precisely what the problem is here, but if you remove all the strictness modifiers then the problem goes away. Also, the following works fine: buildOctTree (Vec 0 0 0) 10 10 10 [(a,(Vec a a a)) | a <- [(-4.0),(-2.0)..4.0]] Also, having done that, the problematic expressions work fine - the bug only appears if the expression below is run as the first call to buildOctTree in the ghci session. This is on a P4, 2GB RAM, Debian unstable, ghc 6.6 (both hand rolled and from debian). uname -a = Linux smudge 2.6.18-2-686 #1 SMP Wed Nov 8 19:52:12 UTC 2006 i686 GNU/Linux > ghci -v OctTree ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Using package config file: /usr/lib/ghc-6.6/package.conf wired-in package base mapped to base-2.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.0 Hsc static flags: -static Loading package base ... linking ... done. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: *** Chasing dependencies: Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] Upsweep completely successful. *** Deleting temp files: Deleting: *** Chasing dependencies: Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] compile: input file OctTree.hs *** Checking old interface for main:OctTree: [1 of 1] Compiling OctTree ( OctTree.hs, interpreted ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 1587 *** Simplify: Result size = 2390 Result size = 2137 Result size = 2105 Result size = 2100 *** Tidy Core: Result size = 2198 *** CorePrep: Result size = 2646 *** ByteCodeGen: *** Deleting temp files: Deleting: Upsweep completely successful. *** Deleting temp files: Deleting: Ok, modules loaded: OctTree. *OctTree> buildOctTree (Vec 0 0 0) 10 10 10 [(a,(Vec a a a)) | a <- [(-4.0),(-3.9)..4.0]] *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: : internal error: interpretBCO: unknown or unimplemented opcode 20196 (GHC version 6.6 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted Thanks, Matthew Code follows: {- - OctTrees.hs: Implementation of OctTrees in Haskell - Copyright (C) 2006 Matthew Sackman - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License - as published by the Free Software Foundation; version 2 - of the License only. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110- 1301, USA. -} module OctTree (OctTree, buildOctTree, findInRadius ) where import Data.List data Vector = Vec !Double !Double !Double deriving (Show, Eq) findDisplacement :: Vector -> Vector -> (Double, Vector) findDisplacement (Vec ax ay az) (Vec bx by bz) = (len, Vec dx dy dz) where len = sqrt ((dx*dx) + (dy*dy) + (dz*dz)) dx = (bx - ax) dy = (by - ay) dz = (bz - az) -- lne usw data OctTree value = OctTree !Vector !Vector !(OctTreeNode value) deriving (Show) data OctTreeNode value = EmptyLeaf -- pos value | Leaf !Vector !(value) | Node -- lne lse lsw lnw !(OctTree value) !(OctTree value) !(OctTree value) !(OctTree value) -- unw usw use une !(OctTree value) !(OctTree value) !(OctTree value) !(OctTree value) deriving (Show) buildOctTree :: (Show a) => Vector -> Double -> Double -> Double -> [(a,Vector)] -> (OctTree a) buildOctTree (Vec mx my mz) x_size y_size z_size values = foldl' (\t (v,pos) -> insertValue t v pos) initial values where initial = OctTree (Vec (mx+x) (my+y) (mz-z)) (Vec (mx-x) (my-y) (mz+z)) EmptyLeaf x = x_size /2 y = y_size /2 z = z_size /2 insertValue :: (Show a) => (OctTree a) -> a -> Vector -> (OctTree a) insertValue (OctTree lnePos uswPos EmptyLeaf) value pos = OctTree lnePos uswPos (Leaf pos value) insertValue (OctTree lnePos@(Vec lne_x lne_y lne_z) uswPos@(Vec usw_x usw_y usw_z) (Leaf pos1 v1)) v2 pos2 = n3 where n1 = OctTree lnePos uswPos (Node lne lse lsw lnw unw usw use une) n2 = insertValue n1 v1 pos1 n3 = insertValue n2 v2 pos2 middle@(Vec mx my mz) = (Vec ((lne_x + usw_x)/2) ((lne_y + usw_y)/2) ((lne_z + usw_z)/2)) lne = OctTree lnePos middle EmptyLeaf lse = OctTree (Vec lne_x my lne_z) (Vec mx usw_y mz) EmptyLeaf lsw = OctTree (Vec mx my lne_z) (Vec usw_x usw_y mz) EmptyLeaf lnw = OctTree (Vec mx lne_y lne_z) (Vec usw_x my mz) EmptyLeaf unw = OctTree (Vec mx lne_y mz) (Vec usw_x my usw_z) EmptyLeaf usw = OctTree middle uswPos EmptyLeaf use = OctTree (Vec lne_x my mz) (Vec mx usw_y usw_z) EmptyLeaf une = OctTree (Vec lne_x lne_y mz) (Vec mx my usw_z) EmptyLeaf insertValue n@(OctTree lnePos uswPos (Node lne lse lsw lnw unw usw use une)) value pos = OctTree lnePos uswPos node where node = case inQuadrant lne pos of True -> (Node (insertValue lne value pos) lse lsw lnw unw usw use une) False -> case inQuadrant lse pos of True -> (Node lne (insertValue lse value pos) lsw lnw unw usw use une) False -> case inQuadrant lsw pos of True -> (Node lne lse (insertValue lsw value pos) lnw unw usw use une) False -> case inQuadrant lnw pos of True -> (Node lne lse lsw (insertValue lnw value pos) unw usw use une) False -> case inQuadrant unw pos of True -> (Node lne lse lsw lnw (insertValue unw value pos) usw use une) False -> case inQuadrant usw pos of True -> (Node lne lse lsw lnw unw (insertValue usw value pos) use une) False -> case inQuadrant use pos of True -> (Node lne lse lsw lnw unw usw (insertValue use value pos) une) False -> case inQuadrant une pos of True -> (Node lne lse lsw lnw unw usw use (insertValue une value pos)) False -> error $ "Value " ++ (show value) +++ " at position " ++ (show pos) ++ " is not in node " ++ (show n) inQuadrant :: (OctTree a) -> Vector -> Bool inQuadrant (OctTree (Vec lne_x lne_y lne_z) (Vec usw_x usw_y usw_z) _) (Vec x y z) = (x > usw_x) && (y > usw_y) && (z < usw_z) && (x <= lne_x) && (y <= lne_y) && (z >= lne_z) findInRadius :: OctTree a -> Vector -> Double -> [(a,Vector,Double)] findInRadius (OctTree _ _ EmptyLeaf) _ _ = [] findInRadius (OctTree _ _ (Leaf vPos value)) from radius = case dist <= radius of True -> [(value, vPos, dist)] False -> [] where (dist,_) = findDisplacement from vPos findInRadius (OctTree _ _ (Node lne lse lsw lnw unw usw use une)) from@(Vec fx fy fz) radius = concat result where children = filter findInRadius' [lne, lse, lsw, lnw, unw, usw, use, une] result = map (\n -> findInRadius n from radius) children findInRadius' :: OctTree a -> Bool findInRadius' (OctTree _ _ EmptyLeaf) = False findInRadius' (OctTree (Vec lne_x lne_y lne_z) (Vec usw_x usw_y usw_z) _) = ((fx + radius) > usw_x) && ((fx - radius) <= lne_x) && ((fy + radius) > usw_y) && ((fy - radius) <= lne_y) && ((fz - radius) < usw_z) && ((fz + radius) >= lne_z) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 7 21:51:03 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1089: Somewhat bad type error message Message-ID: <071.df804d9915662739b48f7a3d5fab79b8@localhost> #1089: Somewhat bad type error message ----------------------------------------+----------------------------------- Reporter: kirsten | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type checker) | Version: 6.6 Severity: trivial | Keywords: Difficulty: Unknown | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- {{{ module Small where import Data.Maybe filterNothings :: [[Maybe a]] -> [[a]] filterNothings xs = {- (map catMaybes) -} (filter someFun xs) someFun = all isJust -- Compiling the above code gives the following rather bad error message (in ghci 6.6): {- Small.hs:5:63: Couldn't match expected type `a' (a rigid variable) against inferred type `Maybe a' `a' is bound by the type signature for `filterNothings' at Small.hs:4:26 Expected type: [[a]] Inferred type: [[Maybe a]] In the second argument of `filter', namely `xs' In the expression: (filter (const True) xs) -} -- My error was leaving out the "(map catMaybes)" part, in the comment. -- I think that the error message shouldn't say anything about rigid variables, -- or at least, I find that confusing, as well as the fact that the error message -- mentions [a] -> Bool. The problem is the return type of the application -- of filter is [[Maybe a]], and the type signature I gave for filterNothings has the -- return type [[a]]. In an ideal world, the error message would point out that the type -- [[a]] doesn't match [[Maybe a]], without the additional noise. Indeed, if I change -- someFun to (const True), I do get the error message I'd like, although it still -- uses the word "rigid", which I find suboptimal. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 7 21:52:58 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1089: Somewhat bad type error message In-Reply-To: <071.df804d9915662739b48f7a3d5fab79b8@localhost> References: <071.df804d9915662739b48f7a3d5fab79b8@localhost> Message-ID: <080.d97a1e29fa8a1c7f70e15243fbffc659@localhost> #1089: Somewhat bad type error message -------------------------------------+-------------------------------------- Reporter: kirsten | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type checker) | Version: 6.6 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Comment (by kirsten): Oops, ignore the error message in the comment there. The actual error message from ghc for the code as it is there is: {{{ Small.hs:5:50: Couldn't match expected type `a' (a rigid variable) against inferred type `Maybe a1' `a' is bound by the type signature for `filterNothings' at Small.hs:4:26 Expected type: [a] -> Bool Inferred type: [Maybe a1] -> Bool In the first argument of `filter', namely `someFun' In the expression: (filter someFun xs) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jan 7 23:04:52 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1090: Bad monomorphism-restriction-related type error message Message-ID: <071.09297036e2b92277b9f1e830622c9019@localhost> #1090: Bad monomorphism-restriction-related type error message ----------------------------------------+----------------------------------- Reporter: kirsten | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type checker) | Version: 6.6 Severity: trivial | Keywords: Difficulty: Unknown | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Consider the following program: {{{ module Small2 where printFormatted :: IO () printFormatted = let myPrint :: (a -> String) -> a -> IO () myPrint f s = putStr (f s) -- myShow :: Show a => a -> IO () myShow = myPrint show in myShow 1 >> myShow "foo" }}} If I compile this I get: {{{ > ghc --make -no-recomp -c small2.hs [1 of 1] Compiling Small2 ( small2.hs, small2.o ) small2.hs:9:19: No instance for (Num [Char]) arising from the literal `1' at small2.hs:9:19 Possible fix: add an instance declaration for (Num [Char]) In the first argument of `myShow', namely `1' In the first argument of `(>>)', namely `myShow 1' In the expression: let myPrint :: (a -> String) -> a -> IO () myPrint f s = putStr (f s) myShow = myPrint show in (myShow 1) >> (myShow "foo") }}} The fix, of course, is to either add -fno-monomorphism-restriction or to uncomment the type signature for {{{myShow}}}, but it took me a while to figure that out. It would be much better if the error message would suggest adding a type signature for {{{myShow}}}. As it is, the suggestion to add an instance for {{{Num [Char]}}} is none too helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 06:18:03 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1091: parse error in comment {- | -} Message-ID: <071.072c08b3431d33f9107b6322a32973a6@localhost> #1091: parse error in comment {- | -} ----------------------------------+----------------------------------------- Reporter: ravi@bluespec.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.7 Severity: minor | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- Decided to try out the latest HEAD and discovered that my code was triggering a parse error ... in a comment. The comment commented out a guard in a case expression, and the | seems to trigger the parse error. Even odder, it doesn't always trigger a parse error (my first attempt to reproduce the issue with a "Hello World" program failed and you can see one {- | -} comment that doesn't trigger a parse error and one that does in the attached test case. Release ghc 6.6 deals with all of these cases just fine, so I presume it is some sort of silly regression. It's just an annoying one because it makes it harder to comment out code when you want to. An even odder thing, that I wasn't going to mention until I could reproduce it is that the HEAD ghc segfaults if you run it on the attached file after ghc 6.6 has generated a .hi file for it. I would have expected an error about incompatible .hi file versions... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 08:07:56 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <071.f32de85001b45350c69cb3b60e06405b@localhost> References: <071.f32de85001b45350c69cb3b60e06405b@localhost> Message-ID: <080.78859ece9acdb97fab2825af76bce680@localhost> #703: all binaries built by ghc have executable stacks ----------------------------+----------------------------------------------- Reporter: duncan | Owner: duncan Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler (NCG) | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Architecture: Multiple Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * type: bug => merge Comment: This is fixed by: {{{ Mon Jan 8 12:26:42 GMT 2007 Ian Lynagh * Have the mangler keep .note.GNU-stack Mon Jan 8 12:59:16 GMT 2007 Ian Lynagh * Have the splitter duplicate the .note.GNU-stack }}} in the head. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 08:08:21 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #703: all binaries built by ghc have executable stacks In-Reply-To: <071.f32de85001b45350c69cb3b60e06405b@localhost> References: <071.f32de85001b45350c69cb3b60e06405b@localhost> Message-ID: <080.577559cc8b6fe4cf0da5fc9c32b576c5@localhost> #703: all binaries built by ghc have executable stacks ----------------------------+----------------------------------------------- Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler (NCG) | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Architecture: Multiple Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: duncan => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 08:11:53 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #929: Strange buffering behaviour in GHCi In-Reply-To: <071.2d87abe3694c17f475ba80d98456804c@localhost> References: <071.2d87abe3694c17f475ba80d98456804c@localhost> Message-ID: <080.e58711a00092f631c81a7ee5e984a03e@localhost> #929: Strange buffering behaviour in GHCi ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: GHCi | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * testcase: => * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 08:50:24 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1092: initC: srt when compiling with profiling Message-ID: <071.fd1a2a6b035a6cdba61266a987b1d414@localhost> #1092: initC: srt when compiling with profiling ----------------------------------+----------------------------------------- Reporter: ravi@bluespec.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: major | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------+----------------------------------------- When compiling for profiling using HEAD, one file I'm working with blows up with initC: srt I boiled it down to a self-contained file (TT.hs) The command line I used with that file: /home/ravi/ghc_darcs/ghc/compiler/stage2/ghc-inplace -prof -auto-all -c -O2 TT.hs Compiling with -dcore-lint spits out a voluminous complaint about the result of Simplifier phase 0, iteration 1 out of 4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 08:52:13 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1092: initC: srt when compiling with profiling In-Reply-To: <071.fd1a2a6b035a6cdba61266a987b1d414@localhost> References: <071.fd1a2a6b035a6cdba61266a987b1d414@localhost> Message-ID: <080.d4266334c9b80d170eeda1d8497b61f7@localhost> #1092: initC: srt when compiling with profiling -------------------------------+-------------------------------------------- Reporter: ravi@bluespec.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by ravi@bluespec.com): And in case it wasn't clear, ghc-6.6 deals with both cases (my original code and the boiled-down file) just fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 09:48:47 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #941: readFile problem in ghci In-Reply-To: <071.44324c367b732ac62dfbe799a80dd131@localhost> References: <071.44324c367b732ac62dfbe799a80dd131@localhost> Message-ID: <080.9eec848e50bf7edb0cec6e7a66560fa0@localhost> #941: readFile problem in ghci ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: GHCi | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------+------------------------------------------------------ Changes (by simonmar): * resolution: => fixed * status: new => closed Comment: This is the same bug as #806, which is partially fixed. We still don't have real support for `hGetBufNonBlocking` on Windows (which is used by `Data.ByteString.Lazy.Char8.readFile`), but it does not crash now, it just behaves like `hGetBuf`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 10:19:41 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1088: : internal error: interpretBCO: unknown or unimplemented opcode In-Reply-To: <071.6e772d2d30b7f58940175e1daf7175d7@localhost> References: <071.6e772d2d30b7f58940175e1daf7175d7@localhost> Message-ID: <080.cadc5d34de6bfbff8796cd665172c8d8@localhost> #1088: : internal error: interpretBCO: unknown or unimplemented opcode ------------------------------------------+--------------------------------- Reporter: matthew at wellquite dot org | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Changes (by simonmar): * resolution: => duplicate * status: new => closed Comment: Duplicate of #1013. Please test a snapshot or release candidate before the 6.6.1 release if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 11:38:29 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #929: Strange buffering behaviour in GHCi In-Reply-To: <071.2d87abe3694c17f475ba80d98456804c@localhost> References: <071.2d87abe3694c17f475ba80d98456804c@localhost> Message-ID: <080.78ed12b8bf999c26f128d1c4830bcae6@localhost> #929: Strange buffering behaviour in GHCi ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.6.1 Component: GHCi | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * type: bug => merge Comment: Fixed by Mon Jan 8 16:28:38 GMT 2007 Ian Lynagh * When setting stdout and stderr to NoBuffering in GHCi, do stdin too. Fixes trac #929. Merge to 6.6 branch. in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 12:44:43 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #942: Windows programs throw uncaught Invalid HANDLE exception on exit In-Reply-To: <071.eb05467836e3d3a715ecfb4593d1a84c@localhost> References: <071.eb05467836e3d3a715ecfb4593d1a84c@localhost> Message-ID: <080.dc3e29c490e2ec2ca1ca35d65e777489@localhost> #942: Windows programs throw uncaught Invalid HANDLE exception on exit --------------------------------------------+------------------------------- Reporter: brianh@metamilk.com | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.6 Severity: major | Resolution: Keywords: uncaught exception HANDLE exit | Difficulty: Unknown Testcase: N/A | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 14:14:34 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #945: `waitForProcess' report in `install' in ghc-6.6 In-Reply-To: <071.9e1dc05932b9c6eedd8f8103bb56561e@localhost> References: <071.9e1dc05932b9c6eedd8f8103bb56561e@localhost> Message-ID: <080.eb9890bd0d5c0fffb5f461563d2dc031@localhost> #945: `waitForProcess' report in `install' in ghc-6.6 ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * cc: => mechvel@botik.ru Comment: Hi Serge, Do you have a testcase we can reproduce this with? Thanks Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 17:06:09 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1088: : internal error: interpretBCO: unknown or unimplemented opcode In-Reply-To: <071.6e772d2d30b7f58940175e1daf7175d7@localhost> References: <071.6e772d2d30b7f58940175e1daf7175d7@localhost> Message-ID: <080.7bd1989647fc162fc3e3441575368a6a@localhost> #1088: : internal error: interpretBCO: unknown or unimplemented opcode ------------------------------------------+--------------------------------- Reporter: matthew at wellquite dot org | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Comment (by matthew at wellquite dot org): Thanks, just tested with ghc-6.6.20070107 and indeed all is well again. Thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 18:24:02 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #942: Windows programs throw uncaught Invalid HANDLE exception on exit In-Reply-To: <071.eb05467836e3d3a715ecfb4593d1a84c@localhost> References: <071.eb05467836e3d3a715ecfb4593d1a84c@localhost> Message-ID: <080.102677467d278dc59a1d19d1d211e219@localhost> #942: Windows programs throw uncaught Invalid HANDLE exception on exit --------------------------------------------+------------------------------- Reporter: brianh@metamilk.com | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Runtime System | Version: 6.6 Severity: major | Resolution: Keywords: uncaught exception HANDLE exit | Difficulty: Unknown Testcase: N/A | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Comment (by igloo): This seems to be fixed in the HEAD. The 6.6 branch isn't building for me on Windows at the moment, so I haven't checked it yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jan 8 19:22:30 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1042: Floating point exception In-Reply-To: <071.6129ca626045912d2903729d98277b21@localhost> References: <071.6129ca626045912d2903729d98277b21@localhost> Message-ID: <080.630328beb403becfd09499689fa4c63b@localhost> #1042: Floating point exception ----------------------+----------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): minBound seems to be a better answer than 0 to me, but I would prefer an exception to both of them. That way div would always either succeed or raise an exception (div by zero or overflow). Also, unlike addition overflow (say), we need to check for this happening anyway, so there is no performance advantage to just letting it wrap by itself. Finally, I would expect that programmers realise that addition, multiplication etc might wrap, but I suspect none have considered that division might. Thanks Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 9 05:47:48 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1042: Floating point exception In-Reply-To: <071.6129ca626045912d2903729d98277b21@localhost> References: <071.6129ca626045912d2903729d98277b21@localhost> Message-ID: <080.82dd2eacdfa9cbdd58eef2e7c5b536fa@localhost> #1042: Floating point exception ----------------------+----------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): Those are certainly reasonable points - I'm happy to raise an exception in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 9 08:52:20 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #937: ghc-pkg should splice $topdir on Windows In-Reply-To: <071.ddaa1d8b163d273e112c90eb32c28911@localhost> References: <071.ddaa1d8b163d273e112c90eb32c28911@localhost> Message-ID: <080.30396e46103c3d59299010fc032b8ce0@localhost> #937: ghc-pkg should splice $topdir on Windows ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: N/A | Architecture: Multiple Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: mine -- Ticket URL: GHC The Glasgow Haskell Compiler From schneegloeckchen at gmx.li Tue Jan 9 09:13:24 2007 From: schneegloeckchen at gmx.li (mm) Date: Thu Jul 19 09:48:03 2007 Subject: Broken link Message-ID: <20070109141324.GB5911@manthe.gotdns.org> Hi, on http://haskell.org/ghc/docs/latest/html/libraries/mtl/Control-Monad-Writer.html there is a broken link. The correct link is http://web.cecs.pdx.edu/~mpj/pubs/springschool.html currently. What's the recent state of the planned migration from CVS to darcs? Is there an overview of the Project somewhere? schneegloeckchen From trac at galois.com Tue Jan 9 11:53:37 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:03 2007 Subject: [GHC] #1093: Windows: haddock-html fields are wrong in package.conf Message-ID: <071.2b38f0c5951af294941b4c35ebd3730e@localhost> #1093: Windows: haddock-html fields are wrong in package.conf -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Build System | Version: 6.6 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Windows -----------------------------+---------------------------------------------- {{{ $ c:/ghc/ghc-6.6/bin/ghc-pkg field network haddock-html haddock-html: $topdir\html\libraries\network }}} it should be {{{ haddock-html: $topdir\doc\html\libraries\network }}} Note the "doc\". After #937 is fixed, this is still preventing "setup haddock" from working in Cabal on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 9 11:55:22 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:04 2007 Subject: [GHC] #1094: Windows: haddock-html fields are wrong in package.conf Message-ID: <071.f2974b6ca8a176e754b364e289b5019a@localhost> #1094: Windows: haddock-html fields are wrong in package.conf -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Build System | Version: 6.6 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Windows -----------------------------+---------------------------------------------- {{{ $ c:/ghc/ghc-6.6/bin/ghc-pkg field network haddock-html haddock-html: $topdir\html\libraries\network }}} it should be {{{ haddock-html: $topdir\doc\html\libraries\network }}} Note the "doc\". After #937 is fixed, this is still preventing "setup haddock" from working in Cabal on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 9 11:55:45 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:04 2007 Subject: [GHC] #1095: Windows: haddock-html fields are wrong in package.conf Message-ID: <071.45d8baf1fa856d6eb54b6590681209c5@localhost> #1095: Windows: haddock-html fields are wrong in package.conf -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6.1 Component: Build System | Version: 6.6 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Windows -----------------------------+---------------------------------------------- {{{ $ c:/ghc/ghc-6.6/bin/ghc-pkg field network haddock-html haddock-html: $topdir\html\libraries\network }}} it should be {{{ haddock-html: $topdir\doc\html\libraries\network }}} Note the "doc\". After #937 is fixed, this is still preventing "setup haddock" from working in Cabal on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 9 14:33:45 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:04 2007 Subject: [GHC] #1089: Somewhat bad type error message In-Reply-To: <071.df804d9915662739b48f7a3d5fab79b8@localhost> References: <071.df804d9915662739b48f7a3d5fab79b8@localhost> Message-ID: <080.33f6cfd4218838bc717dbc38a5392096@localhost> #1089: Somewhat bad type error message -------------------------------------+-------------------------------------- Reporter: kirsten | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler (Type checker) | Version: 6.6 Severity: trivial | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by simonpj): * resolution: => wontfix * status: new => closed Comment: Thanks for the suggestions, but I don't really see how to improve this. Sometimes it's really, really heplful to have the localised mis-match, rather than {{{ Can't match (Tree Int -> [[Maybe a]] -> [Tree (Maybe a)]) with (Tree Int -> [[a]] -> [Tree (Maybe a)} }}} when it's hard to do a visual diff. I suppose I could leave out the "rigid" part if that would be less confusing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jan 9 14:37:14 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:04 2007 Subject: [GHC] #1090: Bad monomorphism-restriction-related type error message In-Reply-To: <071.09297036e2b92277b9f1e830622c9019@localhost> References: <071.09297036e2b92277b9f1e830622c9019@localhost> Message-ID: <080.c1033cd88a52c7630e24a60f124a934b@localhost> #1090: Bad monomorphism-restriction-related type error message -------------------------------------+-------------------------------------- Reporter: kirsten | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler (Type checker) | Version: 6.6 Severity: trivial | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by simonpj): * resolution: => wontfix * status: new => closed Comment: Again, I really don't see how to fix this. If there really was an instance for `Num [Char]` then the program really would be legal. Still I have to agree that it's not a terribly friendly message. Keep reporting them. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From mechvel at botik.ru Wed Jan 10 10:42:18 2007 From: mechvel at botik.ru (Serge D. Mechveliani) Date: Thu Jul 19 09:48:04 2007 Subject: #945: `waitForProcess' Message-ID: <20070110154218.GA1837@scico.botik.ru> On Mon, Jan 08, 2007 at 07:14:32PM -0000, GHC wrote: > #945: `waitForProcess' report in `install' in ghc-6.6 > ----------------------+----------------------------------------------------- > Reporter: guest | Owner: > Type: bug | Status: new > Priority: normal | Milestone: 6.6.1 > Component: Compiler | Version: 6.6 > Severity: normal | Resolution: > Keywords: | Difficulty: Unknown > Testcase: | Architecture: Unknown > Os: Linux | > --------------------------------------------------------------------------- > Changes (by igloo): > > * cc: => mechvel@botik.ru > > Comment: > > Hi Serge, > > Do you have a testcase we can reproduce this with? > > > Thanks > Ian When reporting, I tried to write down some description by copying by mouse to the field 'comment' (as I recall) but, probably, misused the page interface. Probably, it visible only "`waitForProcess' report in `install' in ghc-6.6". I somehow got used to this, changed something in the command sequence (do not recall what namely). So, this effect is visible very rarely now. Let us wait for next occasion. Regards, ----------------- Serge Mechveliani mechvel@botik.ru From trac at galois.com Thu Jan 11 14:08:52 2007 From: trac at galois.com (GHC) Date: Thu Jul 19 09:48:04 2007 Subject: [GHC] #1087: had a look into it, might be best to leave it as it is. In-Reply-To: <071.a5fd1da3a1a464a3669f9eb5afccc128@localhost> References: <071.a5fd1da3a1a464a3669f9eb5afccc128@localhost> Message-ID: <080.89ca00612f75276a3ecec7a1e9b3ef16@localhost> #1087: had a look into it, might be best to leave it as it is. -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.6 Severity: normal | Resolution: Keywords: bang patterns | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by benl): * summary: Bang pattern parsing with infix ops => had a look into it, might be best to leave it as it is. Comment: I don't think fixing this is going to be straight forward because '~' is a reserved op whereas '!' isn't. There's a conflict between bang patterns and use of a single '!' as an operator. We ''could'' allow bang patterns with infix decls by changing the infixexp rule as follows: {{{ infixexp : exp10 | infixexp qop bang_exp10 | '!' aexp qop bang_exp10 -- (A) bang_exp10 : exp10 | '!' exp10 }}} However, adding the rule marked (A) to get them on the right hand side of the qop introduces a boatload (43) of shift/reduce conflicts into the parser, all at the following point: {{{ State 236 infixexp -> '!' . aexp qop bang_exp10 (rule 303) special_sym -> '!' . (rule 516) '_' shift, and enter state 111 (reduce using r