From trac at galois.com Mon Sep 1 06:10:41 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 06:09:04 2008 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> References: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> Message-ID: <051.e76a76bc867b081dbdf0ad6794a60f31@localhost> #2530: deriving Show adds extra parens for constructor with record syntax ----------------------+----------------------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * milestone: 6.10 branch => 6.12 branch Comment: I'm not sure what the resolution is here. * Hugs and GHC produce different output, but both are legal. * Which output you like is something of a matter of taste. My own taste prefers GHC's output. * If there was a strong lobby in favour of matching output, then we could change GHC or change Hugs. This isn't a terribly big deal, and the easiest thing to do is, well, nothing. So if you want a change, can you lead a discussion that converges on a particular course of action? Meanwhile, I'll move this off the 6.10 branch. But if the discussion converges quickly we can easily put it in 6.10. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 06:54:52 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 06:53:10 2008 Subject: [GHC] #2558: re-throwing an asynchronous exception throws it synchronously Message-ID: <047.339350d6751eeb20e19b24c52175ed9b@localhost> #2558: re-throwing an asynchronous exception throws it synchronously -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- If you catch and re-throw an asynchronous exception, the second time it will be thrown synchronously. This only makes a difference when using `unsafePerformIO` or `unsafeInterleaveIO`, because otherwise the `catch` will not be inside any thunks. This could have the unfortunate effect of updating an `unsafePerformIO` thunk with `Timeout`, or `KillThread`, or some other asychronous exception that should not be recorded as the value of the thunk. We believe that exceptions thrown by an exception handler should be thrown in the same mode (synchronous or asynchronous) as the original exception. This means that we need to * keep track of the current exception-throwing mode * push a frame when in an exception handler (we already do this, because the exception handler is implicitly wrapped in `block`) * respect this mode when throwing exceptions. This raises another issue: catching an exception and recovering by tail- calling out of the exception handler is not a good thing to do. Currently it has the undesirable effect that the thread remains in `block` mode, and an explicit `unblock` is required. With the changes above, the thread may also remain in "asynchronous exception" mode. The right way to solve this is just "don't do that". Here's how to use the exception API: * For cleanup, use `finally`, `bracket`, and `onException`. * To modify the exception, use `mapException`. * For recovery, use `try`. Perhaps we should be deprecating `catch`? Or perhaps `catch` should be implemented in terms of `try`, so it doesn't have the implicit `block` / re-throw async exceptions behaviour? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 06:55:13 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 06:53:30 2008 Subject: [GHC] #2558: re-throwing an asynchronous exception throws it synchronously In-Reply-To: <047.339350d6751eeb20e19b24c52175ed9b@localhost> References: <047.339350d6751eeb20e19b24c52175ed9b@localhost> Message-ID: <056.f01506aa99c233706ae255d6a9c64025@localhost> #2558: re-throwing an asynchronous exception throws it synchronously ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 08:08:40 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 08:06:58 2008 Subject: [GHC] #2006: unreachable GADT pattern clauses show up as warnings with -Wall In-Reply-To: <044.a004885c928a62e2a73bf12df457c462@localhost> References: <044.a004885c928a62e2a73bf12df457c462@localhost> Message-ID: <053.d6100d3db63e2d13766d384528cc5dfe@localhost> #2006: unreachable GADT pattern clauses show up as warnings with -Wall ----------------------+----------------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by ertai): * cc: nicolas.pouillard@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 08:11:00 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 08:09:16 2008 Subject: [GHC] #2057: inconsistent .hi file error gets ignored In-Reply-To: <045.e53c768183aca8a1a40fddc456cadee9@localhost> References: <045.e53c768183aca8a1a40fddc456cadee9@localhost> Message-ID: <054.9f3838c371add7c3199639b96214c5fb@localhost> #2057: inconsistent .hi file error gets ignored ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by ertai): * cc: nicolas.pouillard@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 08:12:00 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 08:10:21 2008 Subject: [GHC] #2151: GADTs in function Patterns In-Reply-To: <047.2f6478e8e827595da4825a54c1ec722c@localhost> References: <047.2f6478e8e827595da4825a54c1ec722c@localhost> Message-ID: <056.d1bb36fe442c458e7699362efcf7138c@localhost> #2151: GADTs in function Patterns ----------------------+----------------------------------------------------- Reporter: hpacheco | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by ertai): * cc: nicolas.pouillard@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 09:30:06 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 09:28:24 2008 Subject: [GHC] #2534: Odd probable cause given by type checker In-Reply-To: <047.ed1af1376e750ad1e5dab7d0ee130215@localhost> References: <047.ed1af1376e750ad1e5dab7d0ee130215@localhost> Message-ID: <056.7563006b49755fae3db3d75ce9b85e13@localhost> #2534: Odd probable cause given by type checker -------------------------------------+-------------------------------------- Reporter: heatsink | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: => simonpj * milestone: 6.10 branch => 6.12 branch Comment: I'm probably the right person to look at this, but not before 6.10. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 09:50:15 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 09:48:32 2008 Subject: [GHC] #788: Class aliases (as proposaed by John Meacham) In-Reply-To: <046.352573f276ea0b65a1451eea70e3a225@localhost> References: <046.352573f276ea0b65a1451eea70e3a225@localhost> Message-ID: <055.cdb349aa0bdbc1322a68cc8c1199a947@localhost> #788: Class aliases (as proposaed by John Meacham) -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by Deewiant): * cc: Deewiant (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 10:12:17 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 10:10:38 2008 Subject: [GHC] #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu In-Reply-To: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> References: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> Message-ID: <053.201ba92aa4430f7ffcd0a5f39cc60812@localhost> #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu ---------------------------+------------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: trivial | Resolution: Keywords: OGI | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Comment (by simonmar): I've made the mtl changes in my tree, btw. Will push later. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 10:14:24 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 10:12:41 2008 Subject: [GHC] #2554: internal error: stg_ap_pp_ret (with terminfo) In-Reply-To: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> References: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> Message-ID: <053.c2d8e33a07361eca538c572b3934a6da@localhost> #2554: internal error: stg_ap_pp_ret (with terminfo) ----------------------+----------------------------------------------------- Reporter: judah | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonmar): * priority: normal => high * owner: => simonmar Comment: So you need a "quickest" build, i.e. no library optimisation? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 10:36:12 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 10:34:29 2008 Subject: [GHC] #1501: Panic in RegisterAlloc In-Reply-To: <044.f7c3918326114c19463f5f9e9eea6707@localhost> References: <044.f7c3918326114c19463f5f9e9eea6707@localhost> Message-ID: <053.4126aad56cb018371da245f50ed763a0@localhost> #1501: Panic in RegisterAlloc ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler (NCG) | Version: 6.9 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: cmm002 | Architecture: x86 Os: Multiple | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: reopened => closed * resolution: => worksforme Comment: Unable to reproduce with 6.8.3 on x86 or x86_64, with or without `-dcmm- lint`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 10:37:24 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 10:37:21 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.9e4487a43440cf574f84e385884b417f@localhost> #1876: Complete shared library support ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * milestone: 6.10.1 => 6.10 branch Comment: I've made some progress on this, but it doesn't look like I'll have time to finish it for 6.10.1. Since it doesn't involve API changes, we could possibly get it into a later 6.10 release, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 10:42:15 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 10:40:31 2008 Subject: [GHC] #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu In-Reply-To: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> References: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> Message-ID: <053.ff700079b7fcb871a00cb58a4fc0ee53@localhost> #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu ---------------------------+------------------------------------------------ Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: trivial | Resolution: Keywords: OGI | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * owner: igloo => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 10:42:25 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 10:40:41 2008 Subject: [GHC] #1501: Panic in RegisterAlloc In-Reply-To: <044.f7c3918326114c19463f5f9e9eea6707@localhost> References: <044.f7c3918326114c19463f5f9e9eea6707@localhost> Message-ID: <053.f8eff4b215512d20abf85163ca2bd3b1@localhost> #1501: Panic in RegisterAlloc ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: high | Milestone: 6.12 branch Component: Compiler (NCG) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: cmm002 | Architecture: x86 Os: Multiple | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: worksforme => * milestone: 6.10.1 => 6.12 branch Comment: However, on a hunch I added -O, and that made the compiler go into an infinite loop. We should check that the new code generator gets this right. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 10:44:00 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 10:42:17 2008 Subject: [GHC] #2554: internal error: stg_ap_pp_ret (with terminfo) In-Reply-To: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> References: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> Message-ID: <053.97f0e6a6a03de13c47e69e4cc485f12f@localhost> #2554: internal error: stg_ap_pp_ret (with terminfo) ----------------------+----------------------------------------------------- Reporter: judah | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by igloo): `quickest` in the sense of `mk/build.mk.sample`, yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 10:57:43 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 10:56:01 2008 Subject: [GHC] #2559: Haddock: Prelude docs are missing Bool, Int, Integer Message-ID: <047.6b5ad6adf37064133e2d331c93c65494@localhost> #2559: Haddock: Prelude docs are missing Bool, Int, Integer ------------------------------+--------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: major | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ------------------------------+--------------------------------------------- The documentation for the `Prelude` is now missing some of the basic types, particularly `Bool`, `Int`, and `Integer`. I suspect this is because these types are now in the `ghc-prim` package. We need to do something about this before the release. See also #2337. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 11:22:35 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 11:20:56 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.54085ccf7edaad9a10ae5c472718c603@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Comment (by simonmar): I'm validating the code now. Any chance you could whip up a test for the testsuite? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 13:13:55 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 13:12:22 2008 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.480c8e217433ea534914c2e6db8a94f1@localhost> #1895: Allow aliases in GHCi module imports -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by Toxaris): * cc: rendel@daimi.au.dk (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 19:35:30 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 19:33:46 2008 Subject: [GHC] #2560: killThread and getChanContents appear to interact strangely Message-ID: <053.7b90af27065da85db72f8f049c3b99b1@localhost> #2560: killThread and getChanContents appear to interact strangely -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------------+-------------------------------------------- I'm not sure if this an error in my program or in GHC, but I think the behaviour I'm seeing is strange enough to merit a place on the tracker. I'm particularly confused by the fact that my correctGetChanContents appears to be able to return an empty list! To run the test case, compile the file below and run it. It /should/ fail to terminate, with a lot of output like this: {{{ Here we go In the thread Got an element CHUNK CHUNK CHUNK: length = 1 Here we go In the thread Got an element CHUNK CHUNK CHUNK: length = 1 Here we go In the thread Got an element }}} Sometimes this doesn't happen (it's nondeterministic). If it completes succesfully then try it again. {{{ module Main where import System.IO.Unsafe import Control.Exception import Control.Concurrent import Data.Maybe import Prelude hiding (catch) {- THE PROBLEM =========== This Haskell program nondeterministically fails to terminate. EXPLANATION =========== This example is extracted from a larger program and hence has a number of interacting parts that conspire to create the bug. They are: 1) Timed-out evaluation. The timeoutList function takes a lazy list computation and a number of microseconds and returns as much of the list as could be evaluated in that number of microseconds. 2) "Improving" IO. To use this you write a sort of IO action that is able to call yieldImprovement at any time. When this is "run" with runImprovingIO you get back an action that can be run to actually do the IO computation you specified in the first place and a lazy list which represents the sequence of "improvements" that will be output by that computation at some future point in time. In this example, the computation part of the Improving IO is spun off to be evaluated on another thread, and the lazy list is consumed in chunks of as many items as can be read in 10ms by readWithTimeout. The test makes an Improving IO action that yields "improvements" that are just a sequence of numbers, and makes sure that they all come back via the lazy list of improvements when it is read in this chunky, timed-out manner. TENTATIVE CAUSE =============== The getChanContents function seems to not be exception-safe. If the timed- out evaluation kills its thread before it runs to completion, the channel seems to be left in an undefined state, causing it to stop yielding values and hanging the program. I have demonstrated a version, correctGetChanContents, that tries to fix this problem by blocking asynchronous exceptions during a readChan call. However, although the program is indeed more reliable, the problem still sporadically occurs! Argh! STRANGE THINGS ============== If you change the definition of correctGetChanContents to include an initial call to block and the program subsequently enters the buggy state, we get the error: > Main: reifyList: list finished before a final value arrived How is that possible?? This even occurs if the second call to block is removed. -} main :: IO () main = do {- This doesn't terminate, which proves that block and killThread work: tid <- block $ forkIO $ let loop x = loop (x + 1) in loop 0 killThread tid -} -- I found that the test almost always worked when the input list -- went up to 5000, failed 1/3 of the time when it went up to 20000, -- and always failed (didn't terminate) with a list of length 100000. let input = [1..5000] :: [Int] -- Kick off improving IO and actually run the IO stuff in another thread (improving, action) <- runImprovingIO (mapM_ yieldImprovement input) forkIO action -- We now want to get all of the items from the input that we sent through -- the improving IO channel by reading from the channel in time chunks 10ms -- in length. -- See comments in readWithTimeout to find out about this -1 output <- readWithTimeout (length input - 1) improving --print output --print (length output) -- Assert that the output matches if input == output then putStrLn "OK" else putStrLn "Nope" where readWithTimeout n improving | n <= 0 = return [] | otherwise = do -- For the sake of argument use a 10ms time step for the timeout chunk <- timeoutList 10000 (allListHeads improving) putStrLn $ "CHUNK CHUNK CHUNK: length = " ++ show (length chunk) -- Now we have a chunk, retrieve the next chunk rest <- case listToMaybeLast chunk of Nothing -> do -- This case only appears if the timeout period was insufficient to return even a single -- item from the improving value. It never occurs in practice. readWithTimeout n improving Just last_improving -> do -- This is the normal case. We got at least one item, so we should continue reading the -- improving value in chunks. However, we need to bear in mind that the first item in -- the chunk we are working with will actually be the one we started with, so we shouldn't -- include it when working out how many additional items we need to obtain, hence the +1. readWithTimeout (n + 1 - length chunk) last_improving -- We need to drop the first improving value returned from the recursive call, as it will just be -- the one we gave the recursive call initially, hence the drop 1. return $ (mapMaybe maybeHead chunk) ++ drop 1 rest allListHeads :: [a] -> [[a]] allListHeads list@[] = [list] allListHeads list@(_:rest) = list : allListHeads rest listToMaybeLast :: [a] -> Maybe a listToMaybeLast = listToMaybe . reverse maybeHead :: [a] -> Maybe a maybeHead (x:_) = Just x maybeHead [] = Nothing -- -- Evaluation with timeout -- -- | Evaluates the given list for the given number of microseconds. After the time limit -- has been reached, a list is returned consisting of the prefix of the list that was -- successfully evaluated within the time limit. -- -- This function does /not/ evaluate the elements of the list: it just ensures that the -- list spine arrives in good order. timeoutList :: Int -> [a] -> IO [a] timeoutList timeout improving = do -- Create var that will be used to store the known prefix (in reverse order) putStrLn "Here we go" known_prefix_var <- newMVar [] -- Go off and get as much of that prefix as we can thread_id <- forkIO (putStrLn "In the thread" >> go known_prefix_var improving) -- Wait for it to do its thing, then kill the thread threadDelay timeout killThread thread_id -- Return that prefix mb_known_prefix <- tryTakeMVar known_prefix_var case mb_known_prefix of Nothing -> error "timeoutList: bug in threading logic!" Just known_prefix -> return (reverse known_prefix) where go _ [] = putStrLn "Bottom" >> return () go var (x:xs) = do putStrLn "Got an element" modifyMVar_ var (\current_prefix -> return (x : current_prefix)) go var xs -- -- The ImprovingIO monad -- newtype ImprovingIO i a = IIO { unIIO :: Chan (Maybe i) -> IO a } instance Monad (ImprovingIO i) where return x = IIO (const $ return x) ma >>= f = IIO $ \chan -> do a <- unIIO ma chan unIIO (f a) chan yieldImprovement :: i -> ImprovingIO i () yieldImprovement improvement = IIO $ \chan -> writeChan chan (Just improvement) runImprovingIO :: ImprovingIO i () -> IO ([i], IO ()) runImprovingIO iio = do chan <- newChan let action = do unIIO iio chan putStrLn "SIGNALLING LIST END - everything is available!" writeChan chan Nothing -- @Nothing@ signals the end of the list yielded_improvements <- correctGetChanContents chan return (reifyList yielded_improvements, action) correctGetChanContents :: Chan a -> IO [a] correctGetChanContents ch = block $ unsafeInterleaveIO (block $ do x <- readChan ch xs <- correctGetChanContents ch return (x:xs) ) liftIO :: IO a -> ImprovingIO i a liftIO io = IIO $ const io reifyList :: [Maybe i] -> [i] reifyList (Just x:rest) = x : reifyList rest reifyList (Nothing:_) = [] reifyList [] = error "reifyList: list finished before a final value arrived" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 1 19:37:05 2008 From: trac at galois.com (GHC) Date: Mon Sep 1 19:35:21 2008 Subject: [GHC] #2560: killThread and getChanContents appear to interact strangely In-Reply-To: <053.7b90af27065da85db72f8f049c3b99b1@localhost> References: <053.7b90af27065da85db72f8f049c3b99b1@localhost> Message-ID: <062.27b5b54c85df836c44d2e1d494dc28d5@localhost> #2560: killThread and getChanContents appear to interact strangely -------------------------------+-------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------------+-------------------------------------------- Comment (by batterseapower): Forgot to mention: the test case above uses a 5000 element list. For some reason, this causes quite a few failures on my machine. If it doesn't work on yours, try bumping it up to 100000 or so, which should make the failure certain. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 04:20:54 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 04:19:10 2008 Subject: [GHC] #2300: GHCi locks up on long input In-Reply-To: <042.b8baab5f9560c1bc1ba314b7db87b0d2@localhost> References: <042.b8baab5f9560c1bc1ba314b7db87b0d2@localhost> Message-ID: <051.32504d04f8fdfb6dc5a511d7f58901d8@localhost> #2300: GHCi locks up on long input --------------------+------------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------+------------------------------------------------------- Comment (by simonmar): I haven't seen it either. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 04:24:04 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 04:22:19 2008 Subject: [GHC] #2462: Data.List.sum is slower than 6.8.3 In-Reply-To: <047.a070686fa958e3b92e101be0217ff9b1@localhost> References: <047.a070686fa958e3b92e101be0217ff9b1@localhost> Message-ID: <056.f080a1e50e69ebe856b6dc8b0ac7ed85@localhost> #2462: Data.List.sum is slower than 6.8.3 --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: run-time performance bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Comment (by simonmar): unreproducible for me too now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 05:25:43 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 05:23:58 2008 Subject: [GHC] #2469: Linking fails with "multiple definition of `deRefStablePtr'" In-Reply-To: <048.9eb18d1762f2087efabea300fec1f63f@localhost> References: <048.9eb18d1762f2087efabea300fec1f63f@localhost> Message-ID: <057.f35e742e16c7dc6d3fc04970da0ff6e4@localhost> #2469: Linking fails with "multiple definition of `deRefStablePtr'" ----------------------------------+----------------------------------------- Reporter: meteficha | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: Keywords: linker ffi stableptr | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * priority: normal => high Comment: Looks like a show-stopper => high priority -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 08:15:00 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 08:14:03 2008 Subject: [GHC] #1999: panic with GADT etc. In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost> References: <046.74c6dc616261a913ffd4180fb00731f0@localhost> Message-ID: <055.08453b46e8be03eb6008cec4d161425e@localhost> #1999: panic with GADT etc. ---------------------------+------------------------------------------------ Reporter: jeltsch | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T1999, T1999a | Architecture: x86 Os: Linux | ---------------------------+------------------------------------------------ Changes (by simonpj): * testcase: T1999 => T1999, T1999a -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 08:39:11 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 08:37:25 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.6a707984be895321ece2a6ae95ccdbae@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: {{{ Wed Aug 27 03:24:14 PDT 2008 Simon Marlow * re-fix of #1205, fix #2542 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 09:07:21 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 09:05:35 2008 Subject: [GHC] #2374: MutableByteArray# is slower than Addr# In-Reply-To: <044.46877f1bb530048ac22aec20e1b9d3f2@localhost> References: <044.46877f1bb530048ac22aec20e1b9d3f2@localhost> Message-ID: <053.9101cadb68918c0e58c1468573146106@localhost> #2374: MutableByteArray# is slower than Addr# -------------------------------+-------------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (NCG) | Version: 6.8.2 Severity: minor | Resolution: Keywords: performance array | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Comment (by batterseapower): I get results exactly opposite to those dolio reports when trying to reproduce this. My times are: {{{ -fvia-c: Before SAT: real 0m17.201s After SAT: real 0m10.498s -fasm: Before SAT: real 0m14.942s After SAT: real 0m14.695s }}} So the NCG is unaffected by SATing the arr argument of reverse, while GCC /is/ affected but it improves the code rather than making it worse. I don't really understand why our results are so different. I've attached the benchmarking script and source files I used in the hopes that someone who understands the NCG better can work out why we aren't benefiting from SAT while GCC is. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 09:09:44 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 09:07:58 2008 Subject: [GHC] #2374: MutableByteArray# is slower than Addr# In-Reply-To: <044.46877f1bb530048ac22aec20e1b9d3f2@localhost> References: <044.46877f1bb530048ac22aec20e1b9d3f2@localhost> Message-ID: <053.19c3360b5ed4c7d567078a2ebbd57d3b@localhost> #2374: MutableByteArray# is slower than Addr# -------------------------------+-------------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (NCG) | Version: 6.8.2 Severity: minor | Resolution: Keywords: performance array | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Comment (by batterseapower): I should add, actually, that I got my results on a Mac OS X 10.5 system running i386 code on Xeons (an early 2008 Mac Pro). The installed GCC is v4.0.1 and GHC was HEAD version 6.9.20080831. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 09:15:44 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 09:14:00 2008 Subject: [GHC] #2554: internal error: stg_ap_pp_ret (with terminfo) In-Reply-To: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> References: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> Message-ID: <053.73efd8c9e610ac40eec4d5d1ab39f3e7@localhost> #2554: internal error: stg_ap_pp_ret (with terminfo) ----------------------+----------------------------------------------------- Reporter: judah | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Tue Sep 2 13:45:04 BST 2008 Simon Marlow * FIX #2554: GHC.TopHandler.{runIO,runNonIO} should be GC roots }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 09:19:20 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 09:17:40 2008 Subject: [GHC] #2397: inclusion of Network.Curl causes compiler issues and coredumps In-Reply-To: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> References: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> Message-ID: <053.c1da9f27ce64105ed8349823d8ec5800@localhost> #2397: inclusion of Network.Curl causes compiler issues and coredumps -------------------------------+-------------------------------------------- Reporter: b7j0c | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: curl, GC | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 09:21:03 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 09:19:16 2008 Subject: [GHC] #2528: nub not as reliable as nubBy In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> Message-ID: <056.2ad1c9a1718a5938fff47fd071f653d8@localhost> #2528: nub not as reliable as nubBy ----------------------------+----------------------------------------------- Reporter: jdressel | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Tue Sep 2 10:29:50 BST 2008 Simon Marlow * #2528: reverse the order of args to (==) in nubBy to match nub }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 09:23:06 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 09:21:19 2008 Subject: [GHC] #2559: Haddock: Prelude docs are missing Bool, Int, Integer In-Reply-To: <047.6b5ad6adf37064133e2d331c93c65494@localhost> References: <047.6b5ad6adf37064133e2d331c93c65494@localhost> Message-ID: <056.89384afaac418e03ef55c94ee7cd42e5@localhost> #2559: Haddock: Prelude docs are missing Bool, Int, Integer ---------------------------+------------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 11:20:49 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 11:19:11 2008 Subject: [GHC] #2397: inclusion of Network.Curl causes compiler issues and coredumps In-Reply-To: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> References: <044.71a03c5613ebce7a7a5b57faf13a6e22@localhost> Message-ID: <053.32df10e836fb6acd45a5469eb581f61b@localhost> #2397: inclusion of Network.Curl causes compiler issues and coredumps -------------------------------+-------------------------------------------- Reporter: b7j0c | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: curl, GC | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: I've been unable to reproduce this on x86-64-Linux (however I did find a problem with the curl library and GHC 6.10 which I've fixed, so it wasn't a completely pointless exercise). Lacking a way to reproduce this we'll have to close the ticket and hope if the bug still exists that it resurfaces later. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 11:43:47 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 11:42:01 2008 Subject: [GHC] #2469: Linking fails with "multiple definition of `deRefStablePtr'" In-Reply-To: <048.9eb18d1762f2087efabea300fec1f63f@localhost> References: <048.9eb18d1762f2087efabea300fec1f63f@localhost> Message-ID: <057.5f2e27734d5c51a4ef12814b01249e27@localhost> #2469: Linking fails with "multiple definition of `deRefStablePtr'" ----------------------------------+----------------------------------------- Reporter: meteficha | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: Keywords: linker ffi stableptr | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: `deRefStablePtr` is defined like this: {{{ #if defined(__GNUC__) # ifndef RTS_STABLE_C extern inline # endif StgPtr deRefStablePtr(StgStablePtr sp) { ASSERT(stable_ptr_table[(StgWord)sp].ref > 0); return stable_ptr_table[(StgWord)sp].addr; } #else /* No support for 'extern inline' */ extern StgPtr deRefStablePtr(StgStablePtr sp); #endif }}} and `extern inline` is supposed to treat the definition as a macro; that is, it never gets emitted into the object file, which is what we want. This seems to be working correctly with the various gcc versions I have here. What gcc versions are installed on the boxes that fail? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 11:54:11 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 11:52:28 2008 Subject: [GHC] #2359: Data.IntMap update{Min, Max}WithKey corrupts data structure In-Reply-To: <042.245aba7cabc38180cbe3d307aebd0f3e@localhost> References: <042.245aba7cabc38180cbe3d307aebd0f3e@localhost> Message-ID: <051.82405ecbae6bb204ceab78d7c5335b75@localhost> #2359: Data.IntMap update{Min,Max}WithKey corrupts data structure ----------------------------+----------------------------------------------- Reporter: nwf | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: Looks ok to me; I'll validate & commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 2 18:12:52 2008 From: trac at galois.com (GHC) Date: Tue Sep 2 18:11:22 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.1a5123ab27abe50130bb098b593ce732@localhost> #1876: Complete shared library support ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by ajd): * cc: alexander.dunlap@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 05:32:07 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 05:30:20 2008 Subject: [GHC] #1934: Bad interplay between -O2 and -prof -auto-all in GHC-6.6.1 In-Reply-To: <056.9240df8333d09b5378a25d28d27c77ce@localhost> References: <056.9240df8333d09b5378a25d28d27c77ce@localhost> Message-ID: <065.28f803eebdd49740258e39eab315bd4e@localhost> #1934: Bad interplay between -O2 and -prof -auto-all in GHC-6.6.1 -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: Doesn't happen with HEAD, and life's too short to find out what the original bug was. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 09:35:25 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 09:33:36 2008 Subject: [GHC] #2559: Haddock: Prelude docs are missing Bool, Int, Integer In-Reply-To: <047.6b5ad6adf37064133e2d331c93c65494@localhost> References: <047.6b5ad6adf37064133e2d331c93c65494@localhost> Message-ID: <056.25ecec2b44fe662faa3f017618e5da8c@localhost> #2559: Haddock: Prelude docs are missing Bool, Int, Integer ---------------------------+------------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * priority: high => normal * owner: igloo => * severity: major => normal * milestone: 6.10.1 => 6.10 branch Comment: There are two parts to this. One is that we need to give haddock the interface files for the transitive dependencies, not just the direct dependencies, as it needs to know what ghc-prim has and where to make the HTML links point. This is now fixed in Cabal. The other part is that types like `Bool` aren't appearing in `modInfoTyThings`. For haddock, we can work around this by explicitly exporting them, so we now do have docs in the libraries. However, we ought to fix the root cause for other GHC API users. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 10:46:03 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 10:44:13 2008 Subject: [GHC] #2517: remove 'pure' method from Arrow class In-Reply-To: <043.bffe8bdb0940ee07d4e323e480390725@localhost> References: <043.bffe8bdb0940ee07d4e323e480390725@localhost> Message-ID: <052.ef5580c11b28cb1a5d7ac1c96ecfec6e@localhost> #2517: remove 'pure' method from Arrow class ----------------------------+----------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by ross): * status: new => closed * resolution: => fixed Comment: Discussion was limited, with a few supporters and no dissent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 11:29:18 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 11:27:29 2008 Subject: [GHC] #2438: memory performance problem when compiling lots of derived instances in a single file In-Reply-To: <044.ea581854aeddeff62675b30ef35f5bfc@localhost> References: <044.ea581854aeddeff62675b30ef35f5bfc@localhost> Message-ID: <053.c2940226ab6443cb21b59a29e2b65236@localhost> #2438: memory performance problem when compiling lots of derived instances in a single file ------------------------------------------+--------------------------------- Reporter: claus | Owner: Type: compile-time performance bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I declare this fixed, as a result of {{{ Wed Sep 3 13:02:28 BST 2008 simonpj@microsoft.com * Major change in compilation of instance declarations (fix Trac #955, #2328) }}} Here are the timings {{{ bash-3.2$ time ghc -c -fforce-recomp Instances.hs -package ghc real 0m7.039s user 0m6.546s sys 0m0.361s bash-3.2$ time ghc -c -fforce-recomp Instances0.hs -package ghc real 0m1.271s user 0m1.069s sys 0m0.111s bash-3.2$ time ghc -c -fforce-recomp All.hs -package ghc real 0m8.727s user 0m8.011s sys 0m0.479s bash-3.2$ wc *hs 355 1200 9779 All.hs 169 495 4559 Instances0.hs 211 758 5678 Instances.hs 735 2453 20016 total }}} I did residency measures too {{{ All.hs 109M Instances.hs 95M Instances0.hs 29M }}} Timings are longer with -O, but similarly additive. In the files you supplied, I replaced {{{ deriving instance Typeable1 DeprecDecl deriving instance Data a => Data (DeprecDecl a) }}} by {{{ deriving instance Typeable1 WarnDecl deriving instance Data a => Data (WarnDecl a) deriving instance Typeable WarningTxt deriving instance Data WarningTxt }}} which is, I suppose, because package `ghc` has changed. Otherwise they are just as you supplied. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 12:10:00 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 12:08:21 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.1bdf0fe120ebd45c3e28f5275de2e1d0@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by simonpj): I believe this bug is fixed now, with the new HEAD. I've changed the compilation of instances so that it's just as if you'd written separate definitions for each method, much as you have now done by hand. If you could test that claim, it'd be great. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 12:24:08 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 12:22:20 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.357d65d9cfde0dc3964cd6ec839819ef@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by maeder): Could you point me to a suitable snapshot distribution? The latest one from http://www.haskell.org/ghc/dist/current/dist/ seems to be `ghc-6.9.20080822-src.tar.bz2` Christian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 14:08:40 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 14:06:50 2008 Subject: [GHC] #2561: Using "ITstring !FastString" in Lexer.x goes wrong (internal error: stg_ap_v_ret) Message-ID: <044.9ac0e4e49ee8e155dd0628d5c362af04@localhost> #2561: Using "ITstring !FastString" in Lexer.x goes wrong (internal error: stg_ap_v_ret) -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- With this patch: {{{ hunk ./compiler/parser/Lexer.x 535 +#if __GLASGOW_HASKELL__ >= 609 + | ITstring !FastString +#else hunk ./compiler/parser/Lexer.x 539 +#endif }}} something goes wrong. The first sign, when validating, is that `timeout` is broken: {{{ timeout: internal error: stg_ap_v_ret (GHC version 6.9.20080902 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If you use the python timeout program instead then you find a few tests fail, e.g.: {{{ testsuite/tests/ghc-regress/codeGen/should_run$ '/home/ian/ghc/darcs/st2/ghc/stage2-inplace/ghc' -fforce-recomp -dcore- lint -dcmm-lint -Dx86_64_unknown_linux -dno-debug-output -o cg052 cg052.hs -O -fasm -funbox-strict-fields testsuite/tests/ghc-regress/codeGen/should_run$ ./cg052 ok cg052: internal error: stg_ap_v_ret (GHC version 6.9.20080902 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort ./cg052 }}} I'm not sure what's going on, but it seems to be repeatable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 15:46:41 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 15:44:50 2008 Subject: [GHC] #2562: GADTs: (.text+0xc6): undefined reference to `Main_IsEqual_con_info' Message-ID: <044.c55d6f10a10ea7337e4c3f5bffa457da@localhost> #2562: GADTs: (.text+0xc6): undefined reference to `Main_IsEqual_con_info' -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- With this module: {{{ {-# LANGUAGE ScopedTypeVariables, GADTs #-} import Unsafe.Coerce data IsEqual a b where IsEqual :: IsEqual a a contextsEqual :: cxt1 -> cxt2 -> IsEqual cxt1 cxt2 contextsEqual = unsafeCoerce IsEqual data Seq from to where Nil :: Seq here here foo :: forall from to . Seq from to foo = f undefined undefined where f :: from -> to -> Seq from to f x y = case contextsEqual x y of IsEqual -> Nil main :: IO () main = case foo :: Seq () () of Nil -> return () }}} I get: {{{ $ ghc --make z -fforce-recomp -O [1 of 1] Compiling Main ( z.hs, z.o ) Linking z ... z.o: In function `smk_info': (.text+0xc6): undefined reference to `Main_IsEqual_con_info' collect2: ld returned 1 exit status }}} with the HEAD and 6.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 17:18:50 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 17:16:59 2008 Subject: [GHC] #2562: GADTs: (.text+0xc6): undefined reference to `Main_IsEqual_con_info' In-Reply-To: <044.c55d6f10a10ea7337e4c3f5bffa457da@localhost> References: <044.c55d6f10a10ea7337e4c3f5bffa457da@localhost> Message-ID: <053.dc9124189d652272ee222cf796fa1088@localhost> #2562: GADTs: (.text+0xc6): undefined reference to `Main_IsEqual_con_info' ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): My compiler, compiled with -DDEBUG, gets an assert error. What do you expect? You're doing {{{ (unsafeCoerce IsEqual) undefined undefined }}} that is, applying a non-function as a function. Would you prefer a seg fault? Unsafe coerce is, as it says, unsafe. What would be the right behaviour? A type error? Presumably not, since you have consciously suppressed that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 17:43:41 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 17:41:50 2008 Subject: [GHC] #2562: GADTs: (.text+0xc6): undefined reference to `Main_IsEqual_con_info' In-Reply-To: <044.c55d6f10a10ea7337e4c3f5bffa457da@localhost> References: <044.c55d6f10a10ea7337e4c3f5bffa457da@localhost> Message-ID: <053.475c44324818e8204d593129c4628e89@localhost> #2562: GADTs: (.text+0xc6): undefined reference to `Main_IsEqual_con_info' ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Whoops, you're quite right! I meant to say {{{ contextsEqual _ _ = unsafeCoerce IsEqual }}} which works fine; sorry for the noise! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 17:45:53 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 17:44:04 2008 Subject: [GHC] #601: Replace GMP In-Reply-To: <047.118762464fe3464def09b9461b8cccc5@localhost> References: <047.118762464fe3464def09b9461b8cccc5@localhost> Message-ID: <056.4c020398998725c80af71da10b38f4be@localhost> #601: Replace GMP ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: normal | Resolution: None Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by JimCrayne): An interim approach that could be done is creating a binary compatible, minimal, drop in replacement for GMP. People who statically link could just implement enough functions to get their program working without linker errors... eventually we'd have all of them done. I attached some starting code as the file jmp.c (Credit to Joe Crayne for this code) The way I envision this approach is that the initial emphasis would be on just having something which works, getting it to be more efficient would come later. Note that this approach would mean that perhaps we can borrow test-suite code from libgmp and that almost no changes would be necessary to GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 3 21:05:32 2008 From: trac at galois.com (GHC) Date: Wed Sep 3 21:03:41 2008 Subject: [GHC] #2563: With -N4: "internal error: RELEASE_LOCK: I do not own this lock: Task.c 269" Message-ID: <044.a34da6c43bb4e28144648cb6864c37dc@localhost> #2563: With -N4: "internal error: RELEASE_LOCK: I do not own this lock: Task.c 269" -------------------------------+-------------------------------------------- Reporter: TomMD | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- The program crashes in various ways including double free (typical) and sigsegv (once when -N3). The error in the subject was seen once (gdb output attached for that run). compile: ghc -threaded -debug ex.hs --make -O2 -o ex run: ./ex.hs +RTS -NX -RTS file1 file2 file3 file4 where X >= 3. It might take 4 or 5 runs to crash. For -N4 it typically complains about a double free error, but I saw the nicer error message once. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 4 11:03:24 2008 From: trac at galois.com (GHC) Date: Thu Sep 4 11:01:31 2008 Subject: [GHC] #2564: ext-core docs Message-ID: <044.9c55487d60a050a3069bd0c8af562908@localhost> #2564: ext-core docs -----------------------------+---------------------------------------------- Reporter: igloo | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Make sure that ext-core docs are built and put in the bindist, and that the other docs point at the in-tree doc rather than the one on the web. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 4 13:12:28 2008 From: trac at galois.com (GHC) Date: Thu Sep 4 13:10:41 2008 Subject: [GHC] #2564: ext-core docs In-Reply-To: <044.9c55487d60a050a3069bd0c8af562908@localhost> References: <044.9c55487d60a050a3069bd0c8af562908@localhost> Message-ID: <053.e035508c3ea59b3807de4d1753ae9d9d@localhost> #2564: ext-core docs --------------------------+------------------------------------------------- Reporter: igloo | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by tim): * cc: chevalier@alum.wellesley.edu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 4 16:09:17 2008 From: trac at galois.com (GHC) Date: Thu Sep 4 16:07:36 2008 Subject: [GHC] #2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks In-Reply-To: <045.f644abcffe54149a52e1b357b6ba7b01@localhost> References: <045.f644abcffe54149a52e1b357b6ba7b01@localhost> Message-ID: <054.fc6c140decc897a344164301363b82b1@localhost> #2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks -----------------------------+---------------------------------------------- Reporter: maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: MacOS X | -----------------------------+---------------------------------------------- Comment (by kquick): With ghc-6.8.2, I get the following griping each time ghc --make has to do an update: Linking foo ... /usr/bin/ld: warning -F: directory name (/Users/kquick/Library/Frameworks) does not exist $ The link operation appears to complete successfully, so this isn't "broken", but it's annoying. Is it possible for the ghc operation to detect the presence of this directory and only supply the -F if it's actually present? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 5 03:15:47 2008 From: trac at galois.com (GHC) Date: Fri Sep 5 03:13:57 2008 Subject: [GHC] #2565: Windows binary snapshots not available Message-ID: <051.1976784c9715158e8d7a1287c8380508@localhost> #2565: Windows binary snapshots not available -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Looking at: http://www.haskell.org/ghc/dist/current/dist/ The latest Windows binary appears to be the 22nd of June, and thus is before things such as the Control.Exception changes, and will not work with the current version of Haddock. Is it possible to get an updated binary? From what I remember, these snapshots are also used for the Windows binary release, so might hold up the 6.10 released. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 5 10:00:08 2008 From: trac at galois.com (GHC) Date: Fri Sep 5 09:58:44 2008 Subject: [GHC] #1964: GHC.Prim In-Reply-To: <044.9207dad19026729963694adf6b204b9d@localhost> References: <044.9207dad19026729963694adf6b204b9d@localhost> Message-ID: <053.87231334c88913065e938d6e947f8b57@localhost> #1964: GHC.Prim ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed; we now have GHC.Prim docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 5 11:56:23 2008 From: trac at galois.com (GHC) Date: Fri Sep 5 11:54:32 2008 Subject: [GHC] #1886: GHC API should preserve and provide access to comments In-Reply-To: <044.eac6e4e9449b44410013b3e7df813e47@localhost> References: <044.eac6e4e9449b44410013b3e7df813e47@localhost> Message-ID: <053.b96a54e0314d79a38143104cd90b8546@localhost> #1886: GHC API should preserve and provide access to comments ---------------------------------------------------------------+------------ Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: GHC API, comments, program transformation, layout | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------------------------------------+------------ Comment (by Jedai): My proposal is to support access to a special kind of token stream including comments. As the tokens themselves aren't enough to get back to the source that produced them (some aesthetic details disappear), I also create a function to add source strings to the tokens in a stream and a function to show such a "rich" token stream. HaRe use the following model : get the AST and the token stream >>> modify AST &&& propagate changes to token stream >>> second (pretty print the token stream). While this model may not be as convenient as we could hope for, it works and the guts of this process could eventually become a package on Hackage, separate from HaRe. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 5 12:52:43 2008 From: trac at galois.com (GHC) Date: Fri Sep 5 12:50:48 2008 Subject: [GHC] #2566: "ghc -c foo.bar" silently does nothing Message-ID: <044.d5ec73495db3a97d116701dde7bbb4b2@localhost> #2566: "ghc -c foo.bar" silently does nothing ------------------------+--------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- `ghc -c foo.bar` silently does nothing. It thinks that `foo.bar` is an extra file to link, but `-c` means "do not link". Instead, it should give an error (or at the very least, a warning). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 5 17:36:48 2008 From: trac at galois.com (GHC) Date: Fri Sep 5 17:34:53 2008 Subject: [GHC] #2535: Bug fix for QuickCheck 1.1.0.0 In-Reply-To: <047.a94a8053354ba7fb4be42a9b053bccf3@localhost> References: <047.a94a8053354ba7fb4be42a9b053bccf3@localhost> Message-ID: <056.30e77d754916da765798a76e607c3f2b@localhost> #2535: Bug fix for QuickCheck 1.1.0.0 -------------------------------+-------------------------------------------- Reporter: patperry | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Comment (by patperry): There was a question about how the new version of variant works. An explanation was given here: http://www.haskell.org/pipermail/libraries/2008-August/010566.html There was also concern about whether or not the patch truly fixed Bug #2065. Specifically, where was some worry about arbitrary (Double -> Int) function producing complicated results for simple input. Those worries were quelled here: http://www.haskell.org/pipermail/libraries/2008-September/010600.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 6 03:31:03 2008 From: trac at galois.com (GHC) Date: Sat Sep 6 03:29:06 2008 Subject: [GHC] #2567: HEAD doesn't install the ghc package anymore Message-ID: <044.ecb8efd3cc5dfa4e996294800bd436de@localhost> #2567: HEAD doesn't install the ghc package anymore ------------------------+--------------------------------------------------- Reporter: Jedai | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- As of some times ago, the HEAD doesn't install the ghc package anymore when you do "make install", it compiles it fine but doesn't put ghc in the package.conf even as an hidden package. The inplace compiler still has access to it but the installed compiler don't have it in its package.conf. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 6 06:56:25 2008 From: trac at galois.com (GHC) Date: Sat Sep 6 06:54:27 2008 Subject: [GHC] #2567: HEAD doesn't install the ghc package anymore In-Reply-To: <044.ecb8efd3cc5dfa4e996294800bd436de@localhost> References: <044.ecb8efd3cc5dfa4e996294800bd436de@localhost> Message-ID: <053.fee1279e1be389e83fdbb25204b948b3@localhost> #2567: HEAD doesn't install the ghc package anymore --------------------------+------------------------------------------------- Reporter: Jedai | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 6 13:48:59 2008 From: trac at galois.com (GHC) Date: Sat Sep 6 13:46:59 2008 Subject: [GHC] #2568: hSetBuffering NoBuffering and getChar don't work properly on Windows Message-ID: <044.cddd57f564de0f359ce95c475998d627@localhost> #2568: hSetBuffering NoBuffering and getChar don't work properly on Windows -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Windows -------------------------+-------------------------------------------------- With this program: {{{ import System.IO main = do { hSetBuffering stdin NoBuffering; run } run = do { getChar; putStrLn "yes"; run } }}} if I type {{{ abcdef }}} then: On Linux and OS X I get the desired output: {{{ $ ./q ayes byes cyes yes dyes eyes fyes yes ^Cq: interrupted }}} In an MSYS window I get: {{{ $ ./q abc def }}} In a cygwin window or a cmd windows I get: {{{ $ ./q abc yes yes yes yes def yes yes yes yes }}} and the program doesn't die. SSHing into cygwin I get: {{{ $ ./q abc def }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 6 14:59:17 2008 From: trac at galois.com (GHC) Date: Sat Sep 6 14:57:16 2008 Subject: [GHC] #2535: Bug fix for QuickCheck 1.1.0.0 In-Reply-To: <047.a94a8053354ba7fb4be42a9b053bccf3@localhost> References: <047.a94a8053354ba7fb4be42a9b053bccf3@localhost> Message-ID: <056.699bbe70a901ba06737f4ab8a8399dd8@localhost> #2535: Bug fix for QuickCheck 1.1.0.0 -------------------------------+-------------------------------------------- Reporter: patperry | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Patch applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 6 15:57:34 2008 From: trac at galois.com (GHC) Date: Sat Sep 6 15:55:34 2008 Subject: [GHC] #2567: HEAD doesn't install the ghc package anymore In-Reply-To: <044.ecb8efd3cc5dfa4e996294800bd436de@localhost> References: <044.ecb8efd3cc5dfa4e996294800bd436de@localhost> Message-ID: <053.155b31a34faca0570c4892249604c22c@localhost> #2567: HEAD doesn't install the ghc package anymore --------------------------+------------------------------------------------- Reporter: Jedai | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed * milestone: => 6.10.1 Comment: Thanks for the report, now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 03:24:34 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 03:22:32 2008 Subject: [GHC] #2569: Inferred type not accepted by compiler Message-ID: <042.a6d02d63748210843219421fda4a2f33@localhost> #2569: Inferred type not accepted by compiler ------------------------+--------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- {{{ ghc --version: The Glorious Glasgow Haskell Compilation System, version 6.9.20080825 }}} A.hs: {{{ {-# LANGUAGE TypeFamilies #-} module A where data H a = A a | B a deriving Eq class PL p class PE a where type P a :: * instance PE [a] where type P [a] = H a instance PL (H a) foo :: PE a => [P a] -> [P a] -> (([P a], [P a]),([P a],[P a])) foo pa pb = ((pa, pa), (pb, pb)) -- bar :: (PE a) => [P a] -> [P a] -> Either ([P a], [P a]) [P a] bar pa pb = let _ = foo pa pb in case True of True -> Right pa False -> Left (pa, pb) }}} Load the above module into GHCi. {{{ *A> :t bar bar :: (PE a) => [P a] -> [P a] -> Either ([P a], [P a]) [P a] }}} However, if we uncomment bar's type signature (which is ''exactly'' the same as the one printed by GHCi), we get a type error: {{{ [1 of 1] Compiling A ( A.hs, interpreted ) A.hs:23:16: Couldn't match expected type `P a' against inferred type `P a1' Expected type: [P a] Inferred type: [P a1] In the first argument of `foo', namely `pa' In the expression: foo pa pb Failed, modules loaded: none. }}} I'm not all that familiar with type families, but I'm pretty sure that when GHCi prints a type, we ought to be able to specify that type and the module ought to compile... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 07:20:34 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 07:18:34 2008 Subject: [GHC] #2570: 2185 test segfaults rather than giving out of memory error Message-ID: <044.4bc60d0f42761c8cb89bb120ce68b513@localhost> #2570: 2185 test segfaults rather than giving out of memory error -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- We currently expect the 2185 test to fail with an out of memory error (#2185), but it is actually segfaulting (amd64/Linux): {{{ $ ./2185 +RTS -M16m -RTS ('A',4.0) ('B',4.0) ('C',[(0.0,0.0),(0.0,128.0),(0.0,256.0),(0.0,384.0),(128.0,0.0),(128.0,128.0),(128.0,256.0),(128.0,384.0),(256.0,0.0),(256.0,128.0),(256.0,256.0),(256.0,384.0),(384.0,0.0),(384.0,128.0),(384.0,256.0),(384.0,384.0)]) zsh: segmentation fault ./2185 +RTS -M16m -RTS }}} Without the `-M16m` flag it works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 07:53:07 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 07:51:03 2008 Subject: [GHC] #2571: ioref001 segfaults depending on how much stack space it has Message-ID: <044.be1f076de3b33330c413bedba41dbc09@localhost> #2571: ioref001 segfaults depending on how much stack space it has -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: ioref001 Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- The ioref001 test is segfaulting, depending on how much stack space you give it: {{{ $ '/home/ian/ghc/darcs/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore- lint -dcmm-lint -Dx86_64_unknown_linux -dno-debug-output -o ioref001 ioref001.hs -O -fasm +RTS -K32m -RTS $ ./ioref001 Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. $ ./ioref001 +RTS -K16m -RTS Stack space overflow: current size 16000000 bytes. Use `+RTS -Ksize' to increase it. zsh: segmentation fault ./ioref001 +RTS -K16m -RTS $ ./ioref001 +RTS -K32m -RTS done zsh: segmentation fault ./ioref001 +RTS -K32m -RTS $ ./ioref001 +RTS -K100m -RTS done }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 09:04:09 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 09:02:07 2008 Subject: [GHC] #2502: segfault with GHC.Handle.fdToHandle' In-Reply-To: <046.3af147e9b383729d4b3cbb7db169730e@localhost> References: <046.3af147e9b383729d4b3cbb7db169730e@localhost> Message-ID: <055.ad8e34ab895a4a126b1e664bf7c5ac88@localhost> #2502: segfault with GHC.Handle.fdToHandle' ---------------------+------------------------------------------------------ Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: FreeBSD | ---------------------+------------------------------------------------------ Comment (by obraun): I can't reproduce this on FreeBSD/i386. I am currently setting up a FreeBSD/amd64 machine to check it on that platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 09:13:10 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 09:11:08 2008 Subject: [GHC] #2572: scoped type variables: bad error message, and wrong semantics? Message-ID: <044.36805424bc32c8674e902d7438592f6d@localhost> #2572: scoped type variables: bad error message, and wrong semantics? ----------------------------------------+----------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: reify Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- With this module (a cut-down version of reify): {{{ {-# OPTIONS -fglasgow-exts #-} module Foo where type GTypeFun = forall a . a -> () gmapType :: Int -> GTypeFun gmapType _ (_ :: a) = undefined }}} GHC gives the rather perplexing error: {{{ Foo.hs:8:12: The scoped type variables `a' and `a' are bound to the same type (variable) Distinct scoped type variables must be distinct In the pattern: _ :: a In the definition of `gmapType': gmapType _ (_ :: a) = undefined }}} Having locations for the two `a`s would be useful. This module gives the same error: {{{ {-# OPTIONS -fglasgow-exts #-} module Foo where gmapType :: Int -> (forall a . a -> ()) gmapType _ (_ :: a) = undefined }}} GHC 6.8.2 accepts both modules. I don't think that the forall in the type signature should bring `a` into scope for the body, as it doesn't bring it into scope for the type signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 09:44:48 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 09:42:46 2008 Subject: [GHC] #2573: Illegal polymorphic or qualified type with generics Message-ID: <044.0f4890c6438f6c0a70aea58e74d30879@localhost> #2573: Illegal polymorphic or qualified type with generics ----------------------------------------+----------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: tcrun007 Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- A cut-down tcrun007: {{{ {-# LANGUAGE Generics, TypeOperators #-} import Data.Generics class Tag a where nCons :: a -> Int nCons {| a :*: b |} _ = 1 }}} is failing with: {{{ tcrun007.hs:5:0: Illegal polymorphic or qualified type: forall a b. a :*: b In the type pattern of a generic definition: forall a b. a :*: b In the class declaration for `Tag' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 10:02:16 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 10:00:12 2008 Subject: [GHC] #2574: internal error: ARR_WORDS object entered! (threaded2 / -N2) Message-ID: <044.cec87d57d46636e838fe24b769e665ef@localhost> #2574: internal error: ARR_WORDS object entered! (threaded2 / -N2) -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: 2317 Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- With the 2317 test: {{{ $ '/home/ian/ghc/darcs/ghc/ghc/stage2-inplace/ghc' -fforce-recomp -dcore- lint -dcmm-lint -Dx86_64_unknown_linux -dno-debug-output --make -o 2317 2317 -O -threaded $ ./2317 +RTS -N2 -RTS 100000 zsh: segmentation fault ./2317 +RTS -N2 -RTS $ ./2317 +RTS -N2 -RTS 100000 2317: internal error: ARR_WORDS object entered! (GHC version 6.9.20080906 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort ./2317 +RTS -N2 -RTS }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 10:28:20 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 10:26:17 2008 Subject: [GHC] #2445: better error message needed for missing package files In-Reply-To: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> References: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> Message-ID: <054.872f70999b06b19a14fc33bd9dc81fbf@localhost> #2445: better error message needed for missing package files ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by duncan): It would be great if `ghc-pkg check` would also stat all the files that we know we need for each package (ie the .hi files for all modules and the library .a files) and report any borked packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 11:13:11 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 11:11:09 2008 Subject: [GHC] #2575: shell script gotcha in boot Message-ID: <049.285f38c1ef1de70458d959845f9cbdf8@localhost> #2575: shell script gotcha in boot ---------------------------+------------------------------------------------ Reporter: pooryorick | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ---------------------------+------------------------------------------------ I use a build process which is sensitive to the exit code of "boot", assuming that everything went OK only if it returns 0. Because the last line of the script uses the && operator, the entire script can exit with a code other than zero if the last file checked does not exist. In my case, "validate" indeed did not exist, and the script failed. Solution: Replace the && with an if statement: {{{ if test -f $f; then chmod +x $f fi }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 11:15:47 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 11:13:44 2008 Subject: [GHC] #2532: Add Typeable instance to Data.Unique In-Reply-To: <045.cab33c7b39a6b1cefa6bbdc4f3dc0833@localhost> References: <045.cab33c7b39a6b1cefa6bbdc4f3dc0833@localhost> Message-ID: <054.110a2ad977e551111acb1330fd61f271@localhost> #2532: Add Typeable instance to Data.Unique ----------------------------+----------------------------------------------- Reporter: japple | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by japple): Ganesh Sittampalam pointed out that this allows Data.Unique to break when using hs-plugins, due to some hackery choices by hs-plugins and Data.Unique. ([http://www.haskell.org/pipermail/libraries/2008-September/010632.html Ganesh's message], [http://article.gmane.org/gmane.comp.lang.haskell.libraries/10019 mirror]) I'm trying to get more details. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 11:19:36 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 11:17:36 2008 Subject: [GHC] #2576: bio and retainer profiling segfaults Message-ID: <044.a90cb00250e6ac3fb6091f08144c5a9c@localhost> #2576: bio and retainer profiling segfaults --------------------------+------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Profiling | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: heapprof001 Architecture: Unknown | Os: Unknown --------------------------+------------------------------------------------- `heapprof001(prof_hc_hb,prof_hr)` is segfaulting. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 12:42:55 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 12:41:07 2008 Subject: [GHC] #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts In-Reply-To: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> References: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> Message-ID: <054.0e2af10ab0b85dec777f464622ed2665@localhost> #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts ----------------------------+----------------------------------------------- Reporter: japple | Owner: malcolm.wallace@cs.york.ac.uk Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by japple): * owner: => malcolm.wallace@cs.york.ac.uk Comment: Malcolm, can you push these changes? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 12:52:42 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 12:50:39 2008 Subject: [GHC] #2532: Add Typeable instance to Data.Unique In-Reply-To: <045.cab33c7b39a6b1cefa6bbdc4f3dc0833@localhost> References: <045.cab33c7b39a6b1cefa6bbdc4f3dc0833@localhost> Message-ID: <054.15c83999c2e1ba9ed74b5b13a6687437@localhost> #2532: Add Typeable instance to Data.Unique ----------------------------+----------------------------------------------- Reporter: japple | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by japple): After reading some of the cafe thread on this issue ("Subject: Top Level <-"), I'm afraid I don't have the time needed to come up with a thorough answer to whether or not this is dangerous. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 13:36:48 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 13:34:45 2008 Subject: [GHC] #2502: segfault with GHC.Handle.fdToHandle' In-Reply-To: <046.3af147e9b383729d4b3cbb7db169730e@localhost> References: <046.3af147e9b383729d4b3cbb7db169730e@localhost> Message-ID: <055.b7415f03951c218c65c6e9ecffa6a8fa@localhost> #2502: segfault with GHC.Handle.fdToHandle' ---------------------+------------------------------------------------------ Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: FreeBSD | ---------------------+------------------------------------------------------ Comment (by obraun): I can't reproduce this on FreeBSD/amd64, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 14:20:05 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 14:18:02 2008 Subject: [GHC] #2577: dependency on $HOME environment variable Message-ID: <049.1c68505ed79c23aa9f49e24b4f7b3a91@localhost> #2577: dependency on $HOME environment variable ---------------------------+------------------------------------------------ Reporter: pooryorick | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ---------------------------+------------------------------------------------ This is probably not a bug, per-se, but out of 161 packages of mostly core software packages and libraries built in a certain environment, only ghc errors because $HOME is not set: ../utils/ghc-pkg/ghc-pkg-inplace update - --force-files GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 15:34:39 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 15:32:35 2008 Subject: [GHC] #2502: segfault with GHC.Handle.fdToHandle' In-Reply-To: <046.3af147e9b383729d4b3cbb7db169730e@localhost> References: <046.3af147e9b383729d4b3cbb7db169730e@localhost> Message-ID: <055.f76fe0364768f6c8a595ea5213399e72@localhost> #2502: segfault with GHC.Handle.fdToHandle' ---------------------+------------------------------------------------------ Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: FreeBSD | ---------------------+------------------------------------------------------ Comment (by obraun): My previous comments are valid for FreeBSD 7.x. I was able to reproduce this on FreeBSD 6.3, which is a _legacy_ release. Unfortunately, I have not enough time at the moment to track this down. Anyway, since FreeBSD 6 is only a legacy release and will be EOL in the near future, we can probably ignore this bug for the next ghc release. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 18:09:11 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 18:07:07 2008 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X Message-ID: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> #2578: "ld: atom sorting error for ..." on OS X -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- I'm seeing `atom sorting error`s while building GHC on OS X, e.g.: {{{ Configuring ghc-bin-6.9... /Users/ian/ghc/darcs/val/libraries/cabal-bin /usr/bin/ghc /Users/ian/ghc/darcs/val/libraries/bootstrapping.conf build --distpref dist-stage2 Preprocessing executables for ghc-bin-6.9... Building ghc-bin-6.9... [1 of 1] Compiling Main ( Main.hs, dist-stage2/build/ghc/ghc- tmp/Main.o ) Linking dist-stage2/build/ghc/ghc ... ld: atom sorting error for _ghczm6zi9_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi9_LibFFI_Czuffizucif_closure_tbl in /Users/ian/ghc/darcs/val/compiler/dist- stage2/build/libHSghc-6.9.a(LibFFI.o) ld: atom sorting error for _ghczm6zi9_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi9_LibFFI_Czuffizucif_closure_tbl in /Users/ian/ghc/darcs/val/compiler/dist- stage2/build/libHSghc-6.9.a(LibFFI.o) }}} It doesn't seem to cause any problems, but it's a little worrying. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 7 18:10:10 2008 From: trac at galois.com (GHC) Date: Sun Sep 7 18:08:11 2008 Subject: [GHC] #2564: ext-core docs In-Reply-To: <044.9c55487d60a050a3069bd0c8af562908@localhost> References: <044.9c55487d60a050a3069bd0c8af562908@localhost> Message-ID: <053.a03812f7e73bc08aa742e91a051d1a4a@localhost> #2564: ext-core docs --------------------------+------------------------------------------------- Reporter: igloo | Owner: igloo Type: task | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 8 06:47:35 2008 From: trac at galois.com (GHC) Date: Mon Sep 8 06:45:30 2008 Subject: [GHC] #2429: error building full dll name to be loaded in ghci In-Reply-To: <042.4bf17899c73d8aa74b87acbd8588af1e@localhost> References: <042.4bf17899c73d8aa74b87acbd8588af1e@localhost> Message-ID: <051.34b7971f28f5422b738ef946a6ce3959@localhost> #2429: error building full dll name to be loaded in ghci ---------------------+------------------------------------------------------ Reporter: jvl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: dll | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I couldn't reproduce the reported bug (with HEAD), but I did improve the error messages. {{{ Wed Sep 3 11:49:51 GMT Daylight Time 2008 Simon Marlow * Windows: print an error message in addDLL Also, look for libXXX.dll in addition to XXX.dll (see #1883, this isn't really a proper fix, but it'll help in some cases). And I tidied up the error message for a DLL load failure, though it's still a bit of a mess because addDLL is supposed to return a (static) string with the error message, but this isn't possible on Windows. Shall I push this patch? (1/2) [ynWvpxdaqjk], or ? for help: Wed Sep 3 11:50:18 GMT Daylight Time 2008 Simon Marlow * sysErrorBelch: don't put an extra \n on Windows }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 8 06:48:23 2008 From: trac at galois.com (GHC) Date: Mon Sep 8 06:46:18 2008 Subject: [GHC] #1883: GHC can't find library using "short" name In-Reply-To: <045.76e5dee1da7bd3e6c3d26431d4641cce@localhost> References: <045.76e5dee1da7bd3e6c3d26431d4641cce@localhost> Message-ID: <054.986521f475b90f9827637def28d7a56b@localhost> #1883: GHC can't find library using "short" name ----------------------------------+----------------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: link library windows | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------------+----------------------------------------- Comment (by simonmar): This is not a complete fix, but I made the linker look for "libXXX.dll" in addition to "XXX.dll". {{{ Wed Sep 3 11:49:51 GMT Daylight Time 2008 Simon Marlow * Windows: print an error message in addDLL Also, look for libXXX.dll in addition to XXX.dll (see #1883, this isn't really a proper fix, but it'll help in some cases). And I tidied up the error message for a DLL load failure, though it's still a bit of a mess because addDLL is supposed to return a (static) string with the error message, but this isn't possible on Windows. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 8 10:25:33 2008 From: trac at galois.com (GHC) Date: Mon Sep 8 10:23:29 2008 Subject: [GHC] #2574: internal error: ARR_WORDS object entered! (threaded2 / -N2) In-Reply-To: <044.cec87d57d46636e838fe24b769e665ef@localhost> References: <044.cec87d57d46636e838fe24b769e665ef@localhost> Message-ID: <053.8a0efe73ebe8879b5430bb03a41fcdb7@localhost> #2574: internal error: ARR_WORDS object entered! (threaded2 / -N2) ----------------------------+----------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: 2317 | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: normal => high * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 8 11:09:23 2008 From: trac at galois.com (GHC) Date: Mon Sep 8 11:07:23 2008 Subject: [GHC] #1897: Type families: type signature rejected In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.91cf931919e2eba7e52ed9ab027ff444@localhost> #1897: Type families: type signature rejected -------------------------------------+-------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by simonpj): * priority: low => normal Comment: See also #2157 and #2569. And Ganesh's email http://www.mail-archive.com /haskell-cafe@haskell.org/msg39593.html We're now convinced that * There is really no good way to check the type of functions like `isValid` * The right thing to do is to reject the type as ambiguous, whether it is inferred or checked. So the program would be rejected either way. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 8 11:10:21 2008 From: trac at galois.com (GHC) Date: Mon Sep 8 11:08:15 2008 Subject: [GHC] #2569: Inferred type not accepted by compiler In-Reply-To: <042.a6d02d63748210843219421fda4a2f33@localhost> References: <042.a6d02d63748210843219421fda4a2f33@localhost> Message-ID: <051.b1f2bef1ac52d074d00d5a0cbb8d60e9@localhost> #2569: Inferred type not accepted by compiler -------------------------------------+-------------------------------------- Reporter: ajd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Yes, I'm afraid this is a now-celebrated bug. See #1897 and associated email. The right thing, I think, is to reject the the program, whether or not you have a signature. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 8 12:28:37 2008 From: trac at galois.com (GHC) Date: Mon Sep 8 12:26:45 2008 Subject: [GHC] #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts In-Reply-To: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> References: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> Message-ID: <054.b31daa5b7383731780c2fc38016df42f@localhost> #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts ----------------------------+----------------------------------------------- Reporter: japple | Owner: Igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by malcolm.wallace@cs.york.ac.uk): * owner: malcolm.wallace@cs.york.ac.uk => Igloo Comment: Igloo, I have applied the final patch to the haskell-report repository, but am guessing that you might prefer to validate the changes to base and testsuite before pushing them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 8 18:32:01 2008 From: trac at galois.com (GHC) Date: Mon Sep 8 18:29:58 2008 Subject: [GHC] #2579: export Data.Map.toDescList Message-ID: <047.fc7adbd301cb8dd162625853d292b43f@localhost> #2579: export Data.Map.toDescList -------------------------+-------------------------------------------------- Reporter: elaforge | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- It's even implemented, but not exported. Without this, there's apparently no way to iterate over a map from high to low, since foldl is also not exported. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 8 18:33:36 2008 From: trac at galois.com (GHC) Date: Mon Sep 8 18:31:30 2008 Subject: [GHC] #2580: export Data.Map.toDescList Message-ID: <047.7323273a4c97569c35461c7770e620db@localhost> #2580: export Data.Map.toDescList -------------------------+-------------------------------------------------- Reporter: elaforge | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- It's even implemented, but not exported. Without this, there's apparently no way to iterate over a map from high to low, since foldl is also not exported. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 8 18:35:17 2008 From: trac at galois.com (GHC) Date: Mon Sep 8 18:33:10 2008 Subject: [GHC] #2579: export Data.Map.toDescList In-Reply-To: <047.fc7adbd301cb8dd162625853d292b43f@localhost> References: <047.fc7adbd301cb8dd162625853d292b43f@localhost> Message-ID: <056.9f047e0fdfb9d4bfea7f304d3c5fc88a@localhost> #2579: export Data.Map.toDescList -------------------------------+-------------------------------------------- Reporter: elaforge | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Changes (by elaforge): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 9 10:54:50 2008 From: trac at galois.com (GHC) Date: Tue Sep 9 10:52:47 2008 Subject: [GHC] #2570: 2185 test segfaults rather than giving out of memory error In-Reply-To: <044.4bc60d0f42761c8cb89bb120ce68b513@localhost> References: <044.4bc60d0f42761c8cb89bb120ce68b513@localhost> Message-ID: <053.c1736fed17c4cc80fcf6084629b5ceb7@localhost> #2570: 2185 test segfaults rather than giving out of memory error ----------------------------+----------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 9 11:48:58 2008 From: trac at galois.com (GHC) Date: Tue Sep 9 11:46:55 2008 Subject: [GHC] #2574: internal error: ARR_WORDS object entered! (threaded2 / -N2) In-Reply-To: <044.cec87d57d46636e838fe24b769e665ef@localhost> References: <044.cec87d57d46636e838fe24b769e665ef@localhost> Message-ID: <053.d99631d509d9328c49f0cbef7da8f470@localhost> #2574: internal error: ARR_WORDS object entered! (threaded2 / -N2) ----------------------------+----------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: 2317 | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Tue Sep 9 06:32:23 PDT 2008 Simon Marlow * Fix race condition in wakeupThreadOnCapability() (#2574) }}} This one took me more than half a day to find. Phew. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 9 11:51:07 2008 From: trac at galois.com (GHC) Date: Tue Sep 9 11:49:25 2008 Subject: [GHC] #2570: 2185 test segfaults rather than giving out of memory error In-Reply-To: <044.4bc60d0f42761c8cb89bb120ce68b513@localhost> References: <044.4bc60d0f42761c8cb89bb120ce68b513@localhost> Message-ID: <053.d44243504849a913fab9fb3870c2b8f3@localhost> #2570: 2185 test segfaults rather than giving out of memory error ----------------------------+----------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Tue Sep 9 06:22:34 PDT 2008 Simon Marlow * Fix compacting GC bug: don't forget to thread the blackhole_queue Tue Sep 9 06:52:51 PDT 2008 Simon Marlow * Separate pruning from marking of spark pools Fixes crash when using compacting GC in parallel programs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 9 11:55:11 2008 From: trac at galois.com (GHC) Date: Tue Sep 9 11:53:10 2008 Subject: [GHC] #2359: Data.IntMap update{Min, Max}WithKey corrupts data structure In-Reply-To: <042.245aba7cabc38180cbe3d307aebd0f3e@localhost> References: <042.245aba7cabc38180cbe3d307aebd0f3e@localhost> Message-ID: <051.4e4f4f47e75a6ec9850dad21a6af4976@localhost> #2359: Data.IntMap update{Min,Max}WithKey corrupts data structure ----------------------------+----------------------------------------------- Reporter: nwf | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Patch applied, thanks! {{{ Thu Jul 3 22:43:50 PDT 2008 sedillard@gmail.com * Fixed typo in updateMinWithKey / updateMaxWithKey }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 04:32:40 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 04:30:29 2008 Subject: [GHC] #2581: Record selectors not being inlined Message-ID: <046.febf14e36d8a0c342a4f5f4856c07ce4@localhost> #2581: Record selectors not being inlined -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: simonpj Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- Bryan O'Sullivan write: This comes from the bloomfilter package on Hackage. {{{ type Hash = Word32 data MBloom s a = MB { hashMB :: {-# UNPACK #-} !(a -> [Hash]) , shiftMB :: {-# UNPACK #-} !Int , maskMB :: {-# UNPACK #-} !Int , bitArrayMB :: {-# UNPACK #-} !(STUArray s Int Hash) } insertMB :: MBloom s a -> a -> ST s () {-# SPECIALIZE insertMB :: MBloom s SB.ByteString -> SB.ByteString -> ST s () #-} insertMB mb elt = do let mu = bitArrayMB mb forM_ (hashesM mb elt) $ \(word :* bit) -> do old <- unsafeRead mu word unsafeWrite mu word (old .|. (1 `shiftL` bit)) }}} If I look at the Core generated for any version of `insertMB`, specialised or not, I see the following. Note the non-inlined uses of `maskMB` and `bitArrayMB`. (I export `bitArrayMB` from the module, but not `maskMB`.) {{{ Data.BloomFilter.insertMB = \ (@ s_a2ta) (@ a_a2tb) (mb_X2n2 :: Data.BloomFilter.MBloom s_a2ta a_a2tb) (elt_X2n4 :: a_a2tb) -> __letrec { a2_s3g9 :: [Word32] -> State# s_a2ta -> (# State# s_a2ta, () #) [Arity 2 a2_s3g9 = \ (ds_a2S9 :: [Word32]) (eta_s37Y :: State# s_a2ta) -> case ds_a2S9 of wild_a2Sa { [] -> (# eta_s37Y, () #); : y_a2Se ys_a2Sf -> case y_a2Se of wild1_a2Io { W32# x#_a2Iq -> case Data.BloomFilter.maskMB @ s_a2ta @ a_a2tb mb_X2n2 of wild11_a2T0 { I# y#_a2T2 -> case Data.BloomFilter.bitArrayMB @ s_a2ta @ a_a2tb mb_X2n2 of wild2_a2P0 { Data.Array.Base.STUArray ds2_a2P2 ds3_a2P3 ds4_a2P4 marr#_a2P5 -> [......] }}} If I switch to non-record syntax, the inliner does the right thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 05:00:56 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 04:58:45 2008 Subject: [GHC] #2572: scoped type variables: bad error message, and wrong semantics? In-Reply-To: <044.36805424bc32c8674e902d7438592f6d@localhost> References: <044.36805424bc32c8674e902d7438592f6d@localhost> Message-ID: <053.a3bb0c76923f5104c363720de809fa34@localhost> #2572: scoped type variables: bad error message, and wrong semantics? ---------------------------------------------------+------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: reify, typecheck/should_compile/T2572 | Architecture: Unknown Os: Unknown | ---------------------------------------------------+------------------------ Changes (by simonpj): * testcase: reify => reify, typecheck/should_compile/T2572 * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Wed Sep 10 01:51:21 PDT 2008 simonpj@microsoft.com * More refactoring of instance declarations (fixes Trac #2572) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 05:02:14 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 05:00:03 2008 Subject: [GHC] #2573: Illegal polymorphic or qualified type with generics In-Reply-To: <044.0f4890c6438f6c0a70aea58e74d30879@localhost> References: <044.0f4890c6438f6c0a70aea58e74d30879@localhost> Message-ID: <053.00cdea9c4a602c5981d92b819e2b6de3@localhost> #2573: Illegal polymorphic or qualified type with generics ------------------------------------------------------+--------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tcrun007, typecheck/should_compile/T2573 | Architecture: Unknown Os: Unknown | ------------------------------------------------------+--------------------- Changes (by simonpj): * testcase: tcrun007 => tcrun007, typecheck/should_compile/T2573 * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Wed Sep 10 01:23:13 PDT 2008 simonpj@microsoft.com * Fix Trac #2573; and explanatory comment }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 05:12:29 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 05:10:19 2008 Subject: [GHC] #2568: hSetBuffering NoBuffering and getChar don't work properly on Windows In-Reply-To: <044.cddd57f564de0f359ce95c475998d627@localhost> References: <044.cddd57f564de0f359ce95c475998d627@localhost> Message-ID: <053.4890e26852055aaf97622d094a44bda3@localhost> #2568: hSetBuffering NoBuffering and getChar don't work properly on Windows ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: We already have a ticket for this: #2189 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 05:30:39 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 05:28:30 2008 Subject: [GHC] #2577: dependency on $HOME environment variable In-Reply-To: <049.1c68505ed79c23aa9f49e24b4f7b3a91@localhost> References: <049.1c68505ed79c23aa9f49e24b4f7b3a91@localhost> Message-ID: <058.b515afe1b70610c96fa809ef7fc64bbf@localhost> #2577: dependency on $HOME environment variable ------------------------+--------------------------------------------------- Reporter: pooryorick | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------+--------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Already fixed, but thanks for the report! (#2492) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 05:42:30 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 05:40:19 2008 Subject: [GHC] #2517: remove 'pure' method from Arrow class In-Reply-To: <043.bffe8bdb0940ee07d4e323e480390725@localhost> References: <043.bffe8bdb0940ee07d4e323e480390725@localhost> Message-ID: <052.eec2b80a9f6d9182e724fd9510e9a5ea@localhost> #2517: remove 'pure' method from Arrow class ----------------------------+----------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by conal): Does anyone have a way to make code work before and after the removal of pure from Arrow? I import Arrow with "hiding (pure)" quite a lot, which is now required up to recent Arrow versions and forbidden after. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 05:50:55 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 05:48:44 2008 Subject: [GHC] #2517: remove 'pure' method from Arrow class In-Reply-To: <043.bffe8bdb0940ee07d4e323e480390725@localhost> References: <043.bffe8bdb0940ee07d4e323e480390725@localhost> Message-ID: <052.c1709ef2f697367b8193b60e21df9d5f@localhost> #2517: remove 'pure' method from Arrow class ----------------------------+----------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by ross): Replying to [comment:3 conal]: > Does anyone have a way to make code work before and after the removal of pure from Arrow? I import Arrow with "hiding (pure)" quite a lot, which is now required up to recent Arrow versions and forbidden after. I suppose you don't want to hear about cpp. You could explicitly import all the stuff from Control.Arrow that you need, or qualify Control.Applicative.pure. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 07:02:41 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 07:00:32 2008 Subject: [GHC] #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.c26a746aca181629787a129ef549c3b7@localhost> #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP --------------------------------------------+------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------------------------+------------------------------- Comment (by igloo): See also #2568. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 07:22:50 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 07:20:37 2008 Subject: [GHC] #2582: We need to provide runhaskell Message-ID: <044.bc0e3a1ac868de2418ccb4b946617a88@localhost> #2582: We need to provide runhaskell -----------------------------+---------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- We need to provide runhaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 07:46:18 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 07:44:05 2008 Subject: [GHC] #2581: Record selectors not being inlined In-Reply-To: <046.febf14e36d8a0c342a4f5f4856c07ce4@localhost> References: <046.febf14e36d8a0c342a4f5f4856c07ce4@localhost> Message-ID: <055.c2af53009ba214a8522ad2a25e925e9a@localhost> #2581: Record selectors not being inlined --------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: run-time performance bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: eyeball/records1 | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => eyeball/records1 * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Wed Sep 10 09:30:14 BST 2008 simonpj@microsoft.com * Fix Trac #2581: inlining of record selectors }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 10:37:08 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 10:35:09 2008 Subject: [GHC] #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts In-Reply-To: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> References: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> Message-ID: <054.cfe27aeb7b9c0b63793b828d4104a55d@localhost> #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts ----------------------------+----------------------------------------------- Reporter: japple | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: Igloo => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 11:36:31 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 11:34:31 2008 Subject: [GHC] #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts In-Reply-To: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> References: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> Message-ID: <054.c2d23c6015214ba002b2a6349f86c875@localhost> #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts ----------------------------+----------------------------------------------- Reporter: japple | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've applied the patches, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 11:44:13 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 11:42:01 2008 Subject: [GHC] #344: arrow notation: incorrect scope of existential dictionaries In-Reply-To: <045.6fa4f20d0985206ecf8719537b5ca060@localhost> References: <045.6fa4f20d0985206ecf8719537b5ca060@localhost> Message-ID: <054.59bfd7b68bc380ac3f70a4f57d36788b@localhost> #344: arrow notation: incorrect scope of existential dictionaries -------------------------------------+-------------------------------------- Reporter: nobody | Owner: ross Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.4 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonpj): Ross says: This will be a hard one, because it needs an intimate understanding of both the type checker and the arrow desugarer. Certainly not before the 19th (Sept 08). Fair enough. If you could get to it before 6.10.2 that would be great. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 10 17:17:57 2008 From: trac at galois.com (GHC) Date: Wed Sep 10 17:15:45 2008 Subject: [GHC] #2583: printf %s is not lazy enough Message-ID: <045.1bc664825025215dda23751e2d4d0e40@localhost> #2583: printf %s is not lazy enough ------------------------+--------------------------------------------------- Reporter: olsner | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Taking a fixpoint of printf {{{fix (printf "a%s") :: String}}}, or printf'ing an infinite string {{{printf "%s" (repeat ' ') :: String}}} either fails with stack overflow or diverges. The culprit is in this code: {{{ fmt cs us = let (width, prec, ladj, zero, plus, cs', us') = getSpecs False False False cs us adjust (pre, str) = let lstr = length str lpre = length pre fill = if lstr+lpre < width then take (width-(lstr+lpre)) (repeat (if zero then '0' else ' ')) else "" in if ladj then pre ++ str ++ fill else if zero then pre ++ fill ++ str else fill ++ pre ++ str }}} If width == 0, then no filling should be done, but the code is still forcing the evaluation of lstr and lpre (which in the case of an infinite str does not ever complete). A simple fix is to check that width is larger than zero before trying to test width against lstr and lpre, like this: {{{ fill = if width > 0 && lstr+lpre < width then {-etc-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 00:49:48 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 00:47:34 2008 Subject: [GHC] #2580: export Data.Map.toDescList In-Reply-To: <047.7323273a4c97569c35461c7770e620db@localhost> References: <047.7323273a4c97569c35461c7770e620db@localhost> Message-ID: <056.9846246879f44935f7ca2cb1c1434e23@localhost> #2580: export Data.Map.toDescList -------------------------------+-------------------------------------------- Reporter: elaforge | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Comment (by elaforge): Replacing patch with one that actually uncomments foldl so toDescList works, and exports foldl as foldlWithKey. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 05:33:26 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 05:31:17 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.47325c6b467deb6470aead37353fae37@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by maeder): using atc.2.tgz the object code size for ghc-6.9.20080910-x86_64-unknown- linux is as follows: {{{ 16K ATC2.hi 16K ATC2.hs 324K ATC2.o 8,0K ATC3.hi 4,0K ATC3.hs 8,0K ATC3.o 248K ATC.hi 88K ATC.hs 1,2M ATC.o }}} compared with our x64 ghc-6.8.3 installation (only consider ATC2.o!) that is a significant improvement. {{{ 16K ATC2.hi 16K ATC2.hs 9,2M ATC2.o 12M ATC3 12K ATC3.hi 4,0K ATC3.hs 8,0K ATC3.o 504K ATC.hi 88K ATC.hs 2,2M ATC.o }}} Linking with ghc-6.9.20080910 did not work (and I also got more warnings) {{{ ... WARNING: file simplCore/SimplCore.lhs line 501 Simplifier still going after 4 iterations; bailing out. Size = 1248 ... [108 of 110] Compiling ATC ( ATC.hs, ATC.o ) WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6yT} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6yT} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6yT} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6yT} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v s6zB} [lid] 0 0 [L, S, L] [109 of 110] Compiling ATC2 ( ATC2.hs, ATC2.o ) ATC2.hs:13:15: Warning: Imported from `HsName' but not used: data constructor `UnQual' WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v X6J6} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v X6J6} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v X6Ja} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v X6Ja} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v X6Ko} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v X6Ko} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v X6Kd} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v X6Kd} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v X6L1} [lid] 0 0 [L, S, L] WARNING: file simplCore/SimplUtils.lhs line 386 More demands than arity a9{v X6L1} [lid] 0 0 [L, S, L] [110 of 110] Compiling Main ( ATC3.hs, ATC3.o ) ATC3.hs:2:0: Warning: Module `ATC2' is imported, but nothing from it is used, except perhaps instances visible in `ATC2' To suppress this warning, use: import ATC2() Linking ATC3 ... /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse- linux/bin/ld: cannot find -lffi collect2: ld returned 1 exit status make: *** [all] Fehler 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 06:42:05 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 06:39:51 2008 Subject: [GHC] #2576: bio and retainer profiling segfaults In-Reply-To: <044.a90cb00250e6ac3fb6091f08144c5a9c@localhost> References: <044.a90cb00250e6ac3fb6091f08144c5a9c@localhost> Message-ID: <053.46460990a97e2a0f89780cffac99069a@localhost> #2576: bio and retainer profiling segfaults -------------------------+-------------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Profiling | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: heapprof001 | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * priority: normal => high * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 06:42:31 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 06:40:16 2008 Subject: [GHC] #2571: ioref001 segfaults depending on how much stack space it has In-Reply-To: <044.be1f076de3b33330c413bedba41dbc09@localhost> References: <044.be1f076de3b33330c413bedba41dbc09@localhost> Message-ID: <053.4341a5f6df10a468c94eeaf91481b4ce@localhost> #2571: ioref001 segfaults depending on how much stack space it has ----------------------------+----------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ioref001 | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: normal => high * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 06:45:47 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 06:43:33 2008 Subject: [GHC] #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. In-Reply-To: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> References: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> Message-ID: <052.d30e16a170a3af665343afff04413412@localhost> #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. ----------------------------+----------------------------------------------- Reporter: sclv | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * priority: normal => high * owner: => simonmar Comment: prioritising crashes -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 07:57:12 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 07:55:03 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.fedb9786b0661078eafceeaa4a7d0664@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by maeder): just for the record I include the sizes for our oldest x64 ghc-6.6.1 installation that again show that they are particularly bad for ghc-6.8.3 {{{ 12K ATC2.hi 16K ATC2.hs 3,5M ATC2.o 8,0M ATC3 8,0K ATC3.hi 4,0K ATC3.hs 4,0K ATC3.o 340K ATC.hi 88K ATC.hs 1,8M ATC.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 08:00:06 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 07:57:52 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.aeccaa67ae5bb1796fb2bf2fc2f16de5@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by maeder): Sorry, my previous comment is wrong. The above ghc-6.6.1 is a 32bit installation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 11:27:30 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 11:25:22 2008 Subject: [GHC] #2584: Pretty printing of types with HsDocTy goes wrong Message-ID: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> #2584: Pretty printing of types with HsDocTy goes wrong -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: major Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Pretty printing of type signatures containing HsDocTy goes wrong in HEAD. This manifests itself as serious bugs in both Haddock and Hoogle. Because the bug causes Haddock generated documentation to be wrong, I've marked the severity as major. Take the following file: {{{ {-# LANGUAGE FlexibleInstances #-} import GHC import SrcLoc import Outputable main = do putStrLn $ out $ HsFunTy fun fun putStrLn $ out $ HsFunTy (doc fun) fun reL = L undefined out x = showSDoc $ ppr x fun = reL $ HsFunTy (reL $ HsTyVar "a") (reL $ HsTyVar "b") doc = reL . flip HsDocTy undefined instance OutputableBndr [Char] where pprBndr _ x = text x }}} The output is: {{{ C:\Neil>runghc "-package ghc" test2.hs ([a] -> [b]) -> [a] -> [b] [a] -> [b] -> [a] -> [b] }}} Note that the first line (correctly) brackets the type signature, but that the second (incorrectly) omits the brackets. I suggest a change to the pretty printer to ignore HsTyDoc when determining where to insert brackets - or even removing the pretty printing of HsTyDoc entirely. -- Neil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 11:29:01 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 11:26:52 2008 Subject: [GHC] #2584: Pretty printing of types with HsDocTy goes wrong In-Reply-To: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> References: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> Message-ID: <060.66b87b0b7f5bab215feb7d55cb37d870@localhost> #2584: Pretty printing of types with HsDocTy goes wrong -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Comment (by NeilMitchell): This bug can be tickled from haddock with the file: {{{ module Test where unmap :: (a -> b) -- ^comment -> a unmap f = undefined }}} In the generated documentation all brackets are missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 13:15:32 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 13:13:25 2008 Subject: [GHC] #2584: Pretty printing of types with HsDocTy goes wrong In-Reply-To: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> References: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> Message-ID: <060.dce75dd35389868f1402394975824a83@localhost> #2584: Pretty printing of types with HsDocTy goes wrong -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: waern Type: bug | Status: assigned Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Changes (by waern): * status: new => assigned * owner: => waern -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 18:10:10 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 18:07:53 2008 Subject: [GHC] #2585: New versions of windres fail with "windres: CreateProcess (null): No error" Message-ID: <044.25b69fd7b594ae443d31576c538df3be@localhost> #2585: New versions of windres fail with "windres: CreateProcess (null): No error" -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Initially reported here: http://www.haskell.org/pipermail/cvs-ghc/2008-September/044944.html This version of windres: {{{ windres.exe -V GNU windres 2.17.50 20060824 }}} fails with: {{{ Linking dist\build\haddock\haddock.exe ... *** Windres: C:\ghc\ghc-6.9.20080905\bin/windres --preprocessor="C:\ghc\ghc-6.9.20080905\gcc" "-BC:\ghc\ghc-6.9.20080905\gcc-lib/" "-E" "-xc" "-DRC_INVOKED" --use-temp-file --input=C:\DOCUME~1\nmitche6\LOCALS~1\Temp\/ghc704_0/ghc704_0.rc --output=C:\DOC UME~1\nmitche6\LOCALS~1\Temp\/ghc704_0/ghc704_0.o --output-format=coff C:\ghc\ghc-6.9.20080905\bin/windres: CreateProcess (null): No error }}} `GNU windres 2.15.91 20040904` works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 11 20:09:49 2008 From: trac at galois.com (GHC) Date: Thu Sep 11 20:07:32 2008 Subject: [GHC] #2586: ghc segfaults when compiling bytestring001 Message-ID: <044.049be6675b7f11d36b94412f36ec028d@localhost> #2586: ghc segfaults when compiling bytestring001 -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: bytestring001 Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- With the `bytestring001` test in the testsuite: {{{ $ ls bytestring001.* bytestring001.hs bytestring001.stdout % /home/ian/ghc/darcs/full/ghc/stage2-inplace/ghc -fforce-recomp -o bytestring001 bytestring001.hs -O -fasm -package bytestring -package QuickCheck /home/ian/ghc/darcs/full/ghc/stage2-inplace/ghc: line 2: 22336 Segmentation fault /home/ian/ghc/darcs/full/ghc/stage2-inplace/libexec/ghc -B/home/ian/ghc/darcs/full/inplace-datadir/. -dynload wrapped ${1+"$@"} }}} That's with the threaded RTS. threaded-debug also segfaults. debug-only gets an Illegal instruction. "+RTS -DS" doesn't spot any problems. Running the debug-only GHC in gdb, I get a segfault in stg_sel_ret_0_upd_info. Doing so again with "+RTS -DS" I got: {{{ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 139962880329440 (LWP 16207)] 0x000000000132a819 in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=12297829382473034410) at ../includes/Storage.h:598 598 return info->type != INVALID_OBJECT && info->type < N_CLOSURE_TYPES; (gdb) p info $1 = (StgInfoTable *) 0xaaaaaaaaaaaaaa9a (gdb) p &info $2 = (StgInfoTable **) 0x7fffadd7abb8 (gdb) p4 0x7fffadd7abb0 0x7fffadd7abc8: 0x132a7e8 0x7fffadd7abc0: 0x7fffadd7abe0 0x7fffadd7abb8: 0xaaaaaaaaaaaaaa9a 0x7fffadd7abb0: 0x7fffadd7ac00 }}} so it looks like some unaligned writing has gone on at some point. The above is all amd64/Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 03:02:20 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 03:00:09 2008 Subject: [GHC] #2585: New versions of windres fail with "windres: CreateProcess (null): No error" In-Reply-To: <044.25b69fd7b594ae443d31576c538df3be@localhost> References: <044.25b69fd7b594ae443d31576c538df3be@localhost> Message-ID: <053.d6ffe90fb190c96c6ef971329b6a1b59@localhost> #2585: New versions of windres fail with "windres: CreateProcess (null): No error" ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by NeilMitchell): * cc: neil.mitchell.2@credit-suisse.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 05:22:41 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 05:20:23 2008 Subject: [GHC] #2587: Optimiser bug with extistentials and GADT's Message-ID: <051.b3070f4c96d88d63d3d2b2aa409dea4e@localhost> #2587: Optimiser bug with extistentials and GADT's ----------------------------------------------------------------------------------------+ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: neil.mitchell.2@credit-suisse.com, ganesh.sittampalam@credit-suisse.com | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------------------------------------------------------+ Given the program: {{{ {-# LANGUAGE GADTs, ExistentialQuantification #-} module GadtBug(bug) where data Existential = forall a . Existential (Gadt a) data Gadt a where Value :: Gadt Double bug = [ match undefined | ps <- undefined, _ <- ps ] where match (Existential _) = undefined match (Existential _) = undefined }}} Using GHC Head from yesterday, compiling without optimisations I get: {{{ C:\Neil>ghc --make GadtBug.hs [1 of 1] Compiling GadtBug ( GadtBug.hs, GadtBug.o ) GadtBug.hs:11:8: Warning: Pattern match(es) are overlapped In the definition of `match': match (Existential _) = ... }}} With optimisations (-O or -O2) I get: {{{ C:\Neil\paradise-bug-csdg\alone>ghc --make GadtBug.hs -O [1 of 1] Compiling GadtBug ( GadtBug.hs, GadtBug.o ) GadtBug.hs:11:8: Warning: Pattern match(es) are overlapped In the definition of `match': match (Existential _) = ... ghc: panic! (the 'impossible' happened) (GHC version 6.9.20080905 for i386-unknown-mingw32): idInfo a{tv ag4} [sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Neil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 06:05:32 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 06:03:15 2008 Subject: [GHC] #2586: ghc segfaults when compiling bytestring001 In-Reply-To: <044.049be6675b7f11d36b94412f36ec028d@localhost> References: <044.049be6675b7f11d36b94412f36ec028d@localhost> Message-ID: <053.aa01727b2f28eb2fc7a1eed218fa0104@localhost> #2586: ghc segfaults when compiling bytestring001 ---------------------------+------------------------------------------------ Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: bytestring001 | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 06:42:16 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 06:39:59 2008 Subject: [GHC] #2588: Missed suggestion with context on foralls Message-ID: <051.f82176fc0c07b1750e90df780f097cc7@localhost> #2588: Missed suggestion with context on foralls -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Given the program: {{{ module Test where test :: forall a . a -> a test = id }}} I get the nice and helpful error message: {{{ Test.hs:3:17: Illegal operator `.' in type `forall a . (a -> a)' Perhaps you intended to use -XRankNTypes or similar flag to enable explicit-forall syntax: forall . }}} [I personally usually want ScopedTypeVariables rather than RankNTypes, but its still a very useful hint at where to look] However, trying the program: {{{ module Test where test :: forall a . Eq a => a -> a test = id }}} Gives: {{{ Test.hs:3:24: parse error on input `=>' }}} I think it would be helpful to give the same suggestion as above. -- Neil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 06:44:31 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 06:42:14 2008 Subject: [GHC] #2502: segfault with GHC.Handle.fdToHandle' In-Reply-To: <046.3af147e9b383729d4b3cbb7db169730e@localhost> References: <046.3af147e9b383729d4b3cbb7db169730e@localhost> Message-ID: <055.4caf7c44805d1b2cc8f9f02dd0581721@localhost> #2502: segfault with GHC.Handle.fdToHandle' ---------------------+------------------------------------------------------ Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: FreeBSD | ---------------------+------------------------------------------------------ Changes (by simonmar): * milestone: 6.10.1 => 6.10 branch Comment: Moving it out of the 6.10.1 milestone, as per Olli's comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 06:52:08 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 06:49:50 2008 Subject: [GHC] #2571: ioref001 segfaults depending on how much stack space it has In-Reply-To: <044.be1f076de3b33330c413bedba41dbc09@localhost> References: <044.be1f076de3b33330c413bedba41dbc09@localhost> Message-ID: <053.b052a7037a33fef7258937f430e50bbc@localhost> #2571: ioref001 segfaults depending on how much stack space it has ----------------------------+----------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: ioref001 | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri Sep 12 11:01:40 BST 2008 Simon Marlow * Fix some bugs in the stack-reducing code (#2571) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 08:04:38 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 08:02:20 2008 Subject: [GHC] #2576: bio and retainer profiling segfaults In-Reply-To: <044.a90cb00250e6ac3fb6091f08144c5a9c@localhost> References: <044.a90cb00250e6ac3fb6091f08144c5a9c@localhost> Message-ID: <053.7ab080003206b21b07f74097098b21ee@localhost> #2576: bio and retainer profiling segfaults -------------------------+-------------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Profiling | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: heapprof001 | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri Sep 12 12:06:43 BST 2008 Simon Marlow * Fix retainer profiling (#2576) Fri Sep 12 12:25:44 BST 2008 Simon Marlow * Fix crash in biographical heap profiling (#2576) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 10:17:03 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 10:14:46 2008 Subject: [GHC] #2586: ghc segfaults when compiling bytestring001 In-Reply-To: <044.049be6675b7f11d36b94412f36ec028d@localhost> References: <044.049be6675b7f11d36b94412f36ec028d@localhost> Message-ID: <053.7f0726643ac70b6c3fb8afbb450044e5@localhost> #2586: ghc segfaults when compiling bytestring001 ---------------------------+------------------------------------------------ Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: bytestring001 | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri Sep 12 14:04:04 BST 2008 Simon Marlow * Fix #2586, bug in THUNK_SELECTORs (again) This time, we had forgetten the write barrier in one place. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 11:00:32 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 10:58:37 2008 Subject: [GHC] #2351: NetBSD defines ELF_ST_TYPE In-Reply-To: <043.48a409a4ca4cc55c3e518b567c9a2f02@localhost> References: <043.48a409a4ca4cc55c3e518b567c9a2f02@localhost> Message-ID: <052.6019d79fb7e62455175b9723c3e0c126@localhost> #2351: NetBSD defines ELF_ST_TYPE ----------------------------+----------------------------------------------- Reporter: donn | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: NetBSD | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: looks like this patch has already been committed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 11:49:47 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 11:47:32 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.d298861a04dc97cd9a1d4f1453415968@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ----------------------------+----------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Using today's HEAD, I just ran Bug2 until it used up all my memory (16Gb) and then some (apologies to the other people that were using this machine at the time :-). Last week I was able to reproduce the symptom, so I think it's likely that it was caused by one of the bugs I've fixed recently. I'm therefore going to close this ticket, but if it does still happen for you with 6.10 please re-open. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 15:25:10 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 15:22:52 2008 Subject: [GHC] #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" Message-ID: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" ------------------------+--------------------------------------------------- Reporter: gwright | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X ------------------------+--------------------------------------------------- When loading the attached file into ghci, it fails with: {{{ redwing-dakota> ghci GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :load Vector.hs [1 of 1] Compiling Data.Vector.Shore.Internal ( Vector.hs, interpreted ) *** Exception: ghci/ByteCodeGen.lhs:(1214,5)-(1221,34): Non-exhaustive patterns in case > }}} Compiling the file is successful: {{{ redwing-dakota> ghc -c Vector.hs redwing-dakota> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 15:33:37 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 15:31:18 2008 Subject: [GHC] #2590: problem with very large lists Message-ID: <055.1f075539798e24191f40fb5420cfcc13@localhost> #2590: problem with very large lists ---------------------------------+------------------------------------------ Reporter: christopheranand | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: x86 | Os: MacOS X ---------------------------------+------------------------------------------ I am debugging some numerical code and thought it would be easy to put the results into a Haskell module in order to analyse/filter it. First ghc stack overflowed. I chopped up the results, but still got: [1 of 1] Compiling Bugs12Sep2008 ( Bugs12Sept2008B.lhs, interpreted ) ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-apple-darwin): linkBCO: >= 64k insns in BCO -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 12 16:17:37 2008 From: trac at galois.com (GHC) Date: Fri Sep 12 16:15:18 2008 Subject: [GHC] #2591: Explain +RTS -xt output text Message-ID: <044.b626aec8f565e89dd926bf4290b84a90@localhost> #2591: Explain +RTS -xt output text ------------------------------+--------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ------------------------------+--------------------------------------------- The user guide should explain the meaning of all this: {{{ Main +RTS -p -s -xt -hc 1,372,408,024 bytes allocated in the heap 121,255,600 bytes copied during GC (scavenged) 6,584,692 bytes copied during GC (not scavenged) 2,768,896 bytes maximum residency (68 sample(s)) 2649 collections in generation 0 ( 1.11s) 68 collections in generation 1 ( 0.49s) 6 Mb total memory in use INIT time 0.00s ( 0.00s elapsed) MUT time 5.97s ( 6.63s elapsed) GC time 1.60s ( 1.88s elapsed) RP time 0.00s ( 0.00s elapsed) PROF time 0.19s ( 0.20s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 7.76s ( 8.71s elapsed) %GC time 20.6% (21.5% elapsed) Alloc rate 229,946,873 bytes per MUT second Productivity 76.9% of total user, 68.5% of total elapsed }}} Originally requested here: http://www.haskell.org/pipermail/haskell- cafe/2007-January/021350.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 13 11:10:55 2008 From: trac at galois.com (GHC) Date: Sat Sep 13 11:08:34 2008 Subject: [GHC] #2591: Explain +RTS -xt output text In-Reply-To: <044.b626aec8f565e89dd926bf4290b84a90@localhost> References: <044.b626aec8f565e89dd926bf4290b84a90@localhost> Message-ID: <053.b125ac2790b25b2da1dcf27ae9b93aeb@localhost> #2591: Explain +RTS -xt output text ---------------------------+------------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Comment (by igloo): Also http://www.haskell.org/pipermail/glasgow-haskell- users/2008-September/015469.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 13 13:09:38 2008 From: trac at galois.com (GHC) Date: Sat Sep 13 13:07:21 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.6ff4f650eb9aeee623055e1cb192345f@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Comment (by Svarog): Replying to [comment:10 simonmar]: > I'm validating the code now. Any chance you could whip up a test for the testsuite? I've just attached a patch for the testsuite and an updated patch for the finalizers. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 13 16:22:45 2008 From: trac at galois.com (GHC) Date: Sat Sep 13 16:20:22 2008 Subject: [GHC] #2592: Can't profile when the heap maximum is hit Message-ID: <046.6ff10d2040e94a9b4e4cc6a778189212@localhost> #2592: Can't profile when the heap maximum is hit ------------------------------+--------------------------------------------- Reporter: adekoba | Owner: Type: bug | Status: new Priority: normal | Component: Profiling Version: 6.8.2 | Severity: normal Keywords: profile, heap | Testcase: Architecture: Unknown | Os: Linux ------------------------------+--------------------------------------------- {{{ $ echo "main = print $ product [1..]" > temp.hs $ ghc -prof -auto-all temp.hs --make $ ./temp +RTS -M100k -p -RTS $ cat temp.prof }}} and the contents of temp.prof will be empty. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 13 19:02:14 2008 From: trac at galois.com (GHC) Date: Sat Sep 13 18:59:51 2008 Subject: [GHC] #2593: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) Message-ID: <044.cfc691368be0e75e6c805c71c10559fc@localhost> #2593: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) -------------------------------+-------------------------------------------- Reporter: shahn | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- An operation {{{ foo :: Int -> IO () }}} is wrapped to a function pointer {{{ptr :: FunPtr (Int -> IO ())}}} (via an FFI wrapper). If you pass this pointer to a C function, that calls it with a negative parameter (e.g. -1), the operation is executed with a positive parameter (something near {{{4294967295 ( == 2 ^ 32 - 1)}}}). This works correctly on x86 (32-bit). See attachment for an example. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 13 19:07:32 2008 From: trac at galois.com (GHC) Date: Sat Sep 13 19:05:14 2008 Subject: [GHC] #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) Message-ID: <044.a6b75e88dad86d305cedec64af5f04be@localhost> #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) -------------------------------+-------------------------------------------- Reporter: shahn | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- An operation {{{ foo :: Int -> IO () }}} is wrapped to a function pointer {{{ptr :: FunPtr (Int -> IO ())}}} (via an FFI wrapper). If you pass this pointer to a C function, that calls it with a negative parameter (e.g. -1), the operation is executed with a positive parameter (something near {{{4294967295 ( == 2 ^ 32 - 1)}}}). This works correctly on x86 (32-bit). See attachment for an example. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 13 19:14:06 2008 From: trac at galois.com (GHC) Date: Sat Sep 13 19:11:42 2008 Subject: [GHC] #2593: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) In-Reply-To: <044.cfc691368be0e75e6c805c71c10559fc@localhost> References: <044.cfc691368be0e75e6c805c71c10559fc@localhost> Message-ID: <053.92bc8569351c77447ba6b5a60e60511e@localhost> #2593: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) -------------------------------+-------------------------------------------- Reporter: shahn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Changes (by shahn): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 13 19:18:27 2008 From: trac at galois.com (GHC) Date: Sat Sep 13 19:16:05 2008 Subject: [GHC] #2346: Compilation of large source files requires a lot of RAM In-Reply-To: <046.285595109907aedbac69f385749bac00@localhost> References: <046.285595109907aedbac69f385749bac00@localhost> Message-ID: <055.a8afb080859f68c7cf910b2945d4f43f@localhost> #2346: Compilation of large source files requires a lot of RAM ------------------------------------------+--------------------------------- Reporter: choener | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Comment (by igloo): I'm not sure if this is the only problem, but one issue is that in a module like this: {{{ module Test where f alg1 alg2 = (a1, a2, a3, a4, a5) where (a1_1, a2_1, a3_1, a4_1, a5_1) = alg1 (a1_2, a2_2, a3_2, a4_2, a5_2) = alg2 a1 x (y,z) = (a1_1 x y, a1_2 x z) a2 x (y,z) = (a2_1 x y, a2_2 x z) a3 x (y,z) = (a3_1 x y, a3_2 x z) a4 x (y,z) = (a4_1 x y, a4_2 x z) a5 x (y,z) = (a5_1 x y, a5_2 x z) }}} we end up with a quadratic amount of code (and also, I think, a quadratic amount of type) e.g. in the above module we get 5 things like this: {{{ \ (x_ag3 :: t5_alb) (ds_dn0 :: (t6_ale, t7_alf)) -> case ds_dn0 of wild_B1 { (y_ag5, z_ag7) -> (case w_soy of wild1_XO { (a1_1_akE, a2_1_akG, a3_1_akI, a4_1_akK, a5_1_akM) -> a2_1_akG x_ag3 y_ag5 }, case w1_soz of wild1_XO { (a1_2_ako, a2_2_akq, a3_2_aks, a4_2_aku, a5_2_akw) -> a2_2_akq x_ag3 z_ag7 }) }, }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 13 19:52:10 2008 From: trac at galois.com (GHC) Date: Sat Sep 13 19:49:47 2008 Subject: [GHC] #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) In-Reply-To: <044.a6b75e88dad86d305cedec64af5f04be@localhost> References: <044.a6b75e88dad86d305cedec64af5f04be@localhost> Message-ID: <053.5e3bbf9cd7818ec56c5397af64e7ce92@localhost> #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) -------------------------------+-------------------------------------------- Reporter: shahn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => invalid Comment: I think this is an incorrect use of the FFI. The example uses Haskell `Int` and passes it to C code which uses it at C's type `int`. These are not the same types, though they do happen to coincide on x86 32bit. The example should be using `CInt` on the Haskell side. Alternatively, if the intention really is to use the Haskell `Int` type then the C side code must use `HsInt` (which is defined in `HsFFI.h`). The reason we get the observed result is because on x86-64, GHC uses a 64-bit `Int` while C's `int` remains 32bit so `-1` in a 32bit int is all `1` bits but that bit pattern as a larger int is `2^32-1`. So I'm closing the ticket as invalid. If anyone thinks this is incorrect then please do re-open it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 13 20:09:03 2008 From: trac at galois.com (GHC) Date: Sat Sep 13 20:06:40 2008 Subject: [GHC] #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) In-Reply-To: <044.a6b75e88dad86d305cedec64af5f04be@localhost> References: <044.a6b75e88dad86d305cedec64af5f04be@localhost> Message-ID: <053.8a532de77cbb5cbfb899cb7fc2dcf0c9@localhost> #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) -------------------------------+-------------------------------------------- Reporter: shahn | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Changes (by shahn): * status: closed => reopened * resolution: invalid => Comment: Replying to [comment:1 duncan]: I was unsure about the correct use of the FFI. However, the described behavior is also shown when using {{{CInt}}} instead of {{{Int}}}. I am re-opening the bug... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 14 05:52:23 2008 From: trac at galois.com (GHC) Date: Sun Sep 14 05:49:58 2008 Subject: [GHC] #2511: unix package doesnt load in ghci on freebsd/amd64 In-Reply-To: <046.b342e2cde385158917f69c7725044f60@localhost> References: <046.b342e2cde385158917f69c7725044f60@localhost> Message-ID: <055.998b37b0de2a5dad5398e5835b7a4b84@localhost> #2511: unix package doesnt load in ghci on freebsd/amd64 ----------------------------+----------------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/unix | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ----------------------------+----------------------------------------------- Comment (by obraun): I cannot reproduce this on FreeBSD 7.1-PRERELEASE amd64 using lang/ghc. Please update your ghc using the FreeBSD port and retry. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 15 03:53:43 2008 From: trac at galois.com (GHC) Date: Mon Sep 15 03:51:17 2008 Subject: [GHC] #2590: problem with very large lists In-Reply-To: <055.1f075539798e24191f40fb5420cfcc13@localhost> References: <055.1f075539798e24191f40fb5420cfcc13@localhost> Message-ID: <064.76875a305614d713775e22062d7e4b75@localhost> #2590: problem with very large lists ------------------------------+--------------------------------------------- Reporter: christopheranand | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ------------------------------+--------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Already ticketed as #789, but thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 15 03:54:07 2008 From: trac at galois.com (GHC) Date: Mon Sep 15 03:51:40 2008 Subject: [GHC] #789: BCOs can only have 64k instructions In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.abcf1810942583a1683a38ee8fc938df@localhost> #789: BCOs can only have 64k instructions ---------------------+------------------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------+------------------------------------------------------ Comment (by simonmar): See #2590 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 15 03:54:57 2008 From: trac at galois.com (GHC) Date: Mon Sep 15 03:52:33 2008 Subject: [GHC] #789: BCOs can only have 64k instructions In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.2061612c19c208452b42e58572c94880@localhost> #789: BCOs can only have 64k instructions ---------------------+------------------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------+------------------------------------------------------ Changes (by simonmar): * milestone: _|_ => 6.10 branch Comment: People are bumping into this, let's move it into a milestone where it should get looked at. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 15 04:26:47 2008 From: trac at galois.com (GHC) Date: Mon Sep 15 04:24:27 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.1ea031b18e14da83c1f198207cd5d150@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by maeder): As shown in the above [comment:17 comment] the ticket can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 15 10:00:46 2008 From: trac at galois.com (GHC) Date: Mon Sep 15 09:58:18 2008 Subject: [GHC] #2595: Implement record update for existential and GADT data types Message-ID: <046.4aca36ddfd3abd8f80e6714ed9319183@localhost> #2595: Implement record update for existential and GADT data types --------------------------------+------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Ganesh writes: The most important thing for me is supporting record update for existentially quantified data records, as in the error below. In general I also find working with code that involves existential type variables quite hard work - for example I can't use foo as a record selector either, even if I immediately do something that seals the existential type back up again. I don't understand this stuff well enough to be sure whether it's an impredicativity issue or not, though. {{{ Foo.hs:11:8: Record update for the non-Haskell-98 data type `Foo' is not (yet) supported Use pattern-matching instead In the expression: rec {foo = id} In the definition of `f': f rec = rec {foo = id} }}} Program is: {{{ {-# LANGUAGE Rank2Types #-} module Foo where data Foo = forall a . Foo { foo :: a -> a, bar :: Int } x :: Foo x = Foo { foo = id, bar = 3 } f :: Foo -> Foo f rec = rec { foo = id } g :: Foo -> Foo g rec = rec { bar = 3 } }}} Simon says: Ah now I see. The relevant comment, `TcExpr` line 465, says {{{ -- Doing record updates on -- GADTs and/or existentials is more than my tiny -- brain can cope with today }}} Should be fixable, even with a tiny brain. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 15 11:28:14 2008 From: trac at galois.com (GHC) Date: Mon Sep 15 11:25:47 2008 Subject: [GHC] #2587: Optimiser bug with extistentials and GADT's In-Reply-To: <051.b3070f4c96d88d63d3d2b2aa409dea4e@localhost> References: <051.b3070f4c96d88d63d3d2b2aa409dea4e@localhost> Message-ID: <060.7477c30a5ae285b475edff882f1aa02e@localhost> #2587: Optimiser bug with extistentials and GADT's -------------------------------------------------------------------------------------+ Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: neil.mitchell.2@credit-suisse.com, ganesh.sittampalam@credit-suisse.com | Difficulty: Unknown Testcase: gadt/T2587 | Architecture: Unknown Os: Unknown | -------------------------------------------------------------------------------------+ Changes (by simonpj): * testcase: => gadt/T2587 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Excellent example, thank you. Fixed by {{{ Sun Sep 14 04:34:34 PDT 2008 simonpj@microsoft.com * Fix Trac #2587: take account of type lets }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 15 12:30:42 2008 From: trac at galois.com (GHC) Date: Mon Sep 15 12:28:23 2008 Subject: [GHC] #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 In-Reply-To: <046.25be20912976f68417223aab5966cd22@localhost> References: <046.25be20912976f68417223aab5966cd22@localhost> Message-ID: <055.4496d8971200091fc3fd840bed38b4ed@localhost> #2328: Compiling DoCon with 6.8.3 has 3x slow-down compared with 6.8.2 ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: simonpj Type: compile-time performance bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I believe this is now fixed. Hurrah! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 15 12:45:23 2008 From: trac at galois.com (GHC) Date: Mon Sep 15 12:42:55 2008 Subject: [GHC] #1735: unused binding changes program behaviour In-Reply-To: <044.165e86ea1e61301d33d53cf154829fac@localhost> References: <044.165e86ea1e61301d33d53cf154829fac@localhost> Message-ID: <053.b329732956f14528adcaa942798c8ee7@localhost> #1735: unused binding changes program behaviour ----------------------+----------------------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * priority: normal => low * milestone: 6.10.1 => 6.12 branch Comment: It's definitely that dodgy instance declaration. I can't quite say why it works sometimes and sometimes not, and I agree that is undesirable. But I can see it's very delicately balanced. I'm not going to pursue this until I've fixed #1470 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 15 15:08:52 2008 From: trac at galois.com (GHC) Date: Mon Sep 15 15:06:26 2008 Subject: [GHC] #2596: Token concatentation (##) in C preprocessor Message-ID: <048.ab4f0681bbb3541df391c141fc8c9414@localhost> #2596: Token concatentation (##) in C preprocessor --------------------------------+------------------------------------------- Reporter: sedillard | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- {{{ #define MY_MACRO(A,B) \ instance MyClass A##B where ... MY_MACRO(Foo,Bar) }}} Should expand to {{{ instance MyClass FooBar where ... }}} This behavior is defined in the C standard, and is quite handy. Presently GHC leaves the '##' in the expanded text. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 15 15:30:42 2008 From: trac at galois.com (GHC) Date: Mon Sep 15 15:28:33 2008 Subject: [GHC] #2596: Token concatentation (##) in C preprocessor In-Reply-To: <048.ab4f0681bbb3541df391c141fc8c9414@localhost> References: <048.ab4f0681bbb3541df391c141fc8c9414@localhost> Message-ID: <057.1a5bc87176a8c94618ce99bc8faa9eff@localhost> #2596: Token concatentation (##) in C preprocessor --------------------------------+------------------------------------------- Reporter: sedillard | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): This occurs because ghc calls the C preprocessor with the -traditional flag, and the ## string-catenation operator is not K&R, it was introduced in the ANSI version of C. There are various good reasons why it is necessary for ghc to use cpp -traditional rather than -ansi. You can try passing the -ansi flag manually ({{{ghc -optP-ansi}}}) but results are not guaranteed to be useful. Another route to try is to install cpphs and instruct ghc to use it instead of cpp. {{{ghc -pgmPcpphs -optP--cpp -optP-ansi}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 15 21:22:19 2008 From: trac at galois.com (GHC) Date: Mon Sep 15 21:19:50 2008 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> Message-ID: <053.2d4d375b64ee2b6e72ce809ef42808c0@localhost> #2578: "ld: atom sorting error for ..." on OS X ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by judah): The following post gives a little information about this issue: http://www.haskell.org/pipermail/glasgow-haskell- users/2008-January/013990.html General consensus is that it's harmless; but it would be nice to eliminate the messages if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 03:46:19 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 03:43:55 2008 Subject: [GHC] #2063: Breackage on OpenBSD due to mmap remap In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.4d96f5d9892588eb7f1b8805c4fcdc18@localhost> #2063: Breackage on OpenBSD due to mmap remap ----------------------------+----------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD | Difficulty: Moderate (1 day) Testcase: | Architecture: Multiple Os: OpenBSD | ----------------------------+----------------------------------------------- Comment (by simonmar): I just made some changes in this area, although not a fix for *BSD this will make things slightly easier: {{{ Mon Sep 15 15:59:24 BST 2008 Simon Marlow * Stop using mremap() to allocate space for trampolines This was causing problems because sometimes mremap() moved the memory we had allocated from the low 2Gb to above the 2Gb boundary, causing some linkages to fail. There's no MAP_32BIT flag to mremap(). So now we just use mmap(MAP_ANON|MAP_32BIT) to allocated space for the trampolines. People without MAP_32BIT (eg. *BSD) will still have to do something else here, such as allocating memory from a fixed address; so I've made it slightly easier for those guys, but there's still work to do (#2063). One solution (that Simon PJ is advocating) is to turn on -fPIC by default on x86-64. This is a good solution as it removes the need for MAP_32BIT, but doesn't work with -fvia-C, so probably this is for later. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 04:21:06 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 04:18:43 2008 Subject: [GHC] #2555: Template Haskell does not respect -package and -hide constraints In-Reply-To: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> References: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> Message-ID: <053.2a54fc6f1d8d5dcd8d53ce720a2eeed9@localhost> #2555: Template Haskell does not respect -package and -hide constraints ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Comment (by simonpj): Simon and I discussed this, and we can't understand enough about the problem to see what is going on. So we need a way to reproduce it. Can you give us some code, and a recipe for making it happen? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 05:00:43 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 04:58:17 2008 Subject: [GHC] #2597: panic! (the 'impossible' happened) (using TH) Message-ID: <043.059865a2ed72b6802d1466b05790ef9c@localhost> #2597: panic! (the 'impossible' happened) (using TH) -----------------------+---------------------------------------------------- Reporter: jcab | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 6.8.3 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- ghc: panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-mingw32): Prelude.init: empty list Attached the compilable files for your enjoyment and reproduction. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 05:37:31 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 05:35:06 2008 Subject: [GHC] #2598: Avoid excessive specialisation in SpecConstr Message-ID: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> #2598: Avoid excessive specialisation in SpecConstr --------------------------------+------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- This ticket captures an email thread so it doesn't get lost. Consider this (from `haddock/src/Haddock/Backends/Hoogle.hs`): {{{ dropComment (' ':'-':'-':' ':_) = [] dropComment (x:xs) = x : dropComment xs dropComment [] = [] }}} This desugars thus: {{{ dropComment xs = case xs of (C# x1 : xs1) -> case x1 of ' '# -> case xs1 of (C# x2:xs2) -> case x2 of '-' -> .... DEFAULT -> dropComment (C# x2 : xs2) DEFAULT -> ... [] -> ... }}} I have elided the branches that are less interesting, and I have done a bit of multi-level pattern matching to save space. The thing to notice is this: at the recursive call, we know that the argument is a cons, with C# at the front. So `SpecConstr` dutifully creates a specialized version. And similarly for ''each subsequent character''! Indeed, if the match fails after matching `(' ': '-' : )` prefix, the recursive call even knows that the first char is `'-'`! Hence we get as many specializations as we have characters in the input match. So `SpecConstr` is behaving as expected. Can anyone think of a heuristic to squash this behavior? At the moment we take the first N specializations and then stop. One heuristic might be "if there are lots of recursive calls, don't specialize". But that is very close to "if there are lots of specializations, drop some". Mind you, perhaps we should be more vigorous still: "if there are more than N, don't do any" on the grounds that randomly choosing the first few is unlikely to be useful. Any thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 05:38:16 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 05:35:48 2008 Subject: [GHC] #2598: Avoid excessive specialisation in SpecConstr In-Reply-To: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> References: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> Message-ID: <055.07ff80e0416e7927f03261d2f87515eb@localhost> #2598: Avoid excessive specialisation in SpecConstr -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by simonpj): Neil has a good suggestion: One possible heuristic would be to never specialise down recursive components. That way you would only ever obtain the specialisations: {{{ [] _:_ ' ':_ '-':_ }}} Which seems like a sensible set. By using a size bound as well, your definition of recursive components can be very weak - directly recursive should catch most examples. I'm not sure how this work with other examples - it seems sufficient for the classic 'last' example though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 07:22:23 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 07:19:56 2008 Subject: [GHC] #2599: Improve error message for type rigidity Message-ID: <046.745ab542948a68e7e48c0d422a79927d@localhost> #2599: Improve error message for type rigidity --------------------------------+------------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- When saying that a GADT match is given a non-rigid type, we should be more explicit about where a type signature would help. For example, given the program: {{{ data E x = E x data Foo a where Foo :: Gadt a -> Foo a data Gadt a where GadtValue :: a -> Gadt (E a) g = case undefined of Foo GadtValue -> () }}} I get the error message: {{{ Test.hs:13:12: GADT pattern match with non-rigid result type `t' Solution: add a type signature In a case alternative: Foo GadtValue -> () In the expression: case undefined of { Foo GadtValue -> () } In the definition of `g': g = case undefined of { Foo GadtValue -> () } }}} But where should the type signature be? A better hint would be: {{{ Solution: add a type signature, probably at _TYPE_ (case undefined of { Foo GadtValue -> () }) :: _TYPE_ }}} Similarly, we know when it's the scrutinee that needs a signature. And in a do-binding the "scrutinee" is really the right-hand side. We can get all this information from the matching context. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 07:29:23 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 07:26:55 2008 Subject: [GHC] #2600: Bind type variables in RULES Message-ID: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> #2600: Bind type variables in RULES --------------------------------+------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Roman writes: here's an example I came across while working on the recycling paper and which I subsequently forgot about. Suppose we have: {{{ {-# LANGUAGE Rank2Types #-} module T where class T t where to :: [a] -> t a from :: t a -> [a] tmap :: (a -> a) -> t a -> t a {-# RULES "myrule" forall f x. from (tmap f (to x)) = map f (from (to x)) #-} }}} Alas, this fails with: {{{ Ambiguous type variable `t' in the constraint: `T t' arising from a use of `to' at T.hs:12:40-43 Probable fix: add a type signature that fixes these type variable(s) }}} Of course, I'd like the t on the rhs to be the same as on the lhs but I don't see how to tell this to GHC. Is it actually possible? The only solution I've found was to add a dummy argument to 'to': {{{ to' :: t a -> [a] -> t a to = to' undefined {-# RULES "myrule" forall f t x. from (tmap f (to' t x)) = map f (from (to' t x)) #-} }}} That's ugly, of course. Am I missing something or is this just impossible to do with the current system? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 07:31:13 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 07:28:46 2008 Subject: [GHC] #2600: Bind type variables in RULES In-Reply-To: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> References: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> Message-ID: <055.442d5289eb2fbdd2a1327d8678098b27@localhost> #2600: Bind type variables in RULES -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: How annoying. You're right, it's impossible, because the 't' isn't mentioned in the type of 'f', or 'x'. What would we like to write? Perhaps something like {{{ "myrule" forall (type t :: *->*) (f :: a->a) x. from (tmap f (to x :: t a)) = map f (from (to x :: t a)) }}} We need a syntactic clue to distinguish the '''type''' binders in the forall from the '''term''' binders. Saying "the signature mentions "*" seems a bit flaky to me. My suggestion above is to re-use the keyword `type`. Incidentally, once the rule is parsed and typechecked, the simplifier will have no trouble doing the right thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 07:36:17 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 07:33:59 2008 Subject: [GHC] #2588: Missed suggestion with context on foralls In-Reply-To: <051.f82176fc0c07b1750e90df780f097cc7@localhost> References: <051.f82176fc0c07b1750e90df780f097cc7@localhost> Message-ID: <060.22cd3330ee700ac52d48cd3f26f2f1f9@localhost> #2588: Missed suggestion with context on foralls --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown * milestone: => 6.12 branch Old description: > Given the program: > > {{{ > module Test where > test :: forall a . a -> a > test = id > }}} > > I get the nice and helpful error message: > > {{{ > Test.hs:3:17: > Illegal operator `.' in type `forall a . (a -> a)' > Perhaps you intended to use -XRankNTypes or similar flag > to enable explicit-forall syntax: forall . > }}} > > [I personally usually want ScopedTypeVariables rather than RankNTypes, > but its still a very useful hint at where to look] > > However, trying the program: > > {{{ > module Test where > test :: forall a . Eq a => a -> a > test = id > }}} > > Gives: > > {{{ > Test.hs:3:24: parse error on input `=>' > }}} > > I think it would be helpful to give the same suggestion as above. > > -- Neil New description: Given the program: {{{ module Test where test :: forall a . a -> a test = id }}} I get the nice and helpful error message: {{{ Test.hs:3:17: Illegal operator `.' in type `forall a . (a -> a)' Perhaps you intended to use -XRankNTypes or similar flag to enable explicit-forall syntax: forall . }}} [I personally usually want `ScopedTypeVariables` rather than `RankNTypes`, but its still a very useful hint at where to look] However, trying the program: {{{ module Test where test :: forall a . Eq a => a -> a test = id }}} Gives: {{{ Test.hs:3:24: parse error on input `=>' }}} I think it would be helpful to give the same suggestion as above. -- Neil Comment: Good suggestion, but harder to implement. Without `ScopedTypeVariables`, `forall` is not a keyword, so GHC is trying to parse that thing as a '''type''', and it just doesn't follow the syntax for types. The solution is probably this: * Do not treat `=>` specially in the parser * Instead parse it as an infix operator * In the post-parsing re-organisation (`RdrHsSyn`), unswizzle the `=>` into a constraint set * But in doing so, if the stuff on the left of the `=>` doesn't look like a constraint set, look for a leading `forall` and complain appropriately Not really hard, but fiddly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 08:55:26 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 08:53:39 2008 Subject: [GHC] #1999: panic with GADT etc. In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost> References: <046.74c6dc616261a913ffd4180fb00731f0@localhost> Message-ID: <055.0b8b254e876d5e218b340de00ca67f1c@localhost> #1999: panic with GADT etc. ---------------------------+------------------------------------------------ Reporter: jeltsch | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T1999, T1999a | Architecture: x86 Os: Linux | ---------------------------+------------------------------------------------ Changes (by chak): * status: reopened => closed * resolution: => fixed Comment: Fixed with the new equality solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 09:30:19 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 09:28:00 2008 Subject: [GHC] #1548: printf bugs In-Reply-To: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> References: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> Message-ID: <060.1f55b9bc89fca3040066f029636af536@localhost> #1548: printf bugs ----------------------------+----------------------------------------------- Reporter: l.mai@web.de | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: reopened => new * owner: lennart@augustsson.net => simonmar Comment: I'll review, validate & apply. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 10:03:28 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 10:01:04 2008 Subject: [GHC] #2469: Linking fails with "multiple definition of `deRefStablePtr'" In-Reply-To: <048.9eb18d1762f2087efabea300fec1f63f@localhost> References: <048.9eb18d1762f2087efabea300fec1f63f@localhost> Message-ID: <057.36df76582f034b0e03c7ca66495e125a@localhost> #2469: Linking fails with "multiple definition of `deRefStablePtr'" ----------------------------------+----------------------------------------- Reporter: meteficha | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: linker ffi stableptr | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Tue Sep 16 14:22:22 BST 2008 Simon Marlow * FIX #2469: sort out our static/extern inline story gcc has changed the meaning of "extern inline" when certain flags are on (e.g. --std=gnu99), and this broke our use of it in the header files. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 10:28:13 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 10:25:43 2008 Subject: [GHC] #2601: Extra parens in error message's displayed code Message-ID: <043.b794cfa79c2c26f5a45cbac59064659b@localhost> #2601: Extra parens in error message's displayed code -------------------------------+-------------------------------------------- Reporter: kaol | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- I'm forwarding the bug [http://bugs.debian.org/499137 #499137] from Debian's BTS. With this example: {{{ import System.Environment main = do args <- filter (/= "--nofork") getArgs return () }}} I get this error message: {{{ Couldn't match expected type `[[Char]]' against inferred type `IO [String]' In the second argument of `filter', namely `getArgs' In a 'do' expression: args <- filter ((/= "--nofork")) getArgs In the expression: do args <- filter ((/= "--nofork")) getArgs return () }}} At some turn, the expression gained an extraneous pair of parenthesis. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 10:45:44 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 10:43:41 2008 Subject: [GHC] #2598: Avoid excessive specialisation in SpecConstr In-Reply-To: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> References: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> Message-ID: <055.9adba47aa14f9d175c612f449bd7bfc9@localhost> #2598: Avoid excessive specialisation in SpecConstr -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 11:07:47 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 11:05:21 2008 Subject: [GHC] #2602: Haddock not installed properly Message-ID: <051.bff77834b377c6ec330f589afeeee640@localhost> #2602: Haddock not installed properly -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- I built GHC Head, took a bindist, moved that to a different machine, and tried the included haddock on a test file: {{{ C:\ghc>c:\ghc\ghc-6.9.20080916\bin\haddock.exe Test.hs --html --hoogle Warning: main:Test: could not find link destinations for: GHC.Types.Int haddock: internal Haddock or GHC error: c:\ghc\ghc-6.9.20080916\bin\..\share/htm l/haddock.css: openFile: does not exist (No such file or directory) }}} haddock.css is actually located at c:\ghc\ghc-6.9.20080916\html\haddock.css (i.e. get rid of the share). -- Neil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 11:14:25 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 11:12:07 2008 Subject: [GHC] #1548: printf bugs In-Reply-To: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> References: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> Message-ID: <060.0bd282cf99042f9a366f6428877b51e9@localhost> #1548: printf bugs ----------------------------+----------------------------------------------- Reporter: l.mai@web.de | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * milestone: 6.10.1 => 6.10 branch Comment: New version committed, but the third example in the original report still gives the apparently wrong result {{{ Prelude Text.Printf> printf "%10.5d" 4 :: String " 4" (expected: " 00004") }}} {{{ Tue Sep 16 14:35:05 BST 2008 Simon Marlow * Fix bugs in Text.Printf (#1548) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 12:02:54 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 12:00:31 2008 Subject: [GHC] #2603: Crash on Korn shell on Windows XP Message-ID: <051.5626caf3a9b026fab0cf28ae90fdd1a7@localhost> #2603: Crash on Korn shell on Windows XP -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Running GHC HEAD in a Korn Shell on Windows XP gives: {{{ [C:/Neil] 21$ ghc ghc: panic! (the 'impossible' happened) (GHC version 6.9.20080916 for i386-unknown-mingw32): can't decompose ghc.exe path: "C:\\ghc\\ghc-6.9.20080916\\bin\\ghc.EXE" Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The problem is that Korn has resolved ghc as ghc.EXE, which matches ghc.exe because windows is case insensitive when looking up files. This causes an error in SysTools.lhs. The attached patch fixes this issue. I have not validated. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 12:05:38 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 12:03:16 2008 Subject: [GHC] #2603: Crash on Korn shell on Windows XP In-Reply-To: <051.5626caf3a9b026fab0cf28ae90fdd1a7@localhost> References: <051.5626caf3a9b026fab0cf28ae90fdd1a7@localhost> Message-ID: <060.786dc5fb43ac9182da7ba69172978742@localhost> #2603: Crash on Korn shell on Windows XP -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Changes (by NeilMitchell): * cc: neil.mitchell.2@credit-suisse.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 12:07:02 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 12:04:36 2008 Subject: [GHC] #2597: panic! (the 'impossible' happened) (using TH) In-Reply-To: <043.059865a2ed72b6802d1466b05790ef9c@localhost> References: <043.059865a2ed72b6802d1466b05790ef9c@localhost> Message-ID: <052.b9aa6f6dadaf4ce9aa00356b51097f5d@localhost> #2597: panic! (the 'impossible' happened) (using TH) ------------------------------+--------------------------------------------- Reporter: jcab | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: The good news is that things are better with the HEAD, as you see below. But I have no idea what the "Failing due to -Werror" is about, since I hvae not specified `-Werror`. Ian, Simon, any ideas? Simon {{{ c:/darcs/HEAD/ghc/stage2-inplace/ghc --make kk.hs -fglasgow-exts -fallow- undecidable-instances -fallow-overlapping-instances -fno-monomorphism- restriction -threaded -lKernel32 -lUser32 -lGdi32 -lOle32 -lComctl32 -optc-D_WIN32_IE=0x700 -optc-D_WIN32_WINNT=0x600 -ilib -odir obj -hidir obj -stubdir obj on the commandline: Warning: -fallow-undecidable-instances is deprecated: use -XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances#-} instead on the commandline: Warning: -fallow-overlapping-instances is deprecated: use -XOverlappingInstances or pragma {-# LANGUAGE OverlappingInstances#-} instead on the commandline: Warning: -fno-monomorphism-restriction is deprecated: use -XNoMonomorphismRestriction or pragma {-# LANGUAGE NoMonomorphismRestriction#-} instead kk.hs:1:11: Warning: -fth is deprecated: use -XTemplateHaskell or pragma {-# LANGUAGE TemplateHaskell#-} instead lib\JCAB\TH.hs:1:11: Warning: -fth is deprecated: use -XTemplateHaskell or pragma {-# LANGUAGE TemplateHaskell#-} instead lib\Win32\System\TH.hs:1:11: Warning: -fth is deprecated: use -XTemplateHaskell or pragma {-# LANGUAGE TemplateHaskell#-} instead [4 of 4] Compiling Main ( kk.hs, obj\Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading object (dynamic) Kernel32 ... done Loading object (dynamic) User32 ... done Loading object (dynamic) Gdi32 ... done Loading object (dynamic) Ole32 ... done Loading object (dynamic) Comctl32 ... done final link ... done Loading package syb ... linking ... done. Loading package array-0.1 ... linking ... done. Loading package packedstring-0.1 ... linking ... done. : Failing due to -Werror. Loading package containers-0.1 ... linking ... done. Loading package pretty-1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package mtl-1.1.0.1 ... linking ... done. make: *** [default] Error 1 bash-3.2$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 13:06:26 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 13:04:00 2008 Subject: [GHC] #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" In-Reply-To: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> References: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> Message-ID: <055.55181419d7cec90dfb6ebd4c98c4bcae@localhost> #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" ----------------------+----------------------------------------------------- Reporter: gwright | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Seems ok with the HEAD. {{{ ~/builds-04/HEAD-1/ghc/stage2-inplace/ghc --interactive GHCi, version 6.9: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. No entry for terminal type "emacs"; using dumb terminal settings. Prelude> :l T2589.hs Ok, modules loaded: Data.Vector.Shore.Internal. Prelude Data.Vector.Shore.Internal> }}} If you could test against a snapshot distribution that'd be great. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 16 22:34:59 2008 From: trac at galois.com (GHC) Date: Tue Sep 16 22:32:56 2008 Subject: [GHC] #2585: New versions of windres fail with "windres: CreateProcess (null): No error" In-Reply-To: <044.25b69fd7b594ae443d31576c538df3be@localhost> References: <044.25b69fd7b594ae443d31576c538df3be@localhost> Message-ID: <053.a9f1f855338d11875e838e5c1862f6ca@localhost> #2585: New versions of windres fail with "windres: CreateProcess (null): No error" ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by shelarcy): * cc: shelarcy@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 00:46:41 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 00:44:17 2008 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> Message-ID: <053.e4bf1f6601ef86257ad28114d4c0f0ae@localhost> #2578: "ld: atom sorting error for ..." on OS X ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by chak): It may be harmless, but it is certainly annoying as it makes tests in the testsuite fail for reasons unrelated to the test (with the usual implications for validate). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 03:07:59 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 03:07:19 2008 Subject: [GHC] #2598: Avoid excessive specialisation in SpecConstr In-Reply-To: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> References: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> Message-ID: <055.eeacca01e5d7dba1db65dae9116b7595@localhost> #2598: Avoid excessive specialisation in SpecConstr -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * cc: rl@cse.unsw.edu.au (added) Comment: Roman says: Yes, as long as the definition of recursive doesn't include things like {{{ data T a where Pair :: T a -> T b -> T (a,b) ... }}} and similar constructs for indexed types. I'm not really convinced about this idea, though. What is so special about recursive constructors? And why is generating all specialisations in this particular case bad at all? In the end, all but the one for `dropComment (x:xs`) are eliminated which roughly doubles the code size. There are a couple more tiny leftovers but that's only because GHC isn't even trying to get rid of them. To be honest, I don't quite see the problem here. In fact, in this example `SpecConstr` actually performs a fairly complex optimisation which, unfortunately, doesn't bring much (I think; benchmarking the lexer with and without `SpecConstr` would be useful). {{{ > dropComment (' ':'-':'-':' ':_) = [] > dropComment (x:xs) = x : dropComment xs > dropComment [] = [] }}} Without `SpecConstr`, we have: {{{ dropComment (' ':'-':'a':...) -> dropComment ('-':'a':...) -> dropComment ('a':...) }}} `SpecConstr` skips the second step (i.e., saves a recursive call) because it knows that the argument won't match the first equation. For Haddock, this isn't a big win unless the input file contains a lot of space/dash sequences. However, I can easily imagine programs where this optimisation would be very desirable. Roman -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 03:15:23 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 03:12:57 2008 Subject: [GHC] #2598: Avoid excessive specialisation in SpecConstr In-Reply-To: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> References: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> Message-ID: <055.ed20b03898f033055738f6ec3e855bdc@localhost> #2598: Avoid excessive specialisation in SpecConstr -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by simonpj): Hmm. I just compiled `dropComment` all by itself, and sure enough you get two `dropComment` itself, one similar-sized specialisation --- together with another FIVE smaller specialisations that look like {{{ Foo.$sdropComment3 :: [GHC.Types.Char] -> GHC.Prim.Char# -> [GHC.Types.Char] Foo.$sdropComment3 xs c = '-' : Foo.$sdropComment2 xs c }}} and similar ones. I'd expected lots of big specialisations, so this was a surprise to me. The full output follows. Still there a big bloat in the middle. Discarding the recursive components is just a slightly-random heuristic, and I expect you're right that there might be cases where it matters. Simon {{{ ==================== Tidy Core ==================== Foo.a :: GHC.Types.Char [GlobalId] [NoCafRefs] Foo.a = GHC.Types.C# '-' Foo.a1 :: GHC.Types.Char [GlobalId] [NoCafRefs] Foo.a1 = GHC.Types.C# '-' Foo.$sdropComment :: [GHC.Types.Char] [GlobalId] [NoCafRefs] Foo.$sdropComment = GHC.Types.: @ GHC.Types.Char Foo.a (GHC.Types.[] @ GHC.Types.Char) Foo.$sdropComment1 :: [GHC.Types.Char] [GlobalId] [NoCafRefs] Foo.$sdropComment1 = GHC.Types.: @ GHC.Types.Char Foo.a1 Foo.$sdropComment Rec { Foo.$sdropComment2 :: [GHC.Types.Char] -> GHC.Prim.Char# -> [GHC.Types.Char] [GlobalId] [Arity 2 NoCafRefs] Foo.$sdropComment2 = \ (sc_sgz :: [GHC.Types.Char]) (sc1_sgA :: GHC.Prim.Char#) -> GHC.Types.: @ GHC.Types.Char (GHC.Types.C# '-') (Foo.$sdropComment4 sc_sgz sc1_sgA) Foo.$sdropComment3 :: [GHC.Types.Char] -> GHC.Prim.Char# -> [GHC.Types.Char] [GlobalId] [Arity 2 NoCafRefs] Foo.$sdropComment3 = \ (sc_sgD :: [GHC.Types.Char]) (sc1_sgE :: GHC.Prim.Char#) -> GHC.Types.: @ GHC.Types.Char (GHC.Types.C# '-') (Foo.$sdropComment2 sc_sgD sc1_sgE) Foo.$sdropComment4 :: [GHC.Types.Char] -> GHC.Prim.Char# -> [GHC.Types.Char] [GlobalId] [Arity 2 NoCafRefs] Foo.$sdropComment4 = \ (sc_sgv :: [GHC.Types.Char]) (sc1_sgw :: GHC.Prim.Char#) -> case sc1_sgw of ds_Xfu { __DEFAULT -> GHC.Types.: @ GHC.Types.Char (GHC.Types.C# ds_Xfu) (Foo.dropComment sc_sgv); ' ' -> case sc_sgv of wild_Xo { [] -> GHC.Types.: @ GHC.Types.Char (GHC.Types.C# ' ') (GHC.Types.[] @ GHC.Types.Char); : ds1_dfc ds2_dfd -> case ds1_dfc of wild1_Xu { GHC.Types.C# ds3_dfe -> case ds3_dfe of ds4_XfM { __DEFAULT -> GHC.Types.: @ GHC.Types.Char (GHC.Types.C# ' ') (Foo.$sdropComment4 ds2_dfd ds4_XfM); '-' -> case ds2_dfd of wild2_XD { [] -> GHC.Types.: @ GHC.Types.Char (GHC.Types.C# ' ') Foo.$sdropComment; : ds5_dff ds6_dfg -> case ds5_dff of wild3_XJ { GHC.Types.C# ds7_dfh -> case ds7_dfh of ds8_Xg4 { __DEFAULT -> GHC.Types.: @ GHC.Types.Char (GHC.Types.C# ' ') (GHC.Types.: @ GHC.Types.Char (GHC.Types.C# '-') (Foo.$sdropComment4 ds6_dfg ds8_Xg4)); '-' -> case ds6_dfg of wild4_XS { [] -> GHC.Types.: @ GHC.Types.Char (GHC.Types.C# ' ') Foo.$sdropComment1; : ds9_dfi ds10_dfj -> case ds9_dfi of wild5_XY { GHC.Types.C# ds11_dfk -> case ds11_dfk of ds12_Xgm { __DEFAULT -> GHC.Types.: @ GHC.Types.Char (GHC.Types.C# ' ') (GHC.Types.: @ GHC.Types.Char (GHC.Types.C# '-') (GHC.Types.: @ GHC.Types.Char (GHC.Types.C# '-') (Foo.$sdropComment4 ds10_dfj ds12_Xgm))); ' ' -> GHC.Types.[] @ GHC.Types.Char }}}}}}}}} Foo.dropComment :: [GHC.Types.Char] -> [GHC.Types.Char] [GlobalId] [Arity 1 NoCafRefs Str: DmdType S] Foo.dropComment = \ (ds_df8 :: [GHC.Types.Char]) -> case ds_df8 of wild_B1 { [] -> GHC.Types.[] @ GHC.Types.Char; : ds1_df9 ds2_dfa -> case ds1_df9 of wild1_Xf { GHC.Types.C# ds3_dfb -> case ds3_dfb of ds4_Xfu { __DEFAULT -> GHC.Types.: @ GHC.Types.Char wild1_Xf (Foo.dropComment ds2_dfa); ' ' -> case ds2_dfa of wild2_Xo { [] -> GHC.Types.: @ GHC.Types.Char wild1_Xf (GHC.Types.[] @ GHC.Types.Char); : ds5_dfc ds6_dfd -> case ds5_dfc of wild3_Xu { GHC.Types.C# ds7_dfe -> case ds7_dfe of ds8_XfM { __DEFAULT -> GHC.Types.: @ GHC.Types.Char wild1_Xf (Foo.$sdropComment4 ds6_dfd ds8_XfM); '-' -> case ds6_dfd of wild4_XD { [] -> GHC.Types.: @ GHC.Types.Char wild1_Xf Foo.$sdropComment; : ds9_dff ds10_dfg -> case ds9_dff of wild5_XJ { GHC.Types.C# ds11_dfh -> case ds11_dfh of ds12_Xg4 { __DEFAULT -> GHC.Types.: @ GHC.Types.Char wild1_Xf (GHC.Types.: @ GHC.Types.Char (GHC.Types.C# '-') (Foo.$sdropComment4 ds10_dfg ds12_Xg4)); '-' -> case ds10_dfg of wild6_XS { [] -> GHC.Types.: @ GHC.Types.Char wild1_Xf Foo.$sdropComment1; : ds13_dfi ds14_dfj -> case ds13_dfi of wild7_XY { GHC.Types.C# ds15_dfk -> case ds15_dfk of ds16_Xgm { __DEFAULT -> GHC.Types.: @ GHC.Types.Char wild1_Xf (GHC.Types.: @ GHC.Types.Char (GHC.Types.C# '-') (GHC.Types.: @ GHC.Types.Char (GHC.Types.C# '-') (Foo.$sdropComment4 ds14_dfj ds16_Xgm))); ' ' -> GHC.Types.[] @ GHC.Types.Char }}}}}}}}}}} end Rec } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 03:35:12 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 03:32:58 2008 Subject: [GHC] #2601: Extra parens in error message's displayed code In-Reply-To: <043.b794cfa79c2c26f5a45cbac59064659b@localhost> References: <043.b794cfa79c2c26f5a45cbac59064659b@localhost> Message-ID: <052.4fefc07052aefc8550480a2ea4139665@localhost> #2601: Extra parens in error message's displayed code ----------------------+----------------------------------------------------- Reporter: kaol | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Happily this is already OK in the HEAD (and hence in 6.10). Thanks for the report though -- keep them coming. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 05:42:42 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 05:40:18 2008 Subject: [GHC] #2604: Suggest -XDeriveDataTypeable with "newtype" too Message-ID: <043.b1f1671247f6c4e384c3ee43b1a2000a@localhost> #2604: Suggest -XDeriveDataTypeable with "newtype" too --------------------------------+------------------------------------------- Reporter: kaol | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: trivial Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- I'm forwarding wishlist bug [http://bugs.debian.org/499216 #499216] from Debian's BTS. ---- If I try to compile or load this program, ghc complains that I need to pass -XDeriveDataTypeable to enable the derivation of Typeable instances: {{{ ------ begin Test.hs -------- module Test where import Data.Typeable data List a = List [a] deriving(Typeable) ----------------------------- }}} {{{ Test.hs:5:0: Can't make a derived instance of `Typeable (List a)' (You need -XDeriveDataTypeable to derive an instance for this class) In the data type declaration for `List' }}} If I use "newtype" and I have GeneralizedNewtypeDeriving turned on, however, I get this error: {{{ /tmp/Test.hs:5:0: Can't make a derived instance of `Typeable (List a)' (even with cunning newtype deriving:) In the newtype declaration for `List' }}} It would be nice if ghc suggested DeriveDataTypeable here too. JFTR, it does suggest this if newtype deriving is off: {{{ /tmp/Test.hs:5:0: Can't make a derived instance of `Typeable (List a)' (You need -XDeriveDataTypeable to derive an instance for this class Try -XGeneralizedNewtypeDeriving for GHC's newtype-deriving extension) In the newtype declaration for `List' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 05:47:39 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 05:45:17 2008 Subject: [GHC] #2605: Possible error message improvement when -XRankNTypes is missing Message-ID: <043.1c39b7a94fa4d25aff9e796ce2606603@localhost> #2605: Possible error message improvement when -XRankNTypes is missing --------------------------------+------------------------------------------- Reporter: kaol | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: trivial Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- I'm forwarding wishlist bug [http://bugs.debian.org/499217 #499217] from Debian's BTS. ---- If I ask ghc to interpret a higher-rank function type, I get this error: {{{ Prelude> :t undefined :: ((forall a . a -> a) -> a -> a) :1:24: Illegal operator `.' in type `forall a . (a -> a)' (Use -XTypeOperators to allow operators in types) }}} If I turn on -XExistentialQuantification, I get this one instead: {{{ Prelude> :t undefined :: ((forall a . a -> a) -> a -> a) :1:0: Illegal polymorphic or qualified type: forall a. a -> a In an expression type signature: (forall a. a -> a) -> a -> a }}} It might not be possible in the first case (where forall isn't a keyword), but in the second case it would be nice if ghc could detect my attempt to enter a higher-rank type and suggest the appropriate extension. (-XRankNTypes) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 06:18:16 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 06:23:20 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.2e074baec1212ec50b2815406800c661@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Comment (by simonmar): Sorry for this late review, and I'm not sure why I didn't pick this up before, but I think this patch has some problems. * we shouldn't be extending the `Foreign.ForeignPtr` API, as it is set in stone by the FFI spec and would need at the very least a library proposal to change it. I had imagined that we would keep the same API, and just implement C finalizers differently. * The implementation doesn't seem to respect the ordering of finalizers. Finalizers are supposed to run in the same order that they were added to the `ForeignPtr` (which is why we have that horrible `IORef` attached to `ForeignPtr`s). It looks like C finalizers will run in an arbitrary order. Once again, I'm sorry for picking this up so late. I thought I'd reviewed the patch earlier, but I guess I didn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 07:38:32 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 07:36:31 2008 Subject: [GHC] #2605: Possible error message improvement when -XRankNTypes is missing In-Reply-To: <043.1c39b7a94fa4d25aff9e796ce2606603@localhost> References: <043.1c39b7a94fa4d25aff9e796ce2606603@localhost> Message-ID: <052.44a3a255035ecf04ee137911bed2dd9e@localhost> #2605: Possible error message improvement when -XRankNTypes is missing -----------------------------+---------------------------------------------- Reporter: kaol | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: The HEAD (and hence 6.10) are already better in this respect: {{{ :t undefined :: ((forall a . a -> a) -> a -> a) :1:24: Illegal operator `.' in type `forall a . (a -> a)' Perhaps you intended to use -XRankNTypes or similar flag to enable explicit-forall syntax: forall . Prelude> :set -XExistentialQuantification Prelude> :t undefined :: ((forall a . a -> a) -> a -> a) :1:0: Illegal polymorphic or qualified type: forall a. a -> a Perhaps you intended to use -XRankNTypes or -XRank2Types In an expression type signature: (forall a. a -> a) -> a -> a In the expression: undefined :: (forall a. a -> a) -> a -> a Prelude> }}} Is that better? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 07:53:38 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 07:51:10 2008 Subject: [GHC] #2598: Avoid excessive specialisation in SpecConstr In-Reply-To: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> References: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> Message-ID: <055.0448d6bf19857305ca2f759543f58dcd@localhost> #2598: Avoid excessive specialisation in SpecConstr -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by rl): It might actually be better to decide whether to specialise or not depending on how an argument is used in the function instead of what it is bound to in a call. So for dropComment we'd see: {{{ dropComment xs = case xs of [] -> [] x:xs -> }}} Now, we might decide that specialising for `dropComment (x:xs)` isn't worth it because we will only get rid of the one `case` which doesn't buy us much. I have no idea what the exact heuristic should be but since we are worried about code size that should probably be the main criterion. BTW, the five tiny specialisations are only kept alive by rules. For instance: {{{ $sdropComment3 xs c = '-' : dropComment2 xs c "SC:dropComment5" forall xs c. dropComment ('-' : '-': c : xs) = dropComment3 xs c }}} Since dropComment3 is very small and the only reference to it is on the rhs of the rule, I can easily imagine a pass which simply inlines it there and drops the binding. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 09:35:21 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 09:32:58 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.807222bd961c8368e3ed35ec438b30f0@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Changes (by simonmar): * status: reopened => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 09:37:57 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 09:35:44 2008 Subject: [GHC] #2596: Token concatentation (##) in C preprocessor In-Reply-To: <048.ab4f0681bbb3541df391c141fc8c9414@localhost> References: <048.ab4f0681bbb3541df391c141fc8c9414@localhost> Message-ID: <057.f2a2c8497ce1c9c1edd6c461ef9ce66b@localhost> #2596: Token concatentation (##) in C preprocessor -----------------------------+---------------------------------------------- Reporter: sedillard | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Malcolm is right... closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 11:22:00 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 11:19:30 2008 Subject: [GHC] #2605: Possible error message improvement when -XRankNTypes is missing In-Reply-To: <043.1c39b7a94fa4d25aff9e796ce2606603@localhost> References: <043.1c39b7a94fa4d25aff9e796ce2606603@localhost> Message-ID: <052.6ee7a8fdaa583570e41e32cb300cb16c@localhost> #2605: Possible error message improvement when -XRankNTypes is missing -----------------------------+---------------------------------------------- Reporter: kaol | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by kaol): * status: new => closed * resolution: => fixed Comment: I'm closing the ticket, since the Debian bug submitter was happy with the new message. Thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 11:31:08 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 11:28:35 2008 Subject: [GHC] #2326: Make configure check sockaddr.sa_len In-Reply-To: <044.969b2b3410986b0157b91f1ec2efd379@localhost> References: <044.969b2b3410986b0157b91f1ec2efd379@localhost> Message-ID: <053.3427307d9876d1b44c34fe57d7443d8b@localhost> #2326: Make configure check sockaddr.sa_len -------------------------------+-------------------------------------------- Reporter: iquiw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/network | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Pushed, thanks! {{{ Sun Jun 1 09:44:51 BST 2008 Iku Iwasa * Check sockaddr.sa_len by configure }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 14:17:56 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 14:15:22 2008 Subject: [GHC] #2555: Template Haskell does not respect -package and -hide constraints In-Reply-To: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> References: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> Message-ID: <053.2d089adaa31df82bdb9950670bfed626@localhost> #2555: Template Haskell does not respect -package and -hide constraints ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Comment (by guest): I think I described it thoroughly; reproducing it requires carefully installing a package or two, and I'm not going to risk screwing up my installation yet again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 19:20:19 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 19:17:46 2008 Subject: [GHC] #2005: localhost on mac causes getnameinfo error in safari. In-Reply-To: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost> References: <043.2e0e6309ca162e2f7e3751b621e7afca@localhost> Message-ID: <052.f4561f592c848f81e48b98d66653550a@localhost> #2005: localhost on mac causes getnameinfo error in safari. ------------------------------------+--------------------------------------- Reporter: alex | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: network localhost ipv6 | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ------------------------------------+--------------------------------------- Changes (by judah): * status: new => closed * resolution: => fixed Comment: This has been fixed by #2326 (works for me on OS X 10.5.4 with ghc-6.9.20080917). That ticket addresses the issues I described in my email above. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 22:35:20 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 22:32:56 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD Message-ID: <042.c2c283bd011173c80eba1a908d5990b1@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.9 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- {{{ $ ghci GHCi, version 6.9.20080912: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> a^? [RET] :1:3: lexical error at character '\DEL' }}} When I pressed my Backspace key, the {{{^?}}} showed up. When I pressed Delete, {{{^[[3~}}} showed up and ghci apparently thought I'd typed an {{{'\ESC'}}}. Arrow keys didn't work either (also seemed to be mapped to {{{'\ESC'}}} and {{{Ctrl-U}}} seemed to send a {{{'\NAK'}}}. However, when I hit {{{Ctrl-Z}}} to suspend ghci and then brought it back to the foreground, all the keys started working. * everything works fine if I start ghci in a shell in emacs, instead of in an xterm (in the latter, {{{$TERM=xterm}}} * emacs sets {{{$TERM}}} to "dumb", so I tried executing {{{declare -x TERM=dumb}}} and then starting ghci in an xterm, but the keys still didn't work * declaring {{{TERM}}} as {{{vt100}}} didn't work either. * Ubuntu 7.10 with xmonad (I think 0.3), if that helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 22:38:23 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 22:35:52 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.a0a5978c24082cb485c6e6b955ddb990@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by tim): By the way, xev says my backspace key is sending keycode 22/keysym 0xff08/BackSpace, and the delete key is sending keycode 107/keysym 0xffff/Delete. Obviously all the keys work in ghci 6.8.2 and in other apps. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 23:20:18 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 23:17:46 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.0e88e0b79ea9e061ded4c1d3f2b43381@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by judah): Do you reproduce the bug by opening up an xterm, and then typing 'ghci'? If so, what happens when you type "stty -a" in the xterm? Alternately, if you start ghci in such a way as to reproduce the bug, what happens when you run the following commands from inside ghci: {{{ System.IO.hIsTerminalDevice System.IO.stdin System.IO.hIsTerminalDevice System.IO.stdout System.Environment.getEnv "TERM" }}} Finally: what version of libedit are you building against? I suspect that some part of your xterm configuration is not set quite right, causing libedit to think that it's not inside a terminal. But it's strange that readline (used in ghc-6.8.2) isn't affected. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 17 23:30:33 2008 From: trac at galois.com (GHC) Date: Wed Sep 17 23:28:01 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.8f6eb0502b6d761452c01629476b6eec@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by tim): Replying to [comment:2 judah]: > Do you reproduce the bug by opening up an xterm, and then typing 'ghci'? If so, what happens when you type "stty -a" in the xterm? Yes. "stty -a" says: {{{ speed 38400 baud; rows 41; columns 89; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke }}} If I enter ghci, hit Ctrl-Z, and bring it back in the foreground so the keys start working again, and then type {{{:!stty -a}}}, the output looks exactly the same to me as before entering ghci. > Alternately, if you start ghci in such a way as to reproduce the bug, what happens when you run the following commands from inside ghci: > > {{{ > System.IO.hIsTerminalDevice System.IO.stdin True > System.IO.hIsTerminalDevice System.IO.stdout True > System.Environment.getEnv "TERM" "xterm" The values for these are the same both while the bug is exhibiting itself, and after suspending and re-activating ghci. > Finally: what version of libedit are you building against? > {{{ $ ls -lh /usr/lib/libedit.* lrwxrwxrwx 1 root root 14 2008-08-02 23:20 /usr/lib/libedit.so.2 -> libedit.so.2.9 -rw-r--r-- 1 root root 106K 2007-04-27 09:39 /usr/lib/libedit.so.2.9 }}} and I don't have any other versions floating around. I've never had problems with key mappings on this computer that I can recall, except for now with the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 18 05:11:07 2008 From: trac at galois.com (GHC) Date: Thu Sep 18 05:08:31 2008 Subject: [GHC] #2607: Inlining defeats selector thunk optimisation Message-ID: <047.c7531631c6a975d610c9a2ecacd7519d@localhost> #2607: Inlining defeats selector thunk optimisation -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- From a [http://www.haskell.org/pipermail/haskell- cafe/2008-September/047665.html post on haskell-cafe]. Lev Walkin wrote: > I wondered why would a contemporary GHC 6.8.3 exhibit such a leak? > After all, the technique was known in 2000 (and afir by Wadler in '87) > and one would assume Joe English's reference to "most other Haskell > systems" ought to mean GHC. Thanks for this nice example - Don Stewart pointed me to it, and Simon PJ and I just spent some time this morning diagnosing it. Incedentally, with GHC 6.8 you can just run the program with "+RTS -hT" to get a basic space profile, there's no need to compile it for profiling - this is tremendously useful for quick profiling jobs. And in this case we see the the heap is filling up with (:) and Tree constructors, no thunks. Here's the short story: GHC does have the space leak optimisation you refer to, and it is working correctly, but it doesn't cover all the cases you might want it to cover. In particular, optimisations sometimes interact badly with the space leak avoidance, and that's what is happening here. We've known about the problem for some time, but this is the first time I've seen a nice small example that demonstrates it. {{{ > -- Lazily build a tree out of a sequence of tree-building events > build :: [TreeEvent] -> ([UnconsumedEvent], [Tree String]) > build (Start str : es) = > let (es', subnodes) = build es > (spill, siblings) = build es' > in (spill, (Tree str subnodes : siblings)) > build (Leaf str : es) = > let (spill, siblings) = build es > in (spill, Tree str [] : siblings) > build (Stop : es) = (es, []) > build [] = ([], []) }}} So here's the long story. Look at the first equation for build: {{{ > build (Start str : es) = > let (es', subnodes) = build es > (spill, siblings) = build es' > in (spill, (Tree str subnodes : siblings)) }}} this turns into {{{ x = build es es' = fst x subnodes = snd x y = build es' spill = fst y siblings = snd y }}} now, it's the "siblings" binding we're interested in, because this one is never demanded - in this example, "subnodes" ends up being an infinite list of trees, and we never get to evaluate "siblings". So anything referred to by siblings will remain in the heap. The space-leak avoidance optimisation works on all those "fst" and "snd" bindings: in a binding like "siblings = snd y", when y is evaluated to a pair, the GC will automatically reduce "snd y", so releasing the first component of the pair. This all works fine. But the optimiser sees the above code and spots that es' only occurs once, in the right hand side of the binding for y, and so it inlines it. Now we have {{{ x = build es subnodes = snd x y = build (fst x) spill = fst y siblings = snd y }}} Now, usually this is a good idea, but in this case we lost the special space-leak avoidance on the "fst x" expression, because it is now embedded in an expression. In fact in this case the thunk goes away entirely, because build is strict. But now, when the program runs, the thunk for siblings retains y, which retains x, which evaluates to a pair, the second component of which evaluates to an infintely growing list of Trees (the first components is a chain of "fst y" expressions that constantly get reduced by the GC and don't take up any space). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 18 05:26:04 2008 From: trac at galois.com (GHC) Date: Thu Sep 18 05:23:27 2008 Subject: [GHC] #2608: Direct support for unit tests in Cabal Message-ID: <043.0f910c87967bdcd72df76a06d6dc0fa6@localhost> #2608: Direct support for unit tests in Cabal -------------------------+-------------------------------------------------- Reporter: kaol | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.6.1 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- I'm passing along Debian wishlist bug [http://bugs.debian.org/458495 #458495] for your consideration. The patch is for version 6.6.1 and it won't apply cleanly on HEAD, but I can adapt it to HEAD if you think it's worth having. I didn't look overly much if something like this has been already implemented. My apologies if this is just more noise. ---- It would be nice if there was a simple way to build and run tests for Cabalized packages. Cabal provides a "test" target, but by default it does nothing. Furthermore, you can't really build test cases using the Cabal infrastructure, since any executables that you list get installed. Searching on Google for how to integrate a test suite into Cabal turns up suggestions such as "make a system() call from runTests to The attached patch adds two new flags to the build information for executables and libraries: {{{ * do-not-install: if set to True, keeps an executable that it's set on from being installed. This is necessary to keep test suites from ending up in $prefix/bin, but may be useful for other build-time utilities. * is-test: if set to True on an executable, the executable will be invoked by the "test" target of the setup script. Note that this doesn't attempt to be at all smart about building the executable(s); it just blindly invokes the test command(s) and returns a failure if any of them fail. }}} The patch should be fairly straightforward. The need to do suppression of installing executables in compiler-specific code is a bit ugly; this could maybe be cleaned up with an equivalent to withExe that drops non-installed executables and by writing and using a similar routine for libraries. This also changes the API of Cabal: runTests now takes an integer as its first argument, indicating the verbosity level provided as an argument on the command-line. The Boolean that was passed before didn't have any purpose I could see and was always False, so it shouldn't be hard to adapt existing code to this change. On the other hand, the API can be preserved by just hard-coding a verbosity level. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 18 09:33:14 2008 From: trac at galois.com (GHC) Date: Thu Sep 18 09:30:39 2008 Subject: [GHC] #1502: GHC should integrate better with mingw In-Reply-To: <047.b7395f3fc65ee001157bf44a9570b106@localhost> References: <047.b7395f3fc65ee001157bf44a9570b106@localhost> Message-ID: <056.320793c9cc4d09bb670936f7b65cdc7f@localhost> #1502: GHC should integrate better with mingw -----------------------------+---------------------------------------------- Reporter: eivuokko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: windows | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------+---------------------------------------------- Comment (by claus): Instead of including the mingw installer, how about preserving the internal directory layout of the bits of mingw that get included? That would avoid the need for extra `-B` flags in ghc, cabal, hsc2hs, .., it would make gcc much less prone to picking up the wrong executables/libraries/include files from other places, allowing it to work as intended (its build-in paths start searching relative to the gcc executable, allowing relocation). See this cvs-ghc thread for more details: ghc head on windows: gcc.exe: installation problem, cannot exec `cc1': No such file or directory http://www.haskell.org/pipermail/cvs-ghc/2008-September/045161.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 18 09:58:57 2008 From: trac at galois.com (GHC) Date: Thu Sep 18 09:56:19 2008 Subject: [GHC] #2555: Template Haskell does not respect -package and -hide constraints In-Reply-To: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> References: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> Message-ID: <053.98b10765646a21df2ef1ac57c1295909@localhost> #2555: Template Haskell does not respect -package and -hide constraints ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * milestone: 6.10 branch => 6.12 branch Comment: OK. If you come across it again, please let us know and we'll take the opportunity to get more specific info. Meanwhile, we're stuck. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 18 11:24:55 2008 From: trac at galois.com (GHC) Date: Thu Sep 18 11:22:23 2008 Subject: [GHC] #738: ghc can't load files with selinux Enforcing In-Reply-To: <065.24a0770a4c910c3e35b946b29e1c1608@localhost> References: <065.24a0770a4c910c3e35b946b29e1c1608@localhost> Message-ID: <074.33a56e35fe74fe551e2c5cb04813d5a9@localhost> #738: ghc can't load files with selinux Enforcing ----------------------------------------+----------------------------------- Reporter: jon.fairbairn@cl.cam.ac.uk | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: selinux | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Changes (by simonmar): * priority: high => normal Comment: Couple of notes: * Fedora is shipping with `allow_execmem` turned on these days, so the issue only affects people that turn it off manually. * In order to reproduce the problem, you need to turn off both `allow_execmem` and `allow_execstack` using `setsebool`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 18 12:03:58 2008 From: trac at galois.com (GHC) Date: Thu Sep 18 12:01:20 2008 Subject: [GHC] #2609: Compiling with -O2 is 7x slower than -O Message-ID: <046.42ce6b19d1fdc31890e2bf896b97f4f5@localhost> #2609: Compiling with -O2 is 7x slower than -O ---------------------------------------------+------------------------------ Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------------------+------------------------------ Serge writes that compiling !DoCon with `-O2 -fvia-C` "does not gain more performance, but leads to 7 times longer compilation". That seems a big slow down, worth looking into. The offending !DoCon bundle is attached -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 18 12:24:04 2008 From: trac at galois.com (GHC) Date: Thu Sep 18 12:21:26 2008 Subject: [GHC] #2604: Suggest -XDeriveDataTypeable with "newtype" too In-Reply-To: <043.b1f1671247f6c4e384c3ee43b1a2000a@localhost> References: <043.b1f1671247f6c4e384c3ee43b1a2000a@localhost> Message-ID: <052.35d81fe371fb7dcf72833e105e64bc53@localhost> #2604: Suggest -XDeriveDataTypeable with "newtype" too ----------------------------------------+----------------------------------- Reporter: kaol | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2604 | Architecture: Unknown Os: Unknown | ----------------------------------------+----------------------------------- Changes (by simonpj): * testcase: => deriving/should_fail/T2604 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: At last! A bug I can fix quickly! Thanks for the suggestion. {{{ Wed Sep 17 14:51:04 BST 2008 simonpj@microsoft.com * Improve error reporting for 'deriving' (Trac #2604) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 18 12:27:24 2008 From: trac at galois.com (GHC) Date: Thu Sep 18 12:24:56 2008 Subject: [GHC] #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) In-Reply-To: <052.784670e095eb0d591995e903dae303b2@localhost> References: <052.784670e095eb0d591995e903dae303b2@localhost> Message-ID: <061.14c60305025d6e93235f23bc405f0a90@localhost> #955: more object-code blow-up in ghc-6.8.3 vs. ghc-6.4.2 (both with optimization) --------------------------------------+------------------------------------- Reporter: maeder@tzi.de | Owner: Type: run-time performance bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: object-code blow-up | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------------+------------------------------------- Comment (by simonpj): Just to say that I've now fixed those odd WARNINGs too. {{{ Wed Sep 17 17:29:10 BST 2008 simonpj@microsoft.com * Fix nasty infelicity: do not short-cut empty substitution in the simplifier I was perplexed about why an arity-related WARN was tripping. It took me _day_ (sigh) to find that it was because SimplEnv.substExpr was taking a short cut when the substitution was empty, thereby not subsituting for Ids in scope, which must be done (CoreSubst Note [Extending the Subst]). The fix is a matter of deleting the "optimisation". Same with CoreSubst.substSpec, although I don't know if that actually caused a problem. }}} Great to have this ticket closed at last. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 18 13:28:48 2008 From: trac at galois.com (GHC) Date: Thu Sep 18 13:26:13 2008 Subject: [GHC] #2610: File permission-related proposals Message-ID: <044.2484ad9dcf80cd653040fb3392e0b3ab@localhost> #2610: File permission-related proposals -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Once 6.10 is out of the way, we should file some permission-related proposals. `openTempFile` and `openBinaryTempFile` mask the file permissions of the file they create with 0o600. However, we would like to use it for implementing things like `writeFileAtomic`, in which case we want the default file permissions to be used. `System.Directory` has an internal `copyPermissions` function, but it should be exported. This is not the same as `getPermissions s >>= setPermissions d` as the Permissions type that the latter uses doesn't hold all the permissions info that we want. Even better would be to make the Permissions type abstract, so that it /can/ contain all the info we want. Functions in the unix and Win32 packages would be able to do more with this type than the portable interface. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 18 17:00:59 2008 From: trac at galois.com (GHC) Date: Thu Sep 18 16:58:20 2008 Subject: [GHC] #2611: print022 fails Message-ID: <044.04df65fcd08934af446e85568f6b956a@localhost> #2611: print022 fails ------------------------+--------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: print022 Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- print022 fails: {{{ -test = C 1 32 1.2 1.23 'x' 1 1.2 1.23 +test = C 1 32 1.2 1.23 'x' (I# 1) (F# 1.2) (D# 1.23) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 18 20:57:07 2008 From: trac at galois.com (GHC) Date: Thu Sep 18 20:54:33 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.34a62048587cf21ccd36d6d91d98ce95@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Comment (by Svarog): Replying to [comment:12 simonmar]: I've just uploaded updated patches for the base lib, the testsuite and ghc to address these issues. The new ghc patch just adds a comment in Weak.c to mention that finalizers rely on weak pointers in weak_ptr_list always being in the same order (which is currently the case). > * we shouldn't be extending the `Foreign.ForeignPtr` API, as it is set in stone > by the FFI spec and would need at the very least a library proposal to > change it. I had imagined that we would keep the same API, and just implement C > finalizers differently. > As discussed on IRC, addForeignPtrFinalizer only needs to work with C functions so I renamed addForeignPtrFinalizerC to addForeignPtrFinalizer. That way the API stays the same. To use Haskell finalizers addForeignPtrConcFinalizer should be used. > * The implementation doesn't seem to respect the ordering of finalizers. > Finalizers are supposed to run in the same order that they were added to the > `ForeignPtr` (which is why we have that horrible `IORef` attached to > `ForeignPtr`s). It looks like C finalizers will run in an arbitrary order. > Weak pointers are always kept in the same order and each C finalizer is attached to its own weak pointer. All C finalizers attached to a particular `ForeignPtr` should execute in correct order. I've updated one of the tests in the testsuite to check for this. As discussed on IRC I added code that throws a run-time error if Haskell and C finalizers are mixed on the same `ForeignPtr`. I've added another test to the testsuite to check this as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 04:35:04 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 04:32:32 2008 Subject: [GHC] #2600: Bind type variables in RULES In-Reply-To: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> References: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> Message-ID: <055.0cd1f363834ba17f18caf35a242326f2@localhost> #2600: Bind type variables in RULES -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by simonpj): One other syntactic question: what if there are multiple type binders? We could say {{{ forall (type a :: *) (type b :: *) (f :: a->b). }}} or perhaps just one `type` keyword to introduce all type binders? But then you'd need something to say when the type binders stopped. A semicolon perhaps? {{{ forall type (a :: *) (b :: *); (f :: a->b). }}} More syntactic suggestions welcome. Once we have the syntax, the implementation should not be hard. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 06:54:02 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 06:51:23 2008 Subject: [GHC] #1470: Overlapping (etc) instances In-Reply-To: <044.7e52c8915b05c8e43ff459f8657b2c84@localhost> References: <044.7e52c8915b05c8e43ff459f8657b2c84@localhost> Message-ID: <053.a34514cd93028ba1aad1f41852ec76f7@localhost> #1470: Overlapping (etc) instances -------------------------------------+-------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Thu Sep 18 17:17:19 GMT Daylight Time 2008 simonpj@microsoft.com * Fix Trac #1470: improve handling of recursive instances (needed for SYB3) This bug has been hanging around for a long time, as you'll see by its number. The fix implements a feature that is really needed by SYB3, to allow an instance to (rather indirectly) refer to itself. The trickiness comes when solving the superclass constraints. The whoel issue is explained in Note [Recursive instances and superclases] in TcSimplify. In cracking this one I found I could remove the WantSCs argument to the ReduceMe flag, which is a worthwhile simplification. Good! }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 07:03:30 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 07:00:50 2008 Subject: [GHC] #2612: deriving Data.Typeable on phantom newtypes does not report that DeriveDataTypeable is needed Message-ID: <044.048feab55bc14d27622fab689e081bdf@localhost> #2612: deriving Data.Typeable on phantom newtypes does not report that DeriveDataTypeable is needed -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- newtype Foo x = Foo deriving (Typeable) reports the rather cryptic error message: Can't make a derived instance of `Typeable (Foo x)' (even with cunning newtype deriving:) In the newtype declaration for `Foo' When newtype is replaced with data, this much more useful error message is given: Can't make a derived instance of `Typeable (Foo x)' (You need -XDeriveDataTypeable to derive an instance for this class) In the data type declaration for `Foo' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 07:03:41 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 07:01:02 2008 Subject: [GHC] #2612: deriving Data.Typeable on phantom newtypes does not report that DeriveDataTypeable is needed In-Reply-To: <044.048feab55bc14d27622fab689e081bdf@localhost> References: <044.048feab55bc14d27622fab689e081bdf@localhost> Message-ID: <053.51d8e07949d4a9ac4fa71ead5f6d3a73@localhost> #2612: deriving Data.Typeable on phantom newtypes does not report that DeriveDataTypeable is needed -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Changes (by guest): * cc: tom.davie@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 07:20:01 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 07:17:22 2008 Subject: [GHC] #2612: deriving Data.Typeable on phantom newtypes does not report that DeriveDataTypeable is needed In-Reply-To: <044.048feab55bc14d27622fab689e081bdf@localhost> References: <044.048feab55bc14d27622fab689e081bdf@localhost> Message-ID: <053.f658848e45c39668abc6e76eacbd1f6a@localhost> #2612: deriving Data.Typeable on phantom newtypes does not report that DeriveDataTypeable is needed ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Thanks for the suggestion. Happily this is already done: see #2604. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 07:20:11 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 07:17:32 2008 Subject: [GHC] #2612: deriving Data.Typeable on phantom newtypes does not report that DeriveDataTypeable is needed In-Reply-To: <044.048feab55bc14d27622fab689e081bdf@localhost> References: <044.048feab55bc14d27622fab689e081bdf@localhost> Message-ID: <053.e31f379e0727f4b79113ac7893a2e1b9@localhost> #2612: deriving Data.Typeable on phantom newtypes does not report that DeriveDataTypeable is needed ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 08:01:25 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 07:58:45 2008 Subject: [GHC] #1875: Compiling with -O is 30 times slower than with -Onot In-Reply-To: <046.51ad0647d4145de0c60e9541c64632d5@localhost> References: <046.51ad0647d4145de0c60e9541c64632d5@localhost> Message-ID: <055.b09c4bd465aa87e2f81a968659f04c27@localhost> #1875: Compiling with -O is 30 times slower than with -Onot ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: compile-time performance bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Fixed at last {{{ Wed Sep 3 13:02:28 BST 2008 simonpj@microsoft.com * Major change in compilation of instance declarations (fix Trac #955, #2328) }}} I'm assuming this is the same as #955, #2328. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 08:57:38 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 08:54:58 2008 Subject: [GHC] #2602: Haddock not installed properly In-Reply-To: <051.bff77834b377c6ec330f589afeeee640@localhost> References: <051.bff77834b377c6ec330f589afeeee640@localhost> Message-ID: <060.ceaa8ef1e34aea579e9b77a26dc79fa1@localhost> #2602: Haddock not installed properly -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- Comment (by claus): the haddock package (what does that do, btw?) is also not installed correctly, pointing to build directories instead of installation directories: {{{ $ type -a ghc-pkg ghc-pkg is /cygdrive/c/ghc/ghc-6.9.20080918/bin/ghc-pkg $ ghc-pkg.exe describe haddock name: haddock version: 2.2.2 license: BSD3 copyright: (c) Simon Marlow, David Waern maintainer: David Waern stability: experimental homepage: http://www.haskell.org/haddock/ package-url: description: Haddock is a documentation-generation tool for Haskell libraries category: Development author: Simon Marlow, David Waern exposed: True exposed-modules: Distribution.Haddock hidden-modules: Haddock.Types Haddock.InterfaceFile Haddock.Exception import-dirs: d:/fptools/ghc/ghc-6.9.20080918\haddock-2.2.2 library-dirs: d:/fptools/ghc/ghc-6.9.20080918\haddock-2.2.2 hs-libraries: HShaddock-2.2.2 extra-libraries: extra-ghci-libraries: include-dirs: includes: depends: Cabal-1.5.4 array-0.1 base-4.0 containers-0.1 directory-1.0 filepath-1.1 ghc-6.9.20080918 haskell98-1.0.1 pretty-1.0 hugs-options: cc-options: ld-options: framework-dirs: frameworks: haddock-interfaces: haddock.haddock haddock-html: d:/fptools/ghc/ghc-6.9.20080918/doc }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 09:32:35 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 09:29:55 2008 Subject: [GHC] #2613: configure should summarize important results at the end of its run Message-ID: <044.0889aaee930d9a4ce299cdd9f349c45b@localhost> #2613: configure should summarize important results at the end of its run --------------------------------+------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Component: Build System Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- `./configure` in ghc head produces a lot of output, including lots of detailed checks that tend to scroll away the more major results near the beginning. It would be useful if the most important points (which ghc/gcc/tools/.. are going to be used; which features are disabled because of missing tools) were summarized at the end of the configure run. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 09:44:10 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 09:41:31 2008 Subject: [GHC] #2613: configure should summarize important results at the end of its run In-Reply-To: <044.0889aaee930d9a4ce299cdd9f349c45b@localhost> References: <044.0889aaee930d9a4ce299cdd9f349c45b@localhost> Message-ID: <053.ef0b49dc78fc9100bc2960a7f26cf936@localhost> #2613: configure should summarize important results at the end of its run --------------------------------+------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 09:55:26 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 09:52:45 2008 Subject: [GHC] #1502: GHC should integrate better with mingw In-Reply-To: <047.b7395f3fc65ee001157bf44a9570b106@localhost> References: <047.b7395f3fc65ee001157bf44a9570b106@localhost> Message-ID: <056.18fe563e9d4ed20d2587405943aca3bc@localhost> #1502: GHC should integrate better with mingw -----------------------------+---------------------------------------------- Reporter: eivuokko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: windows | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------+---------------------------------------------- Comment (by claus): Preserving the mingw structure within ghc would also keep the mingw tools out of ghc's bin directory! A current ghc head has: {{{ $ ls /cygdrive/c/ghc/ghc-6.9.20080918/bin/ ar.exe* ghci.exe* hasktags.exe* hsc2hs.exe* windres.exe* ghc-pkg.exe* ghcii.sh* hp2ps.exe* installPackage.exe* ghc.exe* haddock.exe* hpc.exe* runghc.exe* $ ls /cygdrive/c/ghc/ghc-6.9.20080918/*.exe /cygdrive/c/ghc/ghc-6.9.20080918/gcc.exe* /cygdrive/c/ghc/ghc-6.9.20080918/touchy.exe* /cygdrive/c/ghc/ghc-6.9.20080918/perl.exe* /cygdrive/c/ghc/ghc-6.9.20080918/unlit.exe* $ ls /cygdrive/c/ghc/ghc-6.9.20080918/gcc-lib/*.exe /cygdrive/c/ghc/ghc-6.9.20080918/gcc-lib/as.exe* /cygdrive/c/ghc/ghc-6.9.20080918/gcc-lib/cc1.exe* /cygdrive/c/ghc/ghc-6.9.20080918/gcc-lib/cc1plus.exe* /cygdrive/c/ghc/ghc-6.9.20080918/gcc-lib/collect2.exe* /cygdrive/c/ghc/ghc-6.9.20080918/gcc-lib/dlltool.exe* /cygdrive/c/ghc/ghc-6.9.20080918/gcc-lib/dllwrap.exe* /cygdrive/c/ghc/ghc-6.9.20080918/gcc-lib/ld.exe* }}} So, if I want to use that ghc, I have to put its path after my local mingw one (or I will pick up the wrong versions) in which case ghc might pick the wrong versions (unless it has the relative paths hardcoded, as is likely; in which case it doesn't need ar/windres in its own bin/). If that stuff ended up not in `ghc-/bin`, but in `ghc-/mingw/bin` (or `ghc-/mingw/libexec/...`), wouldn't everything get simpler? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 10:02:27 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 09:59:47 2008 Subject: [GHC] #1502: GHC should integrate better with mingw In-Reply-To: <047.b7395f3fc65ee001157bf44a9570b106@localhost> References: <047.b7395f3fc65ee001157bf44a9570b106@localhost> Message-ID: <056.5a080657571bb126f1e25d84dabf6b37@localhost> #1502: GHC should integrate better with mingw -----------------------------+---------------------------------------------- Reporter: eivuokko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: windows | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------+---------------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) Comment: I agree with Claus here, GHC should ship its own minimal version of the necessary mingw tools, which is private to GHC. This would simplify the Windows Building instructions, and reduce the number of obvious mistakes people can make. People who want Mingw should install their own separate copy - if GHC tries to reuse an existing installation it becomes much more fragile with version shift. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 11:22:24 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 11:19:46 2008 Subject: [GHC] #1502: GHC should integrate better with mingw In-Reply-To: <047.b7395f3fc65ee001157bf44a9570b106@localhost> References: <047.b7395f3fc65ee001157bf44a9570b106@localhost> Message-ID: <056.905667f322dd8f5ded5436c3fd49bcfd@localhost> #1502: GHC should integrate better with mingw -----------------------------+---------------------------------------------- Reporter: eivuokko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: windows | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------+---------------------------------------------- Changes (by simonmar): * milestone: 6.12 branch => 6.10.2 Comment: We agree, but it's too late to make this change for 6.10.1. Moving to the 6.10.2 milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 11:47:16 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 11:44:42 2008 Subject: [GHC] #738: ghc can't load files with selinux Enforcing In-Reply-To: <065.24a0770a4c910c3e35b946b29e1c1608@localhost> References: <065.24a0770a4c910c3e35b946b29e1c1608@localhost> Message-ID: <074.d0d09afa22d2557eca82bfd56b47f2c2@localhost> #738: ghc can't load files with selinux Enforcing ----------------------------------------+----------------------------------- Reporter: jon.fairbairn@cl.cam.ac.uk | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: selinux | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Changes (by simonmar): * status: reopened => closed * resolution: => fixed Comment: Ok, it turned out to be not as hard as I thought it might be. But libffi doesn't appear to support doing executable allocation on Windows, so we had to retain the old mechanism for that. I wasn't sure whether it would work on the other Unix-like OSs either, so I've enabled the libffi allocator only for Linux at the moment. {{{ Fri Sep 19 14:46:02 BST 2008 Simon Marlow * On Linux use libffi for allocating executable memory (fixed #738) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 11:58:22 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 11:55:52 2008 Subject: [GHC] #2585: New versions of windres fail with "windres: CreateProcess (null): No error" In-Reply-To: <044.25b69fd7b594ae443d31576c538df3be@localhost> References: <044.25b69fd7b594ae443d31576c538df3be@localhost> Message-ID: <053.1cc309869a527d36ee008bb1d8865634@localhost> #2585: New versions of windres fail with "windres: CreateProcess (null): No error" ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): Just a note - to reproduce this problem you need to use an installed binary distribution, because otherwise windres doesn't get passed the offending -B option that causes quoting issues. I haven't reproduced it yet, but I noticed that it doesn't seem to occur with a standard validate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 19 12:04:32 2008 From: trac at galois.com (GHC) Date: Fri Sep 19 12:02:05 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.2e5cedf61cfab35dea80adeace69b070@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by judah): Replying to [comment:3 tim]: > Replying to [comment:2 judah]: > > Do you reproduce the bug by opening up an xterm, and then typing 'ghci'? If so, what happens when you type "stty -a" in the xterm? > > Yes. "stty -a" says: (...) > > If I enter ghci, hit Ctrl-Z, and bring it back in the foreground so the keys start working again, and then type {{{:!stty -a}}}, the output looks exactly the same to me as before entering ghci. > Just to clarify: what happens when you type :!stty -a from inside ghci immediately after entering ghci? > I've never had problems with key mappings on this computer that I can recall, except for now with the HEAD. I suspect this is a problem with libedit, since HEAD replaced readline with it it between 6.8 and 6.10. Do you know of any other programs on your machine that use libedit and whether they have the same issue? Otherwise, would it be possible for you to compile the following C program (with {{{gcc -ledit}}}) and check its behavior inside the xterm? {{{ #include #include int main(void) { char *result; rl_initialize(); result = readline("enter:"); printf("%s\n",result); return 0; } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 02:55:17 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 02:52:45 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.8af5b3b1f244fbc7d4c5003f80795aab@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by tim): Replying to [comment:4 judah]: > Just to clarify: what happens when you type :!stty -a from inside ghci immediately after entering ghci? Still the same output as what I pasted. > I suspect this is a problem with libedit, since HEAD replaced readline with it it between 6.8 and 6.10. Do you know of any other programs on your machine that use libedit and whether they have the same issue? Otherwise, would it be possible for you to compile the following C program (with {{{gcc -ledit}}}) and check its behavior inside the xterm? > Done (I had to install libedit-dev first, but I don't think that had any other effects); your test program works fine (backspace, delete, Ctrl-U) work, when it's run in an xterm, but still the same problem with ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 04:39:58 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 04:37:15 2008 Subject: [GHC] #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` Message-ID: <043.429d5e175a90219c9682c6f3937cb586@localhost> #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` --------------------------------+------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Multiple --------------------------------+------------------------------------------- It is desirable to have an enumeration of values that might end up in `Sys.Info.os` and `Sys.Info.arch`. Only after much reading of Cabal files and such have I learnt that the former includes (at least) `linux`, `darwin`, `windows` and `freebsd`. (And not, for example, `win32`.) This is only a minor annoyance and I will likely never need to bother with it again -- though I guess I'm still not sure what Solaris is called -- probably `solaris` -- I've got the pattern now, but it would have been much better to see a list. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 05:27:39 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 05:24:56 2008 Subject: [GHC] #2597: panic! (the 'impossible' happened) (using TH) In-Reply-To: <043.059865a2ed72b6802d1466b05790ef9c@localhost> References: <043.059865a2ed72b6802d1466b05790ef9c@localhost> Message-ID: <052.040ccfbcabbf017d9b49a245419081e1@localhost> #2597: panic! (the 'impossible' happened) (using TH) ------------------------------+--------------------------------------------- Reporter: jcab | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Comment (by jcab): A-ha! I've reduced this to the minimal. It is caused by trying to expand list comprehensions: mkBug = returnQ $ CompE [BindS (VarP $ mkName "p") (ListE []), NoBindS (VarE $ mkName "p")] That simple template causes the panic (on 6.8.3) when invoked: bug = $mkBug My code seems to work correctly if I get the comprehensions eliminated at template-compile time so there are no comprehensions in the returned expression tree. BTW: defining comprehensions as "CompE [Stmt]" is... weird. Putting the two statements in the opposite order doesn't change the outcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 05:52:43 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 05:50:00 2008 Subject: [GHC] #2597: panic! (the 'impossible' happened) (using TH) In-Reply-To: <043.059865a2ed72b6802d1466b05790ef9c@localhost> References: <043.059865a2ed72b6802d1466b05790ef9c@localhost> Message-ID: <052.d4c291b249edf43cb2b1bf2c65c11a06@localhost> #2597: panic! (the 'impossible' happened) (using TH) ------------------------------+--------------------------------------------- Reporter: jcab | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Comment (by jcab): And yet another case that gives GHC the shivers: mkBug2 = returnQ $ DoE [] Granted, that's an incorrect tree, but... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 07:49:48 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 07:47:05 2008 Subject: [GHC] #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` In-Reply-To: <043.429d5e175a90219c9682c6f3937cb586@localhost> References: <043.429d5e175a90219c9682c6f3937cb586@localhost> Message-ID: <052.1b9ea7f370e87adbec1a324d819686ea@localhost> #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` --------------------------------+------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Multiple --------------------------------+------------------------------------------- Comment (by duncan): Cabal does use an enumeration, defined in `Distribution.System`. It also has equivalents of `System.Info.arch` and `os` but using the enumeration type. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 12:39:43 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 12:37:06 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.901368b080b850a1589647eefdc9f5cb@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by judah): Hmm, if you had to install libedit-dev to build that program then maybe ghc's editline bindings weren't built when you built ghc. Can you please check whether ghc's editline package is installed, for example by: - trying to run {{{:browse System.Console.Editline.Readline}}} inside ghci - double-checking whether the up/down arrow keys page through the ghci history If it's not installed, you can probably fix this problem by building ghc again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 14:06:43 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 14:04:00 2008 Subject: [GHC] #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` In-Reply-To: <043.429d5e175a90219c9682c6f3937cb586@localhost> References: <043.429d5e175a90219c9682c6f3937cb586@localhost> Message-ID: <052.1ffc12c4553ed0c5ec74652586b157d3@localhost> #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` --------------------------------+------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Multiple --------------------------------+------------------------------------------- Comment (by jsnx): Replying to [comment:1 duncan]: > Cabal does use an enumeration, defined in `Distribution.System`. It also has equivalents of `System.Info.arch` and `os` but using the enumeration type. The values defined in the Cabal enumeration do not have a clear relationship to those actually in Cabal files. * Where is `freebsd`? (I see it is in the latest Cabal, but was it neglected in the past? I don't think so...) * Can I write `if os(os x) ...` in a Cabal file? (I seem to have it as `darwin`.) Were it not for the fact that Cabal specifically points to `System.Info`, I would have filed this bug against Cabal. Even if Cabal provided everything, it is still desirable that the documentation for `System.Info` should mention its possible values. Some things will always be treasure hunts but this need not be one of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 14:17:46 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 14:15:02 2008 Subject: [GHC] #2609: Compiling with -O2 is 7x slower than -O In-Reply-To: <046.42ce6b19d1fdc31890e2bf896b97f4f5@localhost> References: <046.42ce6b19d1fdc31890e2bf896b97f4f5@localhost> Message-ID: <055.376a4142a295067c6ece5278fee81304@localhost> #2609: Compiling with -O2 is 7x slower than -O ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Comment (by simonpj): Ah, this seems to be to do with `-fviaC` ''not'' to do with `-O2`. Serge writes: With -O2, the compile time is ok, but when I add -fvia-C, it takes 7 times longer -- this is for ghc-6.9-earlySeptember to compile !DoCon-2.12-pre. You do not control over the speed of gcc itself. But a small change in the GHC compiler may, in principle, lead to many times faster compilation by gcc of the code produced by GHC. This may occur some problem in GHC as well as some problem in gcc. This is only my observation, I do not pretend for a bug report in this case. I tried -fvia-C for curiosity: "by occasion, would it increase the code performance?". If this ratio of 7 looks curious to you, you could investigate this. And personally, I am satisfied with -O (without via-C). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 15:46:55 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 15:44:23 2008 Subject: [GHC] #2582: We need to provide runhaskell In-Reply-To: <044.bc0e3a1ac868de2418ccb4b946617a88@localhost> References: <044.bc0e3a1ac868de2418ccb4b946617a88@localhost> Message-ID: <053.777e3b46e3e20d8d1748de764a601114@localhost> #2582: We need to provide runhaskell --------------------------+------------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 17:24:02 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 17:21:17 2008 Subject: [GHC] #2597: panic! (the 'impossible' happened) (using TH) In-Reply-To: <043.059865a2ed72b6802d1466b05790ef9c@localhost> References: <043.059865a2ed72b6802d1466b05790ef9c@localhost> Message-ID: <052.fdcfe51f421fdf3bcf4cb347c0ca885f@localhost> #2597: panic! (the 'impossible' happened) (using TH) ------------------------------+--------------------------------------------- Reporter: jcab | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: => simonpj Comment: Great report thank you. Actually there are two bugs, which I have fixed. I'll push a patch shortly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 18:51:00 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 18:48:16 2008 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts Message-ID: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> #2615: ghci doesn't play nice with linker scripts -------------------------------+-------------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- I'm trying to use HsHyperEstraier with ghci. I can compile and run the included examples, but when I run them in ghci, I see: {{{ $ ghci GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :l HelloWorld.hs [1 of 1] Compiling Main ( HelloWorld.hs, interpreted ) Ok, modules loaded: Main. *Main> main [...] Loading package HsHyperEstraier-0.2.1 ... can't load .so/.DLL for: c (/usr/lib/libc.so: invalid ELF header) }}} I see a similar error message if I specify '-package HsHyperEstraier' on the command line. I did some looking and came up with these messages: http://www.haskell.org/pipermail/glasgow-haskell- users/2004-May/006632.html http://www.nabble.com/RE:-idea-to-allow-ghci-to-use-a-different-libs- list-p1830432.html Debian's /usr/lib/libc.so is indeed a GNU linker script, not an actual shared library. If I remove all the libraries in HsHyperEstraier's ~/.ghc/.../package.conf that are linker scripts (pthreads and c), it loads up fine. Could ghci either recognize or ignore linker scripts? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 19:11:12 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 19:08:27 2008 Subject: [GHC] #2597: panic! (the 'impossible' happened) (using TH) In-Reply-To: <043.059865a2ed72b6802d1466b05790ef9c@localhost> References: <043.059865a2ed72b6802d1466b05790ef9c@localhost> Message-ID: <052.bed582eb79bb11c70ae2efa2b7ccac1d@localhost> #2597: panic! (the 'impossible' happened) (using TH) ------------------------------+--------------------------------------------- Reporter: jcab | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Here are the patches. {{{ Sat Sep 20 22:20:10 GMT Daylight Time 2008 simonpj@microsoft.com * Fix Trac #2597 (first bug): correct type checking for empty list The GHC front end never generates (ExplicitList []), but TH can. This patch makes the typechecker robust to such programs. Sat Sep 20 22:11:01 GMT Daylight Time 2008 simonpj@microsoft.com * Fix Trac #2597 (second bug): complain about an empty DoE block When converting an empty do-block from TH syntax to HsSyn, complain rather than crashing. }}} Ian; worth merging these across I think. Both are small Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 19:12:07 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 19:09:22 2008 Subject: [GHC] #2597: panic! (the 'impossible' happened) (using TH) In-Reply-To: <043.059865a2ed72b6802d1466b05790ef9c@localhost> References: <043.059865a2ed72b6802d1466b05790ef9c@localhost> Message-ID: <052.45014eb4ea0b1049a96671c2ac54abbd@localhost> #2597: panic! (the 'impossible' happened) (using TH) ----------------------------------+----------------------------------------- Reporter: jcab | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: th/T2597a, th/T2597b | Architecture: x86 Os: Windows | ----------------------------------+----------------------------------------- Changes (by simonpj): * testcase: => th/T2597a, th/T2597b -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 19:45:16 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 19:42:31 2008 Subject: [GHC] #2052: hpc ignores files containing LINES pragmas that refer to .hsc files In-Reply-To: <043.13a31077ae5ebb133355743a92fc5086@localhost> References: <043.13a31077ae5ebb133355743a92fc5086@localhost> Message-ID: <052.67883454cc24e6cdb741c989d90ebe69@localhost> #2052: hpc ignores files containing LINES pragmas that refer to .hsc files ---------------------------+------------------------------------------------ Reporter: dons | Owner: AndyGill Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Code Coverage | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: hpc, hsc2hs | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ---------------------------+------------------------------------------------ Changes (by AndyGill): * status: assigned => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 20 19:45:43 2008 From: trac at galois.com (GHC) Date: Sat Sep 20 19:42:59 2008 Subject: [GHC] #2311: hpc markup fails to create directory when marking up coverage of a package In-Reply-To: <047.c5e059546eb7b71abc6327141315c07f@localhost> References: <047.c5e059546eb7b71abc6327141315c07f@localhost> Message-ID: <056.677ae97508946e7a3299b9c724f5496f@localhost> #2311: hpc markup fails to create directory when marking up coverage of a package ---------------------------+------------------------------------------------ Reporter: AndyGill | Owner: AndyGill Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Code Coverage | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by AndyGill): * status: assigned => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 21 07:11:45 2008 From: trac at galois.com (GHC) Date: Sun Sep 21 07:09:05 2008 Subject: [GHC] #2565: Windows binary snapshots not available In-Reply-To: <051.1976784c9715158e8d7a1287c8380508@localhost> References: <051.1976784c9715158e8d7a1287c8380508@localhost> Message-ID: <060.6ca561b3aab14334cb0885d7dd552bfc@localhost> #2565: Windows binary snapshots not available --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: There are now newer snapshots available -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 01:31:58 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 01:29:15 2008 Subject: [GHC] #2606: Backspace, delete, etc. don't work in ghci in HEAD In-Reply-To: <042.c2c283bd011173c80eba1a908d5990b1@localhost> References: <042.c2c283bd011173c80eba1a908d5990b1@localhost> Message-ID: <051.c533e943ba6840eee93d527c0da25d68@localhost> #2606: Backspace, delete, etc. don't work in ghci in HEAD -----------------------+---------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by tim): Replying to [comment:6 judah]: > Hmm, if you had to install libedit-dev to build that program then maybe ghc's editline bindings weren't built when you built ghc. Can you please check whether ghc's editline package is installed, for example by: > - trying to run {{{:browse System.Console.Editline.Readline}}} inside ghci > - double-checking whether the up/down arrow keys page through the ghci history > > If it's not installed, you can probably fix this problem by building ghc again. Indeed, the browse command you suggested says there's no such module, and the arrow keys don't work (even after I suspend ghci and bring it back to the foreground as I described before). So I think your explanation is probably right. I won't have a chance to build ghc again for a little bit, but I think it should really be documented that you need to install the libedit-dev package (or whatever the equivalent is for distros other than Ubuntu/Debian), because my install of Ubuntu didn't come with it by default and I would expect that either this would work out of the box, or configure would tell me that I lacked a needed dependency. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 08:57:29 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 08:54:41 2008 Subject: [GHC] #2493: implement proposed Qualified Operator syntax In-Reply-To: <051.85a6e8a5d506f432836c995c200eacbf@localhost> References: <051.85a6e8a5d506f432836c995c200eacbf@localhost> Message-ID: <060.da1ded4b4a9fe0cbbf448a208a253cce@localhost> #2493: implement proposed Qualified Operator syntax -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 09:06:02 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 09:03:12 2008 Subject: [GHC] #2616: install script can't replace /usr/local/bin/runhaskell Message-ID: <044.47116bb1d681622f73ee4d9827568e26@localhost> #2616: install script can't replace /usr/local/bin/runhaskell -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- sudo make install under OS X encounters the following error if runhaskell is already installed. rming it sorts the issue. ------------------------------------------------------------------------ == make install - --no-print-directory -r; in /Users/tatd2/Documents/HaskellRepositories/darcsT/ghc/driver/runhaskell ------------------------------------------------------------------------ ln -s runghc /usr/local/bin/runhaskell ln: /usr/local/bin/runhaskell: File exists make[2]: *** [install] Error 1 Failed making install in runhaskell: 1 make[1]: *** [install] Error 1 make: *** [install] Error 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 09:07:20 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 09:04:32 2008 Subject: [GHC] #2617: GHC.Integer no longer exports S# and J# Message-ID: <044.45278722ce7acad4e6c3763b20241222@localhost> #2617: GHC.Integer no longer exports S# and J# -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHC API Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- These constructors are needed for hs-plugins' Data.Binary instance for Integer instance Binary Integer where get bh = do b <- getByte bh case b of 0 -> do (I# i#) <- get bh return (S# i#) _ -> do (I# s#) <- get bh sz <- get bh (BA a#) <- getByteArray bh sz return (J# s# a#) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 10:34:16 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 10:31:27 2008 Subject: [GHC] #2618: Order is relevant when matching signature contexts of a mutually recursive group Message-ID: <044.3cbe08640dd9401cf960fac9aa59e7db@localhost> #2618: Order is relevant when matching signature contexts of a mutually recursive group ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- The Following code {{{ f :: (Show a, Eq a) => a -> String f x = show x `const` g x g :: (Eq a,Show a) => a -> Bool g x = x==x `const` f x }}} gives this error: {{{ Couldn't match expected type `Eq a' against inferred type `Show a1' When matching the contexts of the signatures for f :: forall a. (Show a, Eq a) => a -> String g :: forall a. (Eq a, Show a) => a -> Bool The signature contexts in a mutually recursive group should all be identical When generalising the type(s) for f, g Failed, modules loaded: none. }}} but it compiles fine if i swap Show and Eq in the context of either f or g. The order of typeclass constraints usually doesn't matter so it's very surprising that it does here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 12:33:46 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 12:30:58 2008 Subject: [GHC] #2619: Can't build HEAD with ghc-6.10 Message-ID: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> #2619: Can't build HEAD with ghc-6.10 -----------------------+---------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- I tried to build an up-to-date HEAD (ghc-6.9.20080920) with ghc-6.10.0.20080921 (from the release candidate tarball), and got the following error. I have double-checked that building HEAD with ghc-6.8.3 still works for me. {{{ Building ghc-bin-6.9.20080920... In file included from Main.hs:14:0: /usr/local/lib/ghc-6.10.0.20080921/ghc-6.10.0.20080921/include/HsVersions.h:23:0: error: ../includes/ghcautoconf.h: No such file or directory make[2]: *** [build.stage.1] Error 1 make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 }}} My installed layout explains the error a little: {{{ /usr/local/lib/ghc-6.10.0.20080921//ghc-6.10.0.20080921/include/HsVersions.h /usr/local/lib/ghc-6.10.0.20080921//include/ghcautoconf.h }}} Although I wonder whether the root cause of this problem is that Main.hs is using the installed `HsVersions.h` instead of the local `compiler/HsVersions.h`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 12:42:48 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 12:39:58 2008 Subject: [GHC] #2620: `ghci --help` gives unhelpful error message Message-ID: <047.0e1b89a67baa9648b525964b885b7025@localhost> #2620: `ghci --help` gives unhelpful error message -------------------------+-------------------------------------------------- Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.3 | Severity: minor Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Running `ghci --help` gives the following humorous output: {{{ : cannot use `--interactive' with `--help' Usage: For basic information, try the `--help' option. }}} This works with GHC 6.8.2 on Linux (x86) but evidently not with GHC 6.8.3 on Windows. Although the error message, in this case, could be improved, it would be better if `--help` (and `--version`, maybe others) worked the same way as with `ghc`, for both `ghci` and `ghc --interactive`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 17:47:32 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 17:44:40 2008 Subject: [GHC] #2580: export Data.Map.toDescList In-Reply-To: <047.7323273a4c97569c35461c7770e620db@localhost> References: <047.7323273a4c97569c35461c7770e620db@localhost> Message-ID: <056.541bcb1b7fe8f7ddbf3e3def25841462@localhost> #2580: export Data.Map.toDescList -------------------------------+-------------------------------------------- Reporter: elaforge | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Changes (by elaforge): * owner: => igloo Comment: Replacing patch yet again to export foldrWithKey also. Summary from the "thread" such as it was: Benedikt suggested adding something like: > viewAssocs :: Map k v -> MapView (k,v) > instance Foldable MapView This might be a good idea for the future but I wanted to keep the scope of the patch under control. On further thought, it seemed asymmetrical to export foldWithKey and foldlWithKey, so I added foldrWithKey to the export list, keeping foldWithKey to not break existing code. I added a note to the haddock for foldWithKey encouraging the use of foldrWithKey. So we export: toDescList - new, but implementable with foldlWithKey foldlWithKey - new foldrWithKey - the same as foldWithKey, but explicitly the mirror of foldlWithKey There were no other comments. I'm specifically not certain about the laziness of the folds (i.e. will they lead to stack problems like List.foldl), but no one said there was a problem, so maybe it's fine. I'm also not sure if there was some important reason behind the reason the folds were exported, but no one said anything, so maybe it was just arbitrary. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 18:21:14 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 18:18:26 2008 Subject: [GHC] #2493: implement proposed Qualified Operator syntax In-Reply-To: <051.85a6e8a5d506f432836c995c200eacbf@localhost> References: <051.85a6e8a5d506f432836c995c200eacbf@localhost> Message-ID: <060.4ca9a870a3d299e2dcc193529529ebdc@localhost> #2493: implement proposed Qualified Operator syntax -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Done: {{{ Mon Sep 22 16:23:40 BST 2008 Simon Marlow * add -XNewQualifiedOperators (Haskell' qualified operator syntax) }}} The implementatin is not exactly the same as the proposal, in that the `(op)` and {{{`var`}}} syntax still resides in the parser, and so we still accept `( + )` as an operator (but not `Prelude.( + )`, so there's an inconsistency). I did try to move these parsing rules down to the lexer, but it turned out to be too complicated to do this and also retain the old way. I don't think it'll be a problem in practice. There are some notes about the issues in `Lexer.x`. This could possibly go into 6.10.1, -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 23:08:29 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 23:05:48 2008 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.cce81172effaf139aa73ac2928090f56@localhost> #1895: Allow aliases in GHCi module imports -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by thoughtpolice): * cc: mad.one@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 23:23:12 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 23:20:31 2008 Subject: [GHC] #2621: sum and product thunkpile Message-ID: <050.ec28989b72681ab105eeb9aecb19ad93@localhost> #2621: sum and product thunkpile ----------------------------+----------------------------------------------- Reporter: Bart Massey | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.9 | Severity: major Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------+----------------------------------------------- Do "ulimit -v 524288" at the shell so your machine won't hang. Run ghci, bring in Data.List, and execute "sum [1..10**8]". Notice that you run out of memory. Now try again with "foldl1' (+) [1..10**8]". Note that you get an answer. The definition of sum and product in the Report use foldl. However, the versions currently being used are open-coded for some reason. They should just use foldl1' (after handling the special case of the empty list appropriately). As it is, the functions thunkpile; this seems pointless, as they are ultimately completely strict in their argument. This kind of bug is grim for new users, which is why the severity is marked "major". Patch attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 23:31:12 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 23:28:38 2008 Subject: [GHC] #2622: sum and product thunkpile Message-ID: <050.f0cff1295454680a8b4898f506c37b1b@localhost> #2622: sum and product thunkpile ----------------------------+----------------------------------------------- Reporter: Bart Massey | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.9 | Severity: major Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------+----------------------------------------------- Do "ulimit -v 524288" at the shell so your machine won't hang. Run ghci, bring in Data.List, and execute "sum [1..10**8]". Notice that you run out of memory. Now try again with "foldl1' (+) [1..10**8]". Note that you get an answer. The definition of sum and product in the Report use foldl. However, the versions currently being used are open-coded for some reason. They should just use foldl1' (after handling the special case of the empty list appropriately). As it is, the functions thunkpile; this seems pointless, as they are ultimately completely strict in their argument. This kind of bug is grim for new users, which is why the severity is marked "major". Patch attached. This is just a context unidiff against current Darcs head; a Darcs-format patch with full context (at 350KB) is at http://po8.org/bart/sumprod.patch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 22 23:38:48 2008 From: trac at galois.com (GHC) Date: Mon Sep 22 23:36:09 2008 Subject: [GHC] #2622: sum and product thunkpile In-Reply-To: <050.f0cff1295454680a8b4898f506c37b1b@localhost> References: <050.f0cff1295454680a8b4898f506c37b1b@localhost> Message-ID: <059.95f7d13075e29f5657d59ff0c5ca61f7@localhost> #2622: sum and product thunkpile -------------------------------+-------------------------------------------- Reporter: Bart Massey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------------+-------------------------------------------- Comment (by Bart Massey): Oh, BTW, maybe product needs to be open-coded (but not the current way!) so that it can be properly lazy on encountering a 0 in the list. I have mixed feelings about this; on the one hand, it's in the spirit of "maximal laziness", on the other hand, it's a bit strange. Should I file another bug report or proposal for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 01:28:42 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 01:25:56 2008 Subject: [GHC] #2585: New versions of windres fail with "windres: CreateProcess (null): No error" In-Reply-To: <044.25b69fd7b594ae443d31576c538df3be@localhost> References: <044.25b69fd7b594ae443d31576c538df3be@localhost> Message-ID: <053.af9c6381522d507d4082a2c4000d87e2@localhost> #2585: New versions of windres fail with "windres: CreateProcess (null): No error" ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by _sr): This is also fixed if a newer version of windres is used: > GNU windres (GNU Binutils) 2.18.50.20080109 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 02:15:36 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 02:12:44 2008 Subject: [GHC] #2623: Crypto-0.4.1 -- the impossible happened Message-ID: <043.3d955c8ddc2d1cdb6bdfa8d6071475f4@localhost> #2623: Crypto-0.4.1 -- the impossible happened -----------------------+---------------------------------------------------- Reporter: jsnx | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- I'm using the Linux binary of GHC 6.8.3 to build the crypto library. The build fails, and GHC helpfully suggests `fregs-graph`, which, when added to the Cabal file, allows the build to continue. {{{ ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 02:46:02 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 02:43:10 2008 Subject: [GHC] #2624: GHC 10.1 beta build error Message-ID: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> #2624: GHC 10.1 beta build error -------------------------+-------------------------------------------------- Reporter: humasect | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- installPackage: internal error: stg_ap_ppp_ret (GHC version 6.8.3 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[2]: *** [build.stage.1] Abort trap make[1]: *** [build.stage.1] Error 2 make: *** [stage1] Error 1 When building ghc-6.10.0.20080921 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 04:19:18 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 04:16:26 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.9774bb95483b4db9750980ee4c5957ed@localhost> #2081: GHC reports internal error: stg_ap_v_ret -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Changes (by guest): * os: MacOS X => Multiple * architecture: powerpc => Multiple * summary: On a strained PPC Mac OS X 10.4, GHC reports internal error: stg_ap_v_ret => GHC reports internal error: stg_ap_v_ret Comment: The same bug can occur on Intel OS X in the resulting binary. The mkbndl package on hackage when compiled and simply run with "mkbndl" will cause the app to output the usage string and then mkbndl: internal error: stg_ap_v_ret (GHC version 6.9.20080920 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 08:39:22 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 08:36:34 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.2b13ed2160bed6a855c6e675ea50660e@localhost> #1364: Finalizers not guaranteed to run before the program exits ----------------------------------+----------------------------------------- Reporter: tomac@pacific.net.au | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Comment (by simonmar): Perhaps I'm reading the code wrong, but it seems that you'll get two weak pointers created by a `newForeignPtr`: one created by `addForeignPtrFinalizer` and one created by `addForeignPtrConcFinalizer` (which is called by `addForeignPtrFinalizer`). Also, the weak pointer with the C finalizer should be attached to the `MutVar#` inside the IORef, in the same way that `addForeignPtrConcFinalizer` does (this is a safety measure, because the compiler might optimise away `ForeignPtrContents`, but it can't optimise away a `MutVar#`). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 08:49:39 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 08:46:47 2008 Subject: [GHC] #2295: Combined -odir/-hidir flag In-Reply-To: <051.3ec75d5010176a8f7458111511793c49@localhost> References: <051.3ec75d5010176a8f7458111511793c49@localhost> Message-ID: <060.78b24661d12678d5a413a4f3d526cc12@localhost> #2295: Combined -odir/-hidir flag -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by simonmar): How about `-outputdir` which sets all of `-odir`, `-hidir`, and `-stubdir`? The only downside I can see is that people might expect the executable to go there too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 09:08:30 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 09:05:37 2008 Subject: [GHC] #2295: Combined -odir/-hidir flag In-Reply-To: <051.3ec75d5010176a8f7458111511793c49@localhost> References: <051.3ec75d5010176a8f7458111511793c49@localhost> Message-ID: <060.bfcfd858b58a43352fe5399fd35ad115@localhost> #2295: Combined -odir/-hidir flag -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by NeilMitchell): An -outputdir flag would be perfect. Another name might be -outdir, or -gendir. Could the semantics of -outputdir create the directory if it doesn't already exist. I think one of -hidir/-odir does this, but the other doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 09:45:18 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 09:42:25 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.33039b7456c52d04efb0648ee332ceb1@localhost> #2081: GHC reports internal error: stg_ap_v_ret -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Comment (by simonmar): I don't see this, using a build on x86-Linux from yesterday and mkbndl downloaded from Hackage today. Can any Mac users reproduce it? The error message could be indicative of a wide range of different corruption failures in the runtime, so my guess is that this ticket is actually more than one bug. It's possible the original bug has now been fixed and what we're looking at now is a new bug. But that's just my informed opinion. Let's try to reproduce it anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 10:07:22 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 10:04:30 2008 Subject: [GHC] #2566: "ghc -c foo.bar" silently does nothing In-Reply-To: <044.d5ec73495db3a97d116701dde7bbb4b2@localhost> References: <044.d5ec73495db3a97d116701dde7bbb4b2@localhost> Message-ID: <053.8ca184fcca39c8ed34fccd111bc96372@localhost> #2566: "ghc -c foo.bar" silently does nothing ---------------------+------------------------------------------------------ Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 11:36:42 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 11:33:50 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.1688965b38a376091ed6b513308aef36@localhost> #2081: GHC reports internal error: stg_ap_v_ret -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Comment (by judah): I was unable to reproduce this on an Intel iMac with OS X 10.5.4, ghc-6.10.0.20080921 and mkbundl-0.2.1. I downloaded the tarball and did {{{runhaskell Setup [configure,build,install]}}}. Thorkil, did anything differ in how you reproduced the error? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 11:42:48 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 11:39:55 2008 Subject: [GHC] #2624: GHC 10.1 beta build error In-Reply-To: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> References: <047.76d2c62e7d59e097507fa0512f79c3af@localhost> Message-ID: <056.288183f026cc25fbc85035a60ee6f875@localhost> #2624: GHC 10.1 beta build error -------------------------+-------------------------------------------------- Reporter: humasect | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Comment (by judah): What versions of OS X and of XCode do you have on your machine? I did not see that error on 10.5.4 with XCode 3.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 12:52:24 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 12:49:46 2008 Subject: [GHC] #2621: sum and product thunkpile In-Reply-To: <050.ec28989b72681ab105eeb9aecb19ad93@localhost> References: <050.ec28989b72681ab105eeb9aecb19ad93@localhost> Message-ID: <059.e7ec9a3e25228f880861eeddea1d3227@localhost> #2621: sum and product thunkpile ----------------------------+----------------------------------------------- Reporter: Bart Massey | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.9 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: resubmitted as #2622 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 13:01:05 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 12:58:27 2008 Subject: [GHC] #2622: sum and product thunkpile In-Reply-To: <050.f0cff1295454680a8b4898f506c37b1b@localhost> References: <050.f0cff1295454680a8b4898f506c37b1b@localhost> Message-ID: <059.71605378436e45afb91aba44df1c6c7f@localhost> #2622: sum and product thunkpile ----------------------------+----------------------------------------------- Reporter: Bart Massey | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.9 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: We can't apply this patch, because it changes the semantics of sum & product. Note that sum is overloaded, and there's no requirement that `(+)` is strict for any given instance of `Num`. When used at `Int` or `Integer`, we do indeed have strict specialised versions of `sum`, but these don't get used inside GHCi, because GHCi doesn't do optimisation. Perhaps there's a case that we should be doing this kind of optimisation in GHCi, but that's another story (and should be another ticket). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 13:52:28 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 13:50:24 2008 Subject: [GHC] #1920: Show instance for Ratio is wrong In-Reply-To: <044.e80848d0a76afc798fd576368291df43@localhost> References: <044.e80848d0a76afc798fd576368291df43@localhost> Message-ID: <053.3986d084e57eb2d8b0612a493281e889@localhost> #1920: Show instance for Ratio is wrong ----------------------------+----------------------------------------------- Reporter: guest | Owner: igoo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igoo * type: bug => merge Comment: Done. libraries/base: {{{ Tue Sep 23 14:49:49 BST 2008 Simon Marlow * Restore the Haskell 98 behaviour of Show Ratio (#1920) }}} testsuite: {{{ Tue Sep 23 15:41:55 BST 2008 Simon Marlow * accept output (Show Ratio changes, #1920) }}} nofib: {{{ Tue Sep 23 14:49:26 BST 2008 Simon Marlow * update output: Show Ratio changed (#1920) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 13:54:45 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 13:53:03 2008 Subject: [GHC] #2566: "ghc -c foo.bar" silently does nothing In-Reply-To: <044.d5ec73495db3a97d116701dde7bbb4b2@localhost> References: <044.d5ec73495db3a97d116701dde7bbb4b2@localhost> Message-ID: <053.5eca1820a34657577c5d58006ffd852c@localhost> #2566: "ghc -c foo.bar" silently does nothing ---------------------+------------------------------------------------------ Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed. {{{ Tue Sep 23 15:49:56 BST 2008 Simon Marlow * #2566: emit a warning for 'ghc -c foo.bar' $ ghc -c foo.bar Warning: the following files would be used as linker inputs, but linking is not being done: foo.bar ghc: no input files Usage: For basic information, try the `--help' option. }}} testsuite: {{{ Tue Sep 23 15:01:20 BST 2008 Simon Marlow * add test for #2566, also enable driver100 which wasn't being run }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 23 13:58:12 2008 From: trac at galois.com (GHC) Date: Tue Sep 23 13:59:59 2008 Subject: [GHC] #2499: OPTIONS pragma silently ignored In-Reply-To: <046.91540bf76265b8560aaa0dae63298652@localhost> References: <046.91540bf76265b8560aaa0dae63298652@localhost> Message-ID: <055.a9ebd34c44c9d37132493d5051f75aca@localhost> #2499: OPTIONS pragma silently ignored ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Fixed: {{{ Tue Sep 23 18:39:04 BST 2008 Simon Marlow * Disallow package flags in OPTIONS_GHC pragmas (#2499) }}} testsuite: {{{ Tue Sep 23 18:56:20 BST 2008 Simon Marlow * add test for #2499 (package flags in OPTIONS pragmas) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 24 00:58:06 2008 From: trac at galois.com (GHC) Date: Wed Sep 24 00:55:13 2008 Subject: [GHC] #2625: Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields Message-ID: <047.a4131859623f35304148b8ddaa8f3bbb@localhost> #2625: Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields -------------------------------+-------------------------------------------- Reporter: aslatter | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Unknown -------------------------------+-------------------------------------------- In the following example, with either -O or -O2 In the derived Eq instance for A, in '==' nothing ever gets re-packed into a B constructor. However in the derived Ord instance, in the 'compile' function the code from -ddump-simpl shows that the RHS of 'compare' is unpacked from the 'A' constructor only to be repacked in 'B' constructor and then passed on to a different function. Is there any way we can do for 'compare' what was done for '==' ? Thanks {{{ module Bug where data A = A {-# UNPACK #-} !B deriving (Eq, Ord) data B = B {-# UNPACK #-} !Int {-# UNPACK #-} !Int {-# UNPACK #-} !Int {-# UNPACK #-} !Int {-# UNPACK #-} !Int {-# UNPACK #-} !Int {-# UNPACK #-} !Int deriving (Eq, Ord) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 24 12:43:56 2008 From: trac at galois.com (GHC) Date: Wed Sep 24 12:41:00 2008 Subject: [GHC] #2597: panic! (the 'impossible' happened) (using TH) In-Reply-To: <043.059865a2ed72b6802d1466b05790ef9c@localhost> References: <043.059865a2ed72b6802d1466b05790ef9c@localhost> Message-ID: <052.b648cec92720c1c6c3b03525bacf24af@localhost> #2597: panic! (the 'impossible' happened) (using TH) ----------------------------------+----------------------------------------- Reporter: jcab | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 6.8.3 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T2597a, th/T2597b | Architecture: x86 Os: Windows | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 24 12:44:09 2008 From: trac at galois.com (GHC) Date: Wed Sep 24 12:41:13 2008 Subject: [GHC] #2566: "ghc -c foo.bar" silently does nothing In-Reply-To: <044.d5ec73495db3a97d116701dde7bbb4b2@localhost> References: <044.d5ec73495db3a97d116701dde7bbb4b2@localhost> Message-ID: <053.c25c9cf88323e153418d841bf1a6532e@localhost> #2566: "ghc -c foo.bar" silently does nothing ---------------------+------------------------------------------------------ Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 24 12:44:18 2008 From: trac at galois.com (GHC) Date: Wed Sep 24 12:41:23 2008 Subject: [GHC] #2499: OPTIONS pragma silently ignored In-Reply-To: <046.91540bf76265b8560aaa0dae63298652@localhost> References: <046.91540bf76265b8560aaa0dae63298652@localhost> Message-ID: <055.629e875e807682dfd1a0b8c29e073c14@localhost> #2499: OPTIONS pragma silently ignored ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 24 12:44:37 2008 From: trac at galois.com (GHC) Date: Wed Sep 24 12:41:41 2008 Subject: [GHC] #1920: Show instance for Ratio is wrong In-Reply-To: <044.e80848d0a76afc798fd576368291df43@localhost> References: <044.e80848d0a76afc798fd576368291df43@localhost> Message-ID: <053.87aff66cdff7260a77c5853743ac22a0@localhost> #1920: Show instance for Ratio is wrong ----------------------------+----------------------------------------------- Reporter: guest | Owner: igoo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 24 13:26:37 2008 From: trac at galois.com (GHC) Date: Wed Sep 24 13:23:59 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.4ca1bd06394b0a80ade1863621bc0448@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): Here is an example of Data.Set going wrong due to multiple instances: {{{ module Type where data Foo = F1 | F2 | F3 deriving (Eq, Show) }}} {{{ module Create where import Data.Set import Type instance Ord Foo where x `compare` y = show x `compare` show y s :: Set Foo s = fromList [F1, F2, F3] }}} {{{ module Consume where import Data.Set import Type instance Ord Foo where x `compare` y = show y `compare` show x f :: Set Foo -> Bool f x = F1 `member` x }}} {{{ import Create import Consume main :: IO () main = print (f s) }}} {{{ $ ./Main False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 24 15:46:02 2008 From: trac at galois.com (GHC) Date: Wed Sep 24 15:43:06 2008 Subject: [GHC] #2626: In ISO8601 the date and time should be separated by a 'T', not a space Message-ID: <053.3c40599d333cc0ff87ad32082ee97987@localhost> #2626: In ISO8601 the date and time should be separated by a 'T', not a space -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (old-time) Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- A proper proposal for the issue raised in #2474. Deadline: a week after ticket submission. -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Wed Sep 24 17:55:01 2008 From: conal at conal.net (Conal Elliott) Date: Wed Sep 24 17:52:04 2008 Subject: TypeCompose Patch In-Reply-To: <6268.24.69.170.39.1222292558.squirrel@squishy.internetofdeath.com> References: <5154.24.69.170.39.1222276110.squirrel@squishy.internetofdeath.com> <5614.24.69.170.39.1222291451.squirrel@squishy.internetofdeath.com> <6268.24.69.170.39.1222292558.squirrel@squishy.internetofdeath.com> Message-ID: Eep! That code (which uses type classes) fails to compile under 6.8.3 but does compile under 6.9. Looks like 6.10 broke something. Can anyone else check whether vector-space build or breaks under 6.10? The repo is http://code.haskell.org/vector-space/ Thanks, - Conal On Wed, Sep 24, 2008 at 2:42 PM, Trevor Elliott wrote: > Here's the specific problem that I get during the build: > > src/Data/LinearMap.hs:37:21: > Couldn't match expected type `t' against inferred type `Basis u' > In the second argument of `(.)', namely `basisValue' > In the first argument of `trie', namely `(f . basisValue)' > In the expression: trie (f . basisValue) > > > build problems in 6.10?? > > > > On Wed, Sep 24, 2008 at 2:24 PM, Trevor Elliott > > wrote: > > > >> By the way, are the build problems in vector-space due to a 6.10 bug, or > >> the library itself? I wasn't able to find any other record of what I > >> was > >> experiencing, and was debating whether or not I should submit a report > >> :) > >> > >> --trevor > >> > >> > thanks very much, Trevor. i just pushed your patch, and now i know to > >> > make > >> > similar changes to my other libraries. > >> > > >> > On Wed, Sep 24, 2008 at 10:08 AM, Trevor Elliott > >> > wrote: > >> > > >> >> Hi Conal, > >> >> > >> >> I fixed a small build issue with the newest 6.10 release candidate. > >> It > >> >> seems that Control.Arrow no longer exports pure, so I added a check > >> to > >> >> hide it when using 6.9 and lower. > >> >> > >> >> --trevor > >> > > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20080924/ce6535b3/attachment.htm From trac at galois.com Wed Sep 24 18:45:11 2008 From: trac at galois.com (GHC) Date: Wed Sep 24 18:42:14 2008 Subject: [GHC] #2580: export Data.Map.toDescList In-Reply-To: <047.7323273a4c97569c35461c7770e620db@localhost> References: <047.7323273a4c97569c35461c7770e620db@localhost> Message-ID: <056.ca882e05611532999abc21515b52b4be@localhost> #2580: export Data.Map.toDescList ----------------------------+----------------------------------------------- Reporter: elaforge | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From marco-oweber at gmx.de Wed Sep 24 20:50:01 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Wed Sep 24 20:47:06 2008 Subject: TypeCompose Patch In-Reply-To: References: <5154.24.69.170.39.1222276110.squirrel@squishy.internetofdeath.com> <5614.24.69.170.39.1222291451.squirrel@squishy.internetofdeath.com> <6268.24.69.170.39.1222292558.squirrel@squishy.internetofdeath.com> Message-ID: <20080925005001.GC18545@gmx.de> On Wed, Sep 24, 2008 at 02:55:01PM -0700, Conal Elliott wrote: > Eep! That code (which uses type classes) fails to compile under 6.8.3 but > does compile under 6.9. Looks like 6.10 broke something. > > Can anyone else check whether vector-space build or breaks under 6.10? > The repo is > > [1]http://code.haskell.org/vector-space/ src/Data/LinearMap.hs|37 col 21 error| || Couldn't match expected type `t' against inferred type `Basis u' || In the second argument of `(.)', namely `basisValue' || In the first argument of `trie', namely `(f . basisValue)' || In the expression: trie (f . basisValue) Hi Conal, I'm getting the error above (current ghc from darcs) If you want I can give you an ssh account where this ghc version is installed within the next days. I also had to add a -fglasgow-exts to a MemoTrie file.. (Not sure which is the correct language extension which was missing) Sincerly Marc Weber From simonpj at microsoft.com Thu Sep 25 03:32:10 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Sep 25 03:29:11 2008 Subject: TypeCompose Patch In-Reply-To: <20080925005001.GC18545@gmx.de> References: <5154.24.69.170.39.1222276110.squirrel@squishy.internetofdeath.com> <5614.24.69.170.39.1222291451.squirrel@squishy.internetofdeath.com> <6268.24.69.170.39.1222292558.squirrel@squishy.internetofdeath.com> <20080925005001.GC18545@gmx.de> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32D766E2F95@EA-EXMSG-C334.europe.corp.microsoft.com> Conal, Marc This is definitely a bug in the new equality-solving mechanism. I can reproduce it readily. I'll discuss it with Manuel tomorrow and get back to you. Thanks for finding it! Simon | -----Original Message----- | From: glasgow-haskell-bugs-bounces@haskell.org [mailto:glasgow-haskell-bugs- | bounces@haskell.org] On Behalf Of Marc Weber | Sent: 25 September 2008 01:50 | To: glasgow-haskell-bugs@haskell.org | Subject: Re: TypeCompose Patch | | On Wed, Sep 24, 2008 at 02:55:01PM -0700, Conal Elliott wrote: | > Eep! That code (which uses type classes) fails to compile under 6.8.3 | but | > does compile under 6.9. Looks like 6.10 broke something. | > | > Can anyone else check whether vector-space build or breaks under 6.10? | > The repo is | > | > [1]http://code.haskell.org/vector-space/ | | src/Data/LinearMap.hs|37 col 21 error| | || Couldn't match expected type `t' against inferred type `Basis u' | || In the second argument of `(.)', namely `basisValue' | || In the first argument of `trie', namely `(f . basisValue)' | || In the expression: trie (f . basisValue) | | Hi Conal, I'm getting the error above (current ghc from darcs) | If you want I can give you an ssh account where this ghc version is | installed within the next days. | | I also had to add a -fglasgow-exts to a MemoTrie file.. | (Not sure which is the correct language extension which was missing) | | Sincerly | Marc Weber | _______________________________________________ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu Sep 25 07:27:38 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:24:38 2008 Subject: [GHC] #2575: shell script gotcha in boot In-Reply-To: <049.285f38c1ef1de70458d959845f9cbdf8@localhost> References: <049.285f38c1ef1de70458d959845f9cbdf8@localhost> Message-ID: <058.f8d1f300016b826d6a5a5b410042170c@localhost> #2575: shell script gotcha in boot --------------------------+------------------------------------------------- Reporter: pooryorick | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report; now done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:29:03 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:26:04 2008 Subject: [GHC] #2583: printf %s is not lazy enough In-Reply-To: <045.1bc664825025215dda23751e2d4d0e40@localhost> References: <045.1bc664825025215dda23751e2d4d0e40@localhost> Message-ID: <054.eda68ad9f3999eec9eae8ec7607363e7@localhost> #2583: printf %s is not lazy enough ----------------------------+----------------------------------------------- Reporter: olsner | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:31:35 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:28:42 2008 Subject: [GHC] #2584: Pretty printing of types with HsDocTy goes wrong In-Reply-To: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> References: <051.bf512b6956b3ff06fbdabc8d35b6e47d@localhost> Message-ID: <060.d1da3f5264856e7dd88f1c6df1482ba9@localhost> #2584: Pretty printing of types with HsDocTy goes wrong --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: waern Type: bug | Status: assigned Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:37:55 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:34:56 2008 Subject: [GHC] #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" In-Reply-To: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> References: <046.1cb31cac63221b315fd1f2ae91446e7c@localhost> Message-ID: <055.da31aaa162dab484bc9093e8694a85e6@localhost> #2589: ghci fails in ByteCodeGen.lhs with "nonexhaustive patterns in case" ----------------------+----------------------------------------------------- Reporter: gwright | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: The code is now -Wall clean, so this sort of crash shouldn't happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:39:10 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:36:10 2008 Subject: [GHC] #2592: Can't profile when the heap maximum is hit In-Reply-To: <046.6ff10d2040e94a9b4e4cc6a778189212@localhost> References: <046.6ff10d2040e94a9b4e4cc6a778189212@localhost> Message-ID: <055.5a4a31e8d024184f2f9779d562649e4f@localhost> #2592: Can't profile when the heap maximum is hit ---------------------------+------------------------------------------------ Reporter: adekoba | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: profile, heap | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:39:36 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:36:36 2008 Subject: [GHC] #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) In-Reply-To: <044.a6b75e88dad86d305cedec64af5f04be@localhost> References: <044.a6b75e88dad86d305cedec64af5f04be@localhost> Message-ID: <053.e4a943ca3f98503a59165cab44a6588d@localhost> #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) ----------------------+----------------------------------------------------- Reporter: shahn | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:40:05 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:37:09 2008 Subject: [GHC] #2598: Avoid excessive specialisation in SpecConstr In-Reply-To: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> References: <046.41dadb7ee5f62a188e8b2b903c4852f9@localhost> Message-ID: <055.edb9e0ff396f83d2c25163fc7050e843@localhost> #2598: Avoid excessive specialisation in SpecConstr -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:40:25 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:37:26 2008 Subject: [GHC] #2600: Bind type variables in RULES In-Reply-To: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> References: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@localhost> Message-ID: <055.4ae3e5aa9a3c40ce28d420b86c6fde03@localhost> #2600: Bind type variables in RULES -----------------------------+---------------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:41:34 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:38:40 2008 Subject: [GHC] #2602: Haddock not installed properly In-Reply-To: <051.bff77834b377c6ec330f589afeeee640@localhost> References: <051.bff77834b377c6ec330f589afeeee640@localhost> Message-ID: <060.81f1a1fe77b5b1f1a241c636f5e904b8@localhost> #2602: Haddock not installed properly --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report; now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:42:48 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:39:48 2008 Subject: [GHC] #2609: Compiling with -O2 is 7x slower than -O In-Reply-To: <046.42ce6b19d1fdc31890e2bf896b97f4f5@localhost> References: <046.42ce6b19d1fdc31890e2bf896b97f4f5@localhost> Message-ID: <055.79b0168de454019f1207761d3e02c791@localhost> #2609: Compiling with -O2 is 7x slower than -O ------------------------------------------+--------------------------------- Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:43:14 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:40:15 2008 Subject: [GHC] #2613: configure should summarize important results at the end of its run In-Reply-To: <044.0889aaee930d9a4ce299cdd9f349c45b@localhost> References: <044.0889aaee930d9a4ce299cdd9f349c45b@localhost> Message-ID: <053.73c5d62adb7b375e7c4d243de86604a4@localhost> #2613: configure should summarize important results at the end of its run -----------------------------+---------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:52:00 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:49:01 2008 Subject: [GHC] #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` In-Reply-To: <043.429d5e175a90219c9682c6f3937cb586@localhost> References: <043.429d5e175a90219c9682c6f3937cb586@localhost> Message-ID: <052.eed5f3416893b68d8fbf5a7477c30e6b@localhost> #2614: Enumeration of values for `Sys.Info.os`, `Sys.Info.arch` -----------------------------+---------------------------------------------- Reporter: jsnx | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 07:54:20 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:51:20 2008 Subject: [GHC] #2616: install script can't replace /usr/local/bin/runhaskell In-Reply-To: <044.47116bb1d681622f73ee4d9827568e26@localhost> References: <044.47116bb1d681622f73ee4d9827568e26@localhost> Message-ID: <053.5ba8283f02e519079e3991b6c7ba45f6@localhost> #2616: install script can't replace /usr/local/bin/runhaskell --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report; now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 08:02:38 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 07:59:40 2008 Subject: [GHC] #2617: GHC.Integer no longer exports S# and J# In-Reply-To: <044.45278722ce7acad4e6c3763b20241222@localhost> References: <044.45278722ce7acad4e6c3763b20241222@localhost> Message-ID: <053.c1dd71447bd0e2cdea249251b2bd31c6@localhost> #2617: GHC.Integer no longer exports S# and J# ---------------------+------------------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------+------------------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 08:25:27 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 08:22:28 2008 Subject: [GHC] #2623: Crypto-0.4.1 -- the impossible happened In-Reply-To: <043.3d955c8ddc2d1cdb6bdfa8d6071475f4@localhost> References: <043.3d955c8ddc2d1cdb6bdfa8d6071475f4@localhost> Message-ID: <052.b3d8432c1158798fd0a86ce57c978f23@localhost> #2623: Crypto-0.4.1 -- the impossible happened ----------------------+----------------------------------------------------- Reporter: jsnx | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report; this is fixed in 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 08:29:20 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 08:26:21 2008 Subject: [GHC] #2625: Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields In-Reply-To: <047.a4131859623f35304148b8ddaa8f3bbb@localhost> References: <047.a4131859623f35304148b8ddaa8f3bbb@localhost> Message-ID: <056.029fbcffa8a881a6546158209806ce0a@localhost> #2625: Unexpected -ddump-simpl output for derived Ord instance and UNPACKed fields ----------------------+----------------------------------------------------- Reporter: aslatter | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report; we'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 08:30:05 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 08:27:05 2008 Subject: [GHC] #2626: In ISO8601 the date and time should be separated by a 'T', not a space In-Reply-To: <053.3c40599d333cc0ff87ad32082ee97987@localhost> References: <053.3c40599d333cc0ff87ad32082ee97987@localhost> Message-ID: <062.398d9bcf0458a62b087b8abb055afb45@localhost> #2626: In ISO8601 the date and time should be separated by a 'T', not a space ----------------------------------+----------------------------------------- Reporter: MagnusTherning | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (old-time) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 08:46:44 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 08:43:45 2008 Subject: [GHC] #2620: `ghci --help` gives unhelpful error message In-Reply-To: <047.0e1b89a67baa9648b525964b885b7025@localhost> References: <047.0e1b89a67baa9648b525964b885b7025@localhost> Message-ID: <056.6331a75e6b3322b5aef07c80867b6b42@localhost> #2620: `ghci --help` gives unhelpful error message ----------------------+----------------------------------------------------- Reporter: Deewiant | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 08:49:42 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 08:46:43 2008 Subject: [GHC] #2619: Can't build HEAD with ghc-6.10 In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.100afaab581ec09e47929b97c8f9f876@localhost> #2619: Can't build HEAD with ghc-6.10 ----------------------+----------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 09:00:23 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 08:57:27 2008 Subject: [GHC] #2618: Order is relevant when matching signature contexts of a mutually recursive group In-Reply-To: <044.3cbe08640dd9401cf960fac9aa59e7db@localhost> References: <044.3cbe08640dd9401cf960fac9aa59e7db@localhost> Message-ID: <053.2932f28d933997af2184b1f5f4dd2814@localhost> #2618: Order is relevant when matching signature contexts of a mutually recursive group -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: I'm not sure off the top of my head if your example is supposed to work in H98, but if you use `-XRelaxedPolyRec` then it is accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From claus.reinke at talk21.com Thu Sep 25 10:58:38 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Sep 25 10:55:46 2008 Subject: [GHC] #2602: Haddock not installed properly References: <051.bff77834b377c6ec330f589afeeee640@localhost> <060.81f1a1fe77b5b1f1a241c636f5e904b8@localhost> Message-ID: <3FC945BA63D84B7CB14C898C4F463BFE@cr3lt> [using email instead of haddock trac, which still doesn't send notifications] The haddock package still has the wrong paths, though: $ /cygdrive/c/ghc/ghc-6.11.20080925/bin/ghc-pkg describe haddock | grep ghc import-dirs: d:/fptools/ghc/ghc-6.11.20080925\haddock-2.2.2 library-dirs: d:/fptools/ghc/ghc-6.11.20080925\haddock-2.2.2 extra-ghci-libraries: directory-1.0.0.2 filepath-1.1.0.1 ghc-6.11.20080925 haddock-html: d:/fptools/ghc/ghc-6.11.20080925/doc (pointing to build, rather than install directories) Claus ----- Original Message ----- From: "GHC" Cc: Sent: Thursday, September 25, 2008 12:41 PM Subject: Re: [GHC] #2602: Haddock not installed properly > #2602: Haddock not installed properly > --------------------------+------------------------------------------------- > Reporter: NeilMitchell | Owner: > Type: bug | Status: closed > Priority: normal | Milestone: > Component: Compiler | Version: 6.9 > Severity: normal | Resolution: fixed > Keywords: | Difficulty: Unknown > Testcase: | Architecture: Unknown > Os: Unknown | > --------------------------+------------------------------------------------- > Changes (by igloo): > > * status: new => closed > * difficulty: => Unknown > * resolution: => fixed > > Comment: > > Thanks for the report; now fixed. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler -------------------------------------------------------------------------------- > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > From claus.reinke at talk21.com Thu Sep 25 11:21:33 2008 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Sep 25 11:18:41 2008 Subject: [GHC] #2602: Haddock not installed properly References: <051.bff77834b377c6ec330f589afeeee640@localhost><060.81f1a1fe77b5b1f1a241c636f5e904b8@localhost> <3FC945BA63D84B7CB14C898C4F463BFE@cr3lt> Message-ID: <0A66C21DAC774F35B6EA7AF3CEE7EA44@cr3lt> haddock also does not seem to generate cross-package references correctly; some of them it warns about (second example below), some it just inserts wrongly, using $httptopdir/doc/libraries/ (first example below). Claus -- after installing haddocked syb-utils: $ grep -A2 IntSet /cygdrive/c/Program\ Files/Haskell/doc/syb-utils-0.0.2008.9.22/html/Data-Generics -GPS.html build IntSets of TypeRep keys, both for the domains of traversals and for substructure types; then several short-circuiting decisions can be based on fast intersection tests with the same IntSet).

keys combined with IntSets or IntMaps can be used to speed up other generic programming problems as well, including typecase and extensible records libraries. -- > = IntSet = IntSet [using email instead of haddock trac, which still doesn't send notifications] > > The haddock package still has the wrong paths, though: > > $ /cygdrive/c/ghc/ghc-6.11.20080925/bin/ghc-pkg describe haddock | grep ghc > import-dirs: d:/fptools/ghc/ghc-6.11.20080925\haddock-2.2.2 > library-dirs: d:/fptools/ghc/ghc-6.11.20080925\haddock-2.2.2 > extra-ghci-libraries: > directory-1.0.0.2 filepath-1.1.0.1 ghc-6.11.20080925 > haddock-html: d:/fptools/ghc/ghc-6.11.20080925/doc > > (pointing to build, rather than install directories) > > Claus > > ----- Original Message ----- > From: "GHC" > Cc: > Sent: Thursday, September 25, 2008 12:41 PM > Subject: Re: [GHC] #2602: Haddock not installed properly > > >> #2602: Haddock not installed properly >> --------------------------+------------------------------------------------- >> Reporter: NeilMitchell | Owner: Type: bug | Status: closed >> Priority: normal | Milestone: Component: Compiler | Version: >> 6.9 Severity: normal | Resolution: fixed Keywords: | >> Difficulty: Unknown >> Testcase: | Architecture: Unknown >> Os: Unknown >> | --------------------------+------------------------------------------------- >> Changes (by igloo): >> >> * status: new => closed >> * difficulty: => Unknown >> * resolution: => fixed >> >> Comment: >> >> Thanks for the report; now fixed. >> >> -- >> Ticket URL: >> GHC >> The Glasgow Haskell Compiler > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> Glasgow-haskell-bugs mailing list >> Glasgow-haskell-bugs@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs >> > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs From trac at galois.com Thu Sep 25 13:51:38 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 13:48:37 2008 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.11116a8b48b5fae19bc0b4e96a75d14d@localhost> #2467: orphan instance warnings are badly behaved ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: igloo => * milestone: 6.10.1 => 6.12 branch Comment: In order to do mtl we'd need to move at least the `MonadPlus IO` instance into the base package, so I'm remilestoning this for 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 14:22:28 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 14:19:49 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.d93515efdc90a6aab0671bb585992f60@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): Re: {{{ With overlap allowed, it's clear that you can make different choices in different parts of the program. }}} I don't agree. While I can see that you would want to commit to an instance early for optimisation reasons, I think you should then fail when linking if it turns out that you would have made a different choice had all of the program's instances been available. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 15:08:53 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 15:05:55 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.b52734fba3127032996a8a4cf390b23c@localhost> #2081: GHC reports internal error: stg_ap_v_ret -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Comment (by thorkilnaur): The original problem was reported against a GHC HEAD pulled around 2008-Feb-03. I am warming up my PPC Mac OS X 10.4 GHC HEAD, intending to see whether the problem is still there. In the meantime, the PPC Mac OS X 10.5 builders, both HEAD (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/138) and STABLE (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20stable%202/builds/175), currently get a report like {{{ =====> arr001(normal) cd ./array/should_run && '/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2 /tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore- lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output -o arr001 arr001.hs >arr001.comp.stderr 2>&1 timeout: internal error: stg_ap_p_ret (GHC version 6.11.20080925 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Compile failed (status -1536) errors were: *** unexpected failure for arr001(normal) }}} for all tests, as far as I can tell. The latest head summary reports: {{{ OVERALL SUMMARY for test run started at Thu Sep 25 05:40:29 CEST 2008 2138 total tests, which gave rise to 6607 test cases, of which 1864 caused framework failures 1057 were skipped 274 expected passes 167 expected failures 1 unexpected passes 3244 unexpected failures }}} I can reproduce like this: {{{ $ ./timeout 200 'echo Something' timeout: internal error: stg_ap_p_ret (GHC version 6.11.20080925 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Something Abort trap $ }}} I have not attempted to investigate further. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 15:23:41 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 15:20:41 2008 Subject: [GHC] #2620: `ghci --help` gives unhelpful error message In-Reply-To: <047.0e1b89a67baa9648b525964b885b7025@localhost> References: <047.0e1b89a67baa9648b525964b885b7025@localhost> Message-ID: <056.f4191ef364b781dc3cc34554cfa2c0c6@localhost> #2620: `ghci --help` gives unhelpful error message ----------------------+----------------------------------------------------- Reporter: Deewiant | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Comment (by igloo): Thanks for the report. Fixed by {{{ Thu Sep 25 17:56:18 BST 2008 Ian Lynagh * Fix the behaviour of flags like --help and --version; fixes trac #2620 They should override other mode flags, not conflict with them }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 15:27:41 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 15:24:41 2008 Subject: [GHC] #2617: GHC.Integer no longer exports S# and J# In-Reply-To: <044.45278722ce7acad4e6c3763b20241222@localhost> References: <044.45278722ce7acad4e6c3763b20241222@localhost> Message-ID: <053.ce809cf557583a334efb6d2c38a88bfa@localhost> #2617: GHC.Integer no longer exports S# and J# ---------------------+------------------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: GHC API | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report. You can now get the constructors from `GHC.Integer.Internals`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 15:28:34 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 15:25:33 2008 Subject: [GHC] #2620: `ghci --help` gives unhelpful error message In-Reply-To: <047.0e1b89a67baa9648b525964b885b7025@localhost> References: <047.0e1b89a67baa9648b525964b885b7025@localhost> Message-ID: <056.2002d14c0b5e8450a691754c261dfd8b@localhost> #2620: `ghci --help` gives unhelpful error message ----------------------+----------------------------------------------------- Reporter: Deewiant | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 15:52:41 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 15:49:43 2008 Subject: [GHC] #303: Rebindable syntax doesn't work as advertised In-Reply-To: <045.7b729482dce9becb714515c500865892@localhost> References: <045.7b729482dce9becb714515c500865892@localhost> Message-ID: <054.e9362bc1acf73dfa0f27600591e502a4@localhost> #303: Rebindable syntax doesn't work as advertised ----------------------------------------+----------------------------------- Reporter: nobody | Owner: nobody Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Changes (by ryani): * status: closed => reopened * os: => Unknown * testcase: => * version: 6.4 => 6.8.3 * architecture: => Unknown * resolution: Fixed => Comment: This seems to be broken in 6.8.3, at least for "weird" monad types. Test case follows: {{{ {-# LANGUAGE NoImplicitPrelude #-} module T where import qualified Prelude as P class IxMonad m where return :: a -> m i i a (>>=) :: m i j a -> (a -> m j k b) -> m i k b (>>) :: m i j a -> m j k b -> m i k b m >> n = m >>= \_ -> n fail :: P.String -> m i j a fail s = P.error s data T a b c = T instance IxMonad T where return _ = T m >>= f = T fail _ = T testM :: T (a,b) b a testM = T test1 = testM >>= \x -> return x test2 = do x <- testM return x }}} test1 compiles fine, but test2 (which should be identical up-to-sugaring) fails. {{{ $ ghc -c -XNoImplicitPrelude T.hs T.hs:27:3: Occurs check: cannot construct the infinite type: b = (a, b) Expected type: T (a, b) b t Inferred type: T (a, b) (a, b) a In the expression: return x In the expression: do x <- testM return x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 15:59:04 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 15:56:04 2008 Subject: [GHC] #303: Rebindable syntax doesn't work as advertised In-Reply-To: <045.7b729482dce9becb714515c500865892@localhost> References: <045.7b729482dce9becb714515c500865892@localhost> Message-ID: <054.40286de9e530c75b009000fae47fbf0c@localhost> #303: Rebindable syntax doesn't work as advertised ----------------------------------------+----------------------------------- Reporter: nobody | Owner: nobody Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Changes (by ryani): * cc: ryani.spam@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 16:29:04 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 16:26:06 2008 Subject: [GHC] #789: BCOs can only have 64k instructions In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.6a024898fc1d464df40a698f806fe74d@localhost> #789: BCOs can only have 64k instructions ---------------------+------------------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------+------------------------------------------------------ Comment (by guest): I'm seeing this message when trying to load an Alex-generated lexer into GHCi. It works for normal compilation with GHC though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 16:44:45 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 16:41:46 2008 Subject: [GHC] #789: BCOs can only have 64k instructions In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.2eb243e4d18983efcd0a822ceb5fc51d@localhost> #789: BCOs can only have 64k instructions ---------------------+------------------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------+------------------------------------------------------ Comment (by guest): BTW. using "alex -g" is a workaround (not for this bug, but for everyone running into it via alex). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 18:10:18 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 18:07:38 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.ce30e9c0ebf66534414d9ffee620e42a@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by claus): some comments in this thread: instance visibility (was: Re: The base library and GHC 6.10) http://www.haskell.org/pipermail/libraries/2008-September/010717.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 19:11:03 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 19:08:02 2008 Subject: [GHC] #303: Rebindable syntax doesn't work as advertised In-Reply-To: <045.7b729482dce9becb714515c500865892@localhost> References: <045.7b729482dce9becb714515c500865892@localhost> Message-ID: <054.287dc10fe63ec64c0d5e0cd9d149957b@localhost> #303: Rebindable syntax doesn't work as advertised -------------------------------------+-------------------------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: rebindable/T303 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * testcase: => rebindable/T303 * difficulty: => Unknown * status: reopened => closed * resolution: => duplicate Old description: > {{{ > -- > -- According to section 7.3.5. Rebindable syntax in the > user's manual > -- this should work (unless I totally misunderstood it). > -- It doesn't. > -- > -- Compile with -fno-implicit-prelude > -- > -- Lennart > -- > > import Prelude hiding(Monad(..)) > > class B a where > b :: a > > instance B Bool where > b = False > > class M m where > return :: a -> m a > (>>=) :: (B a) => m a -> (a -> m b) -> m b > (>>) :: (B a) => m a -> m b -> m b > fail :: String -> m a > > p >> q = p >>= \ _ -> q > fail s = error s > > instance M Maybe where > return x = Just x > (>>=) = error "bind" > > test :: Maybe Bool > test = do > x <- return True > return (x && x) > > unJust (Just x) = x > > main = print (unJust test) > > }}} New description: {{{ -- -- According to section 7.3.5. Rebindable syntax in the user's manual -- this should work (unless I totally misunderstood it). -- It doesn't. -- -- Compile with -fno-implicit-prelude -- -- Lennart -- import Prelude hiding(Monad(..)) class B a where b :: a instance B Bool where b = False class M m where return :: a -> m a (>>=) :: (B a) => m a -> (a -> m b) -> m b (>>) :: (B a) => m a -> m b -> m b fail :: String -> m a p >> q = p >>= \ _ -> q fail s = error s instance M Maybe where return x = Just x (>>=) = error "bind" test :: Maybe Bool test = do x <- return True return (x && x) unJust (Just x) = x main = print (unJust test) }}} Comment: This is really a dup of #1537, which was fixed last year but never got into 6.8. Works in HEAD (and hence the upcoming GHC 6.10). However, I've added your program as a new test case in the regression test suite `rebindable/T303`, so that we'll know if it ever fails in the future. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 25 19:29:45 2008 From: trac at galois.com (GHC) Date: Thu Sep 25 19:26:45 2008 Subject: [GHC] #2618: Order is relevant when matching signature contexts of a mutually recursive group In-Reply-To: <044.3cbe08640dd9401cf960fac9aa59e7db@localhost> References: <044.3cbe08640dd9401cf960fac9aa59e7db@localhost> Message-ID: <053.9298a0dea15d1f478181281470f1388f@localhost> #2618: Order is relevant when matching signature contexts of a mutually recursive group -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: It's part of the Haskell 98 spec; see the last sentence of Section 4.5.2 http://haskell.org/onlinereport/decls.html#generalization As Ian says, the `-XRelaxedPolyRec` flag lifts this restriction. I'll close the bug as invalid. But don't let that discourage you from reporting bugs. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 26 02:59:29 2008 From: trac at galois.com (GHC) Date: Fri Sep 26 02:56:28 2008 Subject: [GHC] #2627: GADT + Type family doesn't unify like I expect Message-ID: <044.4166c66675f16702cbe4b15c24b7a007@localhost> #2627: GADT + Type family doesn't unify like I expect ------------------------+--------------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- I'd expect this program to compile; the "given" equations in "conn" should add additional constraints to the types determined by the GADT. Instead it looks like (Dual a) is failing to unify with (R _ _), and the same for (Dual b) and (W _ _). {{{ {-# LANGUAGE GADTs, TypeFamilies, EmptyDataDecls #-} module Dual where data R a b data W a b data Z type family Dual a type instance Dual Z = Z type instance Dual (R a b) = W a (Dual b) type instance Dual (W a b) = R a (Dual b) data Comm a where Rd :: (a -> Comm b) -> Comm (R a b) Wr :: a -> Comm b -> Comm (W a b) Fin :: Int -> Comm Z conn :: (Dual a ~ b, Dual b ~ a) => Comm a -> Comm b -> (Int, Int) conn (Fin x) (Fin y) = (x,y) conn (Rd k) (Wr a r) = conn (k a) r conn (Wr a r) (Rd k) = conn r (k a) }}} Running off of GHC HEAD: {{{The Glorious Glasgow Haskell Compilation System, version 6.11.20080925}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 26 08:33:39 2008 From: trac at galois.com (GHC) Date: Fri Sep 26 08:30:56 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.6e2c1154ae7d4a2bf065b3868987d242@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by claus): Replying to [comment:8 igloo]: > Here is an example of Data.Set going wrong due to multiple instances: That depends on what you define as wrong, doesn't it?-) In the Haskell'98 view, there is at most one instance for a class/type, so if you give such an instance, you may conclude that it is the only one, so the behaviour is wrong. In the Ghc view, local instances are supported unless they actually conflict in use, so you may not conclude that the instance you see is the only one there'll ever be, so the behaviour is not wrong per se, just one of many possible behaviours. In particular, you explicitly force Ghc to commit to the local instances leaving it no room for using other instances or reporting conflicts. If the functions where `memberBy` and `fromListBy`, with explicit comparison parameters, you're supplying the comparisons at the point of definition for `f` and `s`, instead of allowing them to be supplied at the point of use (where a conflict between differing comparisons might be noted). If, instead you ask Ghc to leave the instances to use open, the behaviour will be closer to what you expected: {{{ s :: Set Foo f :: Set Foo -> Bool }}} would become (needs `{-# LANGUAGE FlexibleContexts #-}`) {{{ s :: Ord Foo => Set Foo f :: Ord Foo => Set Foo -> Bool }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 26 11:22:01 2008 From: trac at galois.com (GHC) Date: Fri Sep 26 11:18:59 2008 Subject: [GHC] #1348: inconsistent 'ghc --help" message In-Reply-To: <044.40c02a1b9d8104e641ba174ea3f5e40e@localhost> References: <044.40c02a1b9d8104e641ba174ea3f5e40e@localhost> Message-ID: <053.11babcb9f008f9911aa4102482739110@localhost> #1348: inconsistent 'ghc --help" message ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now fixed: {{{ Fri Sep 26 15:05:39 BST 2008 Ian Lynagh * Split ShowVersion etc off into a different type to DoInteractive etc This fixes trac #1348 (ghci --help gave ghc's help), and also tidies things up a bit. Things would be even tidier if the usage.txt files were put into a .hs file, so that ShowUsage wouldn't need to be able to find the libdir. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 26 11:22:23 2008 From: trac at galois.com (GHC) Date: Fri Sep 26 11:19:33 2008 Subject: [GHC] #2477: -package-conf flag makes runghc fail In-Reply-To: <043.3badf8aec8b2932c76550c9b14657312@localhost> References: <043.3badf8aec8b2932c76550c9b14657312@localhost> Message-ID: <052.85bfdd729d7be546260a177f7e044e42@localhost> #2477: -package-conf flag makes runghc fail ---------------------------+------------------------------------------------ Reporter: fons | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri Sep 26 13:44:25 BST 2008 Ian Lynagh * Improve runghc docs; fixes trac #2477 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 26 13:30:34 2008 From: trac at galois.com (GHC) Date: Fri Sep 26 13:27:35 2008 Subject: [GHC] #2627: GADT + Type family doesn't unify like I expect In-Reply-To: <044.4166c66675f16702cbe4b15c24b7a007@localhost> References: <044.4166c66675f16702cbe4b15c24b7a007@localhost> Message-ID: <053.266f9029d01c315806186a62a7f58522@localhost> #2627: GADT + Type family doesn't unify like I expect -------------------------------------+-------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: => chak * difficulty: => Unknown Comment: Nice example -- just the kind of interaction between GADTs and type functions that should now work. I've convinced myself that your code should indeed compile. I stripped out a couple of eqns in the example, and wrote out the derivation that shows it should typecheck. Manuel, over to you! Simon {{{ conn :: (Dual a ~ b, Dual b ~ a) => Comm a -> Comm b -> (Int, Int) conn (Rd k) (Wr a r) = conn (k a) r -- conn (Fin x) (Fin y) = (x,y) -- conn (Wr a r) (Rd k) = conn r (k a) {- Simon's reasoning Given :: Dual a ~ b, Dual b ~ a (sig) a ~ R a1 b1, b ~ W a2 b2 (gadt match) k :: a1 -> Con b1 a :: a2 r :: Conn b2 Instantiate conn at: ai, bi (unification variables) Wanted: Dual ai ~ bi, Dual bi ~ ai first arg: a1~a2, b1~ai second: b2~bi Fixing the unification variables is easy: ai:=b1, bi:=b2 The interesting thing is figuring out that a1~a2 Wanted: a1~a2 Given: Dual a ~ b => (substitute for a) Dual (R a1 b1) ~ b => (top-level eqn) W a1 (Dual b1) ~ b => (substitute for b) W a1 (Dual b1) ~ W a2 b2 => (decompose) a1~a2 -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 26 13:34:51 2008 From: trac at galois.com (GHC) Date: Fri Sep 26 13:31:51 2008 Subject: [GHC] #2627: GADT + Type family doesn't unify like I expect In-Reply-To: <044.4166c66675f16702cbe4b15c24b7a007@localhost> References: <044.4166c66675f16702cbe4b15c24b7a007@localhost> Message-ID: <053.027b5998dbb0f4023dc89a053a3d55b1@localhost> #2627: GADT + Type family doesn't unify like I expect -------------------------------------+-------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonpj): PS. The error message looks like {{{ T2627.hs:19:13: Couldn't match expected type `b2' against inferred type `Dual b1' `b2' is a rigid type variable bound by the constructor `Wr' at T2627.hs:19:13 In the pattern: Wr a r In the definition of `conn': conn (Rd k) (Wr a r) = conn (k a) r }}} but I'd expect it to say something like "cannot deduce `(b2 ~ Dual b1)` from from `(b ~ Dual a, a ~ Dual b, ... blah blah)`". The current error message is really only right for things like "cannot unify `[a]` against `Maybe Int`" or something. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 26 15:09:53 2008 From: trac at galois.com (GHC) Date: Fri Sep 26 15:06:56 2008 Subject: [GHC] #2627: GADT + Type family doesn't unify like I expect In-Reply-To: <044.4166c66675f16702cbe4b15c24b7a007@localhost> References: <044.4166c66675f16702cbe4b15c24b7a007@localhost> Message-ID: <053.5b16a6f9dcc24bee9f74645c6e69744e@localhost> #2627: GADT + Type family doesn't unify like I expect -------------------------------------+-------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by ryani): While playing around with this I also found a crash bug: {{{conn (Rd k) (Wr a r) = undefined -- typechecks successfully}}} {{{conn (Rd k) (Wr a r) = conn undefined undefined -- crashes}}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.11.20080925 for i386-apple-darwin): TcTyFuns.uMeta: unexpected synonym family }}} Interestingly, this example just fails to typecheck: {{{urk () = conn undefined undefined}}} with an unhelpful error message: {{{ Dual.hs:1:0: Couldn't match expected type `a' against inferred type `Dual (Dual a)' }}} Note the line number of the error... If I remove the () to force the monomorphism restriction to kick in, the line number is more helpful. I find it fascinating that with type equality constraints, "undefined" is no longer a valid argument at all call-sites. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 26 17:59:45 2008 From: trac at galois.com (GHC) Date: Fri Sep 26 17:56:41 2008 Subject: [GHC] #2591: Explain +RTS -t/s/S output text In-Reply-To: <044.b626aec8f565e89dd926bf4290b84a90@localhost> References: <044.b626aec8f565e89dd926bf4290b84a90@localhost> Message-ID: <053.bbabcec70162f4cdd39422f99fbcb177@localhost> #2591: Explain +RTS -t/s/S output text ---------------------------+------------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed * summary: Explain +RTS -xt output text => Explain +RTS -t/s/S output text Comment: Fixed: {{{ Fri Sep 26 21:02:03 BST 2008 Ian Lynagh * Add some description of the +RTS -t/-s/-S output }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 26 18:00:13 2008 From: trac at galois.com (GHC) Date: Fri Sep 26 17:57:10 2008 Subject: [GHC] #2501: [Document] Is it possible to add an example to show how to use SCC in profiling? Moreover, there seems no explaination for +RTS -s -S In-Reply-To: <049.55daf57c282859db865e658846ee4aed@localhost> References: <049.55daf57c282859db865e658846ee4aed@localhost> Message-ID: <058.d33d04cad331aade3e54dafc0f326fc3@localhost> #2501: [Document] Is it possible to add an example to show how to use SCC in profiling? Moreover, there seems no explaination for +RTS -s -S ---------------------------+------------------------------------------------ Reporter: rivercheng | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: SCC profiling | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri Sep 26 21:38:32 BST 2008 Ian Lynagh * Add an example of how to use SCCs to the user guide Fri Sep 26 21:02:03 BST 2008 Ian Lynagh * Add some description of the +RTS -t/-s/-S output Shall I push this patch? (4/5) [ynWvpxqadjk], or ? for help: y }}} Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 10:23:21 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 10:20:16 2008 Subject: [GHC] #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. In-Reply-To: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> References: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> Message-ID: <052.db9d51882b5633d0c7d8ef6e7add62a8@localhost> #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. ----------------------------+----------------------------------------------- Reporter: sclv | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Fri Sep 26 16:28:06 PDT 2008 Simon Marlow * Fix #2411: missing case for CATCH_STM_FRAME in raiseAsync() }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 10:38:09 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 10:35:04 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.b4e1c2ef50dae9860a5a01e31ccab794@localhost> #2081: GHC reports internal error: stg_ap_v_ret -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Comment (by thorkilnaur): I am no longer able to produce the error message {{{internal error: stg_ap_p_ret}}} using the method originally described (compiling a program with GHC HEAD while spending resources in a separate process). I have looked a bit more into the timeout case: As I read what happens, timeout.hs is compiled using the stage1 inplace compiler. And: {{{ $ uname -a Darwin thorkil-naurs-mac-mini.local 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:36:17 PDT 2008; root:xnu-1228.5.20~1/RELEASE_PPC Power Macintosh $ /Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx- head-2/build/ghc/stage1-inplace/ghc -fforce-recomp --make timeout.hs [1 of 1] Compiling Main ( timeout.hs, timeout.o ) Linking timeout ... $ ./timeout 200 'echo Something' Something $ /Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2/tnaur-ppc-osx- head-2/build/ghc/stage1-inplace/ghc -fforce-recomp --make timeout.hs -O2 [1 of 1] Compiling Main ( timeout.hs, timeout.o ) Linking timeout ... $ ./timeout 200 'echo Something' timeout: internal error: stg_ap_p_ret (GHC version 6.11.20080927 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Something Abort trap $ }}} So {{{-O2}}} makes a difference. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 11:21:43 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 11:18:43 2008 Subject: [GHC] #2603: Crash on Korn shell on Windows XP In-Reply-To: <051.5626caf3a9b026fab0cf28ae90fdd1a7@localhost> References: <051.5626caf3a9b026fab0cf28ae90fdd1a7@localhost> Message-ID: <060.9594573583ec09cd7dab7976340a6d19@localhost> #2603: Crash on Korn shell on Windows XP --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 12:01:05 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 11:57:59 2008 Subject: [GHC] #2619: Can't build HEAD with ghc-6.10 In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.7338fac1bb1a3be2c4660127fbe26f94@localhost> #2619: Can't build HEAD with ghc-6.10 ----------------------+----------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by igloo): Hmm, I can't reproduce this problem. How are you building the HEAD? Does it work for you if you use this installer? http://www.haskell.org/ghc/dist/stable/dist/GHC-6.10.0.20080921-i386.pkg -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 12:18:15 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 12:15:17 2008 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@localhost> References: <046.37416aee19ee095c9a6e98285b215b72@localhost> Message-ID: <055.d99930e46f08ca3f7876a0ff86e7d859@localhost> #915: Implement list fusion using streams instead of foldr/build ----------------------------+----------------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8 Severity: normal | Resolution: Keywords: fusion | Difficulty: Project (> 1 week) Testcase: N/A | Architecture: Multiple Os: Unknown | ----------------------------+----------------------------------------------- Changes (by Deewiant): * cc: Deewiant (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 12:20:16 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 12:17:14 2008 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@localhost> References: <046.37416aee19ee095c9a6e98285b215b72@localhost> Message-ID: <055.65dd1e38190541a30330746a977fcbc6@localhost> #915: Implement list fusion using streams instead of foldr/build ----------------------------+----------------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8 Severity: normal | Resolution: Keywords: fusion | Difficulty: Project (> 1 week) Testcase: N/A | Architecture: Multiple Os: Unknown | ----------------------------+----------------------------------------------- Comment (by dons): This library has been written and released, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion To replace GHC's existing list fusion, we'll need to work out how concatMap is optimised, and push the desugaring for list comprehensions into GHC. For now though, users can just use the library, and avoid list comprehensions and [n .. m] (use enumFromTo). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 12:25:13 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 12:22:09 2008 Subject: [GHC] #2295: Combined -odir/-hidir flag In-Reply-To: <051.3ec75d5010176a8f7458111511793c49@localhost> References: <051.3ec75d5010176a8f7458111511793c49@localhost> Message-ID: <060.46172c98f3a49ecbab46d62320561ea5@localhost> #2295: Combined -odir/-hidir flag --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by simonmar): * owner: => igloo * type: feature request => merge Comment: Done: {{{ Sat Sep 27 15:18:22 BST 2008 Simon Marlow * Add -outputdir flag (#2295) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 13:27:04 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 13:23:58 2008 Subject: [GHC] #2628: isatty behaves unexpectedly on mingw Message-ID: <044.c1bd1c3ac0471340a6fae29b24f965a3@localhost> #2628: isatty behaves unexpectedly on mingw -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: 2228 Architecture: x86 | Os: Windows -------------------------------+-------------------------------------------- test 2228 is failing for me in an msys window on Windows: {{{ -BlockBuffering Nothing +LineBuffering BlockBuffering Nothing }}} because isatty behaves unexpectedly on mingw: {{{ #include #include int main(void) { int i; i = fileno(stdin); printf("%d\n", i); i = fileno(stdout); printf("%d\n", i); i = isatty(0); printf("%d\n", i); i = isatty(1); printf("%d\n", i); return 0; } }}} {{{ $ ./w 0 1 0 0 $ ./w < /dev/null 0 1 64 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 13:40:11 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 13:37:06 2008 Subject: [GHC] #2619: Can't build HEAD with ghc-6.10 In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.79bd249e163e177e396db76b6f6f9831@localhost> #2619: Can't build HEAD with ghc-6.10 ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 13:41:58 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 13:38:52 2008 Subject: [GHC] #2495: Source dist should include Happy/Alex-generated sources In-Reply-To: <047.edfee026faeed124911f8a005cc577d9@localhost> References: <047.edfee026faeed124911f8a005cc577d9@localhost> Message-ID: <056.58b6afd8d046a2bc80c7e99fd672abe3@localhost> #2495: Source dist should include Happy/Alex-generated sources --------------------------+------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 13:49:50 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 13:46:45 2008 Subject: [GHC] #2484: ghc 6.8.2 broken after Security Update 2008-005 (PPC) on Mac OS 10.4.11 In-Reply-To: <044.a2618a27f261a948044540a6bc0d6d47@localhost> References: <044.a2618a27f261a948044540a6bc0d6d47@localhost> Message-ID: <053.53a73f7b2e8f69203e4de467dd22577b@localhost> #2484: ghc 6.8.2 broken after Security Update 2008-005 (PPC) on Mac OS 10.4.11 ----------------------+----------------------------------------------------- Reporter: knarF | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: Unreproducible, and no response from submitter. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 13:54:53 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 13:51:47 2008 Subject: [GHC] #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin In-Reply-To: <047.918ccc59a875951e79ffd2348c4375d6@localhost> References: <047.918ccc59a875951e79ffd2348c4375d6@localhost> Message-ID: <056.c633cf22e0ce6370bf38aaa4b05b7642@localhost> #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin --------------------------+------------------------------------------------- Reporter: jimwhite | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Comment (by igloo): Are you able to test whether the GHC 6.10.1 beta works for you, please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 15:41:50 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 15:38:43 2008 Subject: [GHC] #2357: Implement the Haskell' proposal for polymorphic pattern bindings In-Reply-To: <047.95a1ebaf86eb581f2f41f8ae61094ccc@localhost> References: <047.95a1ebaf86eb581f2f41f8ae61094ccc@localhost> Message-ID: <056.d26d1b4847d494c0a9d7999c4f5289b3@localhost> #2357: Implement the Haskell' proposal for polymorphic pattern bindings -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 15:43:16 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 15:40:09 2008 Subject: [GHC] #2338: unpack primitive types by default in data? and NOUNPACK? In-Reply-To: <051.acef913b312de6cf127d683143b322b3@localhost> References: <051.acef913b312de6cf127d683143b322b3@localhost> Message-ID: <060.f1739836adfb30fe8fa36b22caa06ed5@localhost> #2338: unpack primitive types by default in data? and NOUNPACK? -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 17:15:25 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 17:12:18 2008 Subject: [GHC] #2377: Building ghc-api with profiling fails during install In-Reply-To: <042.889e74131a43acb30fedce713d1f1022@localhost> References: <042.889e74131a43acb30fedce713d1f1022@localhost> Message-ID: <051.2cec2dfa156d281417388d1df57a17b5@localhost> #2377: Building ghc-api with profiling fails during install ----------------------+----------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report; I can reproduce this with 6.8.3, but it's fixed in the 6.10 branch. You need {{{ echo "GhcLibProfiled=YES" >> mk/build.mk }}} instead in 6.10, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 19:01:17 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 18:58:11 2008 Subject: [GHC] #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto-all' In-Reply-To: <045.6d20356736e6fa3c22e35dd97141b722@localhost> References: <045.6d20356736e6fa3c22e35dd97141b722@localhost> Message-ID: <054.08d3896f826c09a7d2fb143637791044@localhost> #2410: HEAD build fails when building way=p with WAY_p_OPTS='-prof -caf-all -auto- all' ----------------------+----------------------------------------------------- Reporter: pgavin | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by igloo): Testcase: {{{ module C where data RealFloat a => Complex a = !a :+ !a deriving (Eq, Show) instance (RealFloat a) => Num (Complex a) where {-# SPECIALISE instance Num (Complex Float) #-} {-# SPECIALISE instance Num (Complex Double) #-} (x :+ y) + (x' :+ y') = (x + x') :+ (y + y') }}} With 6.11.20080927: {{{ $ ghc -prof -caf-all -auto-all -O2 -c C.hs -fforce-recomp /tmp/ghc31271_0/ghc31271_0.s: Assembler messages: /tmp/ghc31271_0/ghc31271_0.s:14944:0: Error: symbol `C_a_CAF_cc_ccs' is already defined /tmp/ghc31271_0/ghc31271_0.s:14976:0: Error: symbol `C_a_CAF_cc_ccs' is already defined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 19:10:28 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 19:07:31 2008 Subject: [GHC] #2354: NOINLINE pragma ignored In-Reply-To: <044.82d464aa2a8db887c5d15527893ee9e8@localhost> References: <044.82d464aa2a8db887c5d15527893ee9e8@localhost> Message-ID: <053.f8caa4dc7abac294610f992568853a9d@localhost> #2354: NOINLINE pragma ignored ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 20:19:41 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 20:16:38 2008 Subject: [GHC] #2012: compiling via-C does not work on ppc In-Reply-To: <045.6ad3ccd84b7b179a5baec1657fb43453@localhost> References: <045.6ad3ccd84b7b179a5baec1657fb43453@localhost> Message-ID: <054.069b972bedc30712099b1d55dfc4ea62@localhost> #2012: compiling via-C does not work on ppc ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.12 branch Comment: I don't think we're likely to fix this before -fvia-C is removed in 6.12. The workaround is just to use `-fasm`, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 27 22:49:50 2008 From: trac at galois.com (GHC) Date: Sat Sep 27 22:46:43 2008 Subject: [GHC] #2619: Can't build HEAD with ghc-6.10 In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.e6c9f921ce170e6f23aecc3f4f78f7c6@localhost> #2619: Can't build HEAD with ghc-6.10 ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by judah): I'm building HEAD with {{{BuildFlavor = quickest}}}. I deleted the ghc files from the tarball and installed the above package. Using that, HEAD built and installed without incident. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 28 03:00:27 2008 From: trac at galois.com (GHC) Date: Sun Sep 28 02:57:33 2008 Subject: [GHC] #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith Message-ID: <050.f409c69b6469259efa640144979533d8@localhost> #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith ----------------------------+----------------------------------------------- Reporter: Bart Massey | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: | Severity: minor Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------+----------------------------------------------- Everyone always complains about nub, but nobody ever does anything about it except (map head . group . sort), which isn't lazy and isn't always faster. :-) I've implemented a new function nubWith that takes a "stop list" as an argument and filters its target list against the stop list. I've then re- implemented nub and implemented nubOrd and nubInt in terms of nubWith: the stop list is a typeclass, so these implementations are trivial and new implementations are easily added. nubBy is left alone, since there's nothing obvious to be done about it. All of the nubs are still fully lazy. Basic !QuickCheck tests are provided, and pass. Performance benchmarking code is provided. The performance of my nub implementation is quite comparable to that of the standard one. My nubOrd and nubInt implementations are dramatically faster, since they use a Set and !IntSet respectively for the stop list. In particular, they are performant on long lists with long nubs, unlike the basic nub. My implementation is available via git at git://svcs.cs.pdx.edu/git/nub.git or can be browsed at http://svcs.cs.pdx.edu/gitweb?p=nub.git;a=tree and has a maybe-outdated tarball at http://svcs.cs.pdx.edu/haskell/nub.tar.gz The Nub.hs file itself is attached to this proposal. If the proposal is accepted, I will prepare a patch against current GHC library top-of-tree, but for now it seems easier for everyone to just look at the bits in their current natural habitat. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 28 03:19:03 2008 From: trac at galois.com (GHC) Date: Sun Sep 28 03:16:09 2008 Subject: [GHC] #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <050.f409c69b6469259efa640144979533d8@localhost> References: <050.f409c69b6469259efa640144979533d8@localhost> Message-ID: <059.c39b8b8d4e6fe7ac9b46c29cc60a5509@localhost> #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith -------------------------------+-------------------------------------------- Reporter: Bart Massey | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Severity: minor | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------------+-------------------------------------------- Comment (by Bart Massey): Oops. Forgot I don't have the Haddock done yet. Will finish in the next few minutes and submit. Also, forgot to include a discussion period. I think two weeks should be suitable. My apologies. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 28 03:38:23 2008 From: trac at galois.com (GHC) Date: Sun Sep 28 03:35:28 2008 Subject: [GHC] #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith In-Reply-To: <050.f409c69b6469259efa640144979533d8@localhost> References: <050.f409c69b6469259efa640144979533d8@localhost> Message-ID: <059.ff93093ebddc15436a14f8db09df4c9f@localhost> #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith -------------------------------+-------------------------------------------- Reporter: Bart Massey | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Severity: minor | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------------+-------------------------------------------- Comment (by Bart Massey): OK, the Haddock is now up. I've reattached the documented source code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 28 06:59:39 2008 From: trac at galois.com (GHC) Date: Sun Sep 28 06:56:32 2008 Subject: [GHC] #2619: Can't build HEAD with ghc-6.10 In-Reply-To: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> References: <044.186108a575a6c194091f1f6cfd66d1a5@localhost> Message-ID: <053.15a9168a55a9ca56f474497558c0c039@localhost> #2619: Can't build HEAD with ghc-6.10 ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Sounds like this is fixed, then. Thanks for testing! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 28 07:35:33 2008 From: trac at galois.com (GHC) Date: Sun Sep 28 07:32:24 2008 Subject: [GHC] #2132: Optimise nested comparisons In-Reply-To: <046.ba0b25228872b80f2daed8d0d0f8352f@localhost> References: <046.ba0b25228872b80f2daed8d0d0f8352f@localhost> Message-ID: <055.1c7ee617c63694235a41f1daa16e2fc4@localhost> #2132: Optimise nested comparisons --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 28 07:40:23 2008 From: trac at galois.com (GHC) Date: Sun Sep 28 07:37:15 2008 Subject: [GHC] #2147: unhelpful error message for a misplaced DEPRECATED pragma In-Reply-To: <044.4706a1b0e36567a842f434c8ed45f7f6@localhost> References: <044.4706a1b0e36567a842f434c8ed45f7f6@localhost> Message-ID: <053.63da4b433b02fc0a567a02f203f7caab@localhost> #2147: unhelpful error message for a misplaced DEPRECATED pragma ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Old description: > The error message on a misplaced DEPRECATED pragma is less than helpful. > Note that it was the latter of these that bit me. > > '''% cat Main.hs''' > > module Main where > > import Foo.Bar > > main = return () > > '''% cat Foo/Bar.hs''' > {-# DEPRECATED foo "bar" #-} > > module Foo.Bar (foo) where > > foo = undefined > > '''% ghc -c Foo/Bar.hs''' > > Foo/Bar.hs:4:0: parse error on input `module' > > '''% ghc --make Main.hs''' > > Foo/Bar.hs:1:0: file name does not match module name `Main' New description: The error message on a misplaced DEPRECATED pragma is less than helpful. Note that it was the latter of these that bit me. '''% cat Main.hs''' {{{ module Main where import Foo.Bar main = return () }}} '''% cat Foo/Bar.hs''' {{{ {-# DEPRECATED foo "bar" #-} module Foo.Bar (foo) where foo = undefined }}} '''% ghc -c Foo/Bar.hs''' Foo/Bar.hs:4:0: parse error on input `module' '''% ghc --make Main.hs''' Foo/Bar.hs:1:0: file name does not match module name `Main' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 28 07:53:28 2008 From: trac at galois.com (GHC) Date: Sun Sep 28 07:50:20 2008 Subject: [GHC] #2147: unhelpful error message for a misplaced DEPRECATED pragma In-Reply-To: <044.4706a1b0e36567a842f434c8ed45f7f6@localhost> References: <044.4706a1b0e36567a842f434c8ed45f7f6@localhost> Message-ID: <053.718cd1700599ad1fe90d6eedafdc9f8f@localhost> #2147: unhelpful error message for a misplaced DEPRECATED pragma ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): In the HEAD/6.10 we get: {{{ Foo/Bar.hs:1:0: File name does not match module name: Saw: `Main' Expected: `Foo.Bar' }}} The problem is that when we go to compile Foo.Bar we first want to get its imports, so that we know what else we have to compile first. When we hit the pragma, we think that the module body has started, and do not parse any more, so as far as GHC is concerned this is a module that has no header, and thus defaults to module Main. I'm not sure how we can do better. Perhaps returning the source location at which we decide what the module name is would help? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 28 09:08:53 2008 From: trac at galois.com (GHC) Date: Sun Sep 28 09:05:45 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources Message-ID: <044.b162acc88d57978452165d6180518f14@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources --------------------------------+------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Component: GHC API Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- In a typical ghc+packages installation, there are no Haskell sources. That makes life difficult for source-code-based tools, such as Haddock or HaRe (as far as I can see from `--show-iface` output, not even the import hierarchy is visible anymore?). (1) It would be useful if Ghc Api clients and Ghc users could easily find the matching source for installed packages, via a `src-dirs` field in the installed package description (if field is empty, no source has been installed). (2) It would be useful if matching sources could easily be added for installed packages. This would require editing the package description. Should there be an `edit` command for `ghc-pkg`? (3) An alternative to a `src-dirs` field would be to install sources in a separate source-package database, as long as it is easy to find the source from the binary package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 00:49:49 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 00:46:37 2008 Subject: [GHC] #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin In-Reply-To: <047.918ccc59a875951e79ffd2348c4375d6@localhost> References: <047.918ccc59a875951e79ffd2348c4375d6@localhost> Message-ID: <056.9fa071e78ef7fd1409d82ec9c0c5257c@localhost> #2423: Panic building GHC version 6.8.3 for powerpc-apple-darwin --------------------------+------------------------------------------------- Reporter: jimwhite | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Comment (by jimwhite): Unfortunately I'm only able to build using macports and I looked into trying a build that way for 6.10.1 and it is far too involved for the time I have available for Haskell (I got here just wanting to use darcs...). Interestingly I did retry a clean build for ghc 6.8.3 using macports and it works fine now (both PPC and Intel 32bit)! Since macports didn't change I have to assume that some Leopard update did the trick. The PPC build is now 10.5.4 (darwin 9.4.0) and the Intel build is 10.5.5 (darwin 9.5.0). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 03:28:04 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 03:24:57 2008 Subject: [GHC] #2432: type family panic: Coercion.splitCoercionKindOf In-Reply-To: <044.419fb1a60288d8516aab35dbc1443539@localhost> References: <044.419fb1a60288d8516aab35dbc1443539@localhost> Message-ID: <053.e44e5d327cd7eeaa40d33433bc54f88e@localhost> #2432: type family panic: Coercion.splitCoercionKindOf -------------------------------------+-------------------------------------- Reporter: claus | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: Works with the new solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 03:31:47 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 03:28:38 2008 Subject: [GHC] #2212: Double assignment to coercion variable In-Reply-To: <046.ad4e8af6cf182013c618bfd8fa17eb5c@localhost> References: <046.ad4e8af6cf182013c618bfd8fa17eb5c@localhost> Message-ID: <055.472a28438abf5a8b00afb2cc3d475535@localhost> #2212: Double assignment to coercion variable ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: equal | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: Fixed by the new solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 03:36:12 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 03:33:14 2008 Subject: [GHC] #2040: GADT regression In-Reply-To: <044.1338e8edb0c35965ed9c7ce0ba7c6cb7@localhost> References: <044.1338e8edb0c35965ed9c7ce0ba7c6cb7@localhost> Message-ID: <053.7ece533edfa9de4647dd5fdde9155e80@localhost> #2040: GADT regression -------------------------------------+-------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: gadt | Difficulty: Unknown Testcase: T2040 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by chak): * testcase: => T2040 * status: new => closed * resolution: => fixed Comment: Fine with new solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 03:40:09 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 03:37:02 2008 Subject: [GHC] #2151: GADTs in function Patterns In-Reply-To: <047.2f6478e8e827595da4825a54c1ec722c@localhost> References: <047.2f6478e8e827595da4825a54c1ec722c@localhost> Message-ID: <056.ddb1201a5e2fdedfef1b21b0165c5405@localhost> #2151: GADTs in function Patterns ----------------------+----------------------------------------------------- Reporter: hpacheco | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Comment (by chak): The new solver doesn't bomb out, but complains: {{{ /Users/chak/Code/haskell/Bug2.hs:13:21: Couldn't match expected type `b' against inferred type `a2' `b' is a rigid type variable bound by the constructor `Func' at /Users/chak/Code/haskell/Bug2.hs:13:10 `a2' is a rigid type variable bound by the constructor `Func' at /Users/chak/Code/haskell/Bug2.hs:13:10 In the pattern: ID In the definition of `test': test (PF (Func _ _)) ID = ID }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 03:43:02 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 03:39:54 2008 Subject: [GHC] #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families In-Reply-To: <043.4e7d20bb20215044f4485928ab1623de@localhost> References: <043.4e7d20bb20215044f4485928ab1623de@localhost> Message-ID: <052.7aec8e86ee541558f6679253112bde9e@localhost> #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families -------------------------------------+-------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: Fixed by the new solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 03:45:16 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 03:42:13 2008 Subject: [GHC] #2202: type error causes type checker stack overflow In-Reply-To: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> References: <045.817a1089ed0068d0921ec39de4c6cc2f@localhost> Message-ID: <054.93da69eda2c52eae520eb8c0f05848e7@localhost> #2202: type error causes type checker stack overflow -------------------------------------+-------------------------------------- Reporter: chiral | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Other Os: Other | -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: All fine with the new solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 03:48:40 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 03:45:32 2008 Subject: [GHC] #2219: GADT match fails to refine type variable In-Reply-To: <044.d581efc20e7649a6ed48131c2b7ba2cd@localhost> References: <044.d581efc20e7649a6ed48131c2b7ba2cd@localhost> Message-ID: <053.d7308de59a339eddedc2144baf977c72@localhost> #2219: GADT match fails to refine type variable -------------------------------------+-------------------------------------- Reporter: dolio | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: gadt type family | Difficulty: Unknown Testcase: T2219 | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by chak): * testcase: => T2219 * status: new => closed * resolution: => fixed Comment: Works with the new solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 04:24:08 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 04:20:58 2008 Subject: [GHC] #2631: Template Haskell weird error message Message-ID: <051.887408f1fe9f34c088e4f6e2dc848969@localhost> #2631: Template Haskell weird error message -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- I've noticed quite a few bugs related to weird TemplateHaskell expressions crashing the compiler recently, so I thought I'd try and write a nice exhaustive test of []'s in all possible places. In doing so however, I got some fairly weird error messages: {{{ C:\Neil\temp>cat Main.hs {-# LANGUAGE TemplateHaskell #-} module Main where import Language.Haskell.TH main _ = $( return $ CompE []) C:\Neil\temp>ghci Main.hs GHCi, version 6.9.20080916: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( Main.hs, interpreted ) Loading package syb ... linking ... done. Loading package array-0.1 ... linking ... done. Loading package packedstring-0.1 ... linking ... done. Loading package containers-0.1 ... linking ... done. Loading package pretty-1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Ok, modules loaded: Main. *Main> main () :1:0: Can't find interface-file declaration for variable main Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the expression: main () In the definition of `it': it = main () *Main> :q Leaving GHCi. C:\Neil\temp>ghc --make Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.1 ... linking ... done. Loading package packedstring-0.1 ... linking ... done. Loading package containers-0.1 ... linking ... done. Loading package pretty-1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Linking Main.exe ... Main.o:fake:(.text+0x4d): undefined reference to `Main_main_closure' Main.o:fake:(.data+0x4): undefined reference to `Main_main_closure' collect2: ld returned 1 exit status }}} The main binding seems to get dropped, but no warning is issued. Later on, when the main binding is needed, it can't be found. -- Neil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 08:27:45 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 08:24:33 2008 Subject: [GHC] #2632: Template Haskell confused by operator fixity Message-ID: <046.8dd0bbd9b32e6728a7a0c1c7930594d5@localhost> #2632: Template Haskell confused by operator fixity -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Reported by JCAB {{{ {-# LANGUAGE TemplateHaskell #-} module MkData where import Language.Haskell.TH import Language.Haskell.TH.Syntax op a b = a + b decl = [d| func = 0 `op` 3 |] }}} Works with 6.8.3, but with the 6.10 beta, it dies with the strange message {{{ C:\Users\JCAB\Haskell\THTest>ghc --make main.hs [1 of 2] Compiling MkData ( MkData.hs, MkData.o ) attempting to use module `main:MkData' (.\MkData.hs) which is not loaded }}} When looking up `op`, GHC doesn't find the fixity correctly. (SLPJ comment: having looked at the code in `RnEnv.lookupFixity` I can't see how 6.8.3 works!) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 08:28:01 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 08:24:48 2008 Subject: [GHC] #2632: Template Haskell confused by operator fixity In-Reply-To: <046.8dd0bbd9b32e6728a7a0c1c7930594d5@localhost> References: <046.8dd0bbd9b32e6728a7a0c1c7930594d5@localhost> Message-ID: <055.c6a8cb1db48f785b940bca6e75db9527@localhost> #2632: Template Haskell confused by operator fixity ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * version: 6.8.3 => 6.9 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 08:30:10 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 08:26:58 2008 Subject: [GHC] #2633: Template Haskell and windres Message-ID: <046.9b919ba8de4c365adabbc0dd415c4d16@localhost> #2633: Template Haskell and windres -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- JCAB reports: {{{ {-# LANGUAGE TemplateHaskell #-} module MkData where import Language.Haskell.TH import Language.Haskell.TH.Syntax decl name = returnQ $ [ DataD [] (mkName name) [] [RecC (mkName name) []] [] ] --- {-# LANGUAGE TemplateHaskell #-} module Main where import MkData $(decl "KK") main = undefined }}} gives the spooky error {{{ C:\Users\JCAB\Haskell\THTest>ghc --make main.hs [1 of 2] Compiling MkData ( MkData.hs, MkData.o ) [2 of 2] Compiling Main ( main.hs, main.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Linking main.exe ... C:\ghc\ghc-6.10.0.20080925\bin/windres: CreateProcess (null): Invalid argument }}} Works in 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 08:46:30 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 08:43:19 2008 Subject: [GHC] #2633: Template Haskell and windres In-Reply-To: <046.9b919ba8de4c365adabbc0dd415c4d16@localhost> References: <046.9b919ba8de4c365adabbc0dd415c4d16@localhost> Message-ID: <055.28aea86d060dd9b751fea07a0c630933@localhost> #2633: Template Haskell and windres ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by NeilMitchell): * status: new => closed * resolution: => duplicate Comment: It's not a Template Haskell bug, but it is known: http://hackage.haskell.org/trac/ghc/ticket/2585 If you compiled your GHC from source then your mingw is too new. My solution has to been to drop a GHC 6.8.3 windres into the binary install of HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 10:19:58 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 10:16:46 2008 Subject: [GHC] #2634: tcIfaceGlobal (local): not found: In-Reply-To: <045.23837f8401c21abc39abe04f4b7ec4b8@localhost> References: <045.23837f8401c21abc39abe04f4b7ec4b8@localhost> Message-ID: <054.6bf7c8c003a97a65286ddba1527cf0d4@localhost> #2634: tcIfaceGlobal (local): not found: -------------------------+-------------------------------------------------- Reporter: Meddix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Changes (by Meddix): * os: Unknown => Windows * architecture: Unknown => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 13:57:05 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 13:53:57 2008 Subject: [GHC] #2635: ghc panic Message-ID: <044.5ed00131488dc69dfc402e9550007157@localhost> #2635: ghc panic ------------------------+--------------------------------------------------- Reporter: jorzo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: powerpc | Os: MacOS X ------------------------+--------------------------------------------------- ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 for powerpc-apple-darwin): parser/Ctype.lhs:(91,13)-(347,35): Non-exhaustive patterns in case I've been getting intermittent hangs or crashes from GHC such as the error message above. When I restart the build, it successfully compiles. I did not observe this for ghc 6.8.2 on intel. I only observe it for ghc 6.8.3 for ppc which I am running under the Rosetta JIT compiler in order to cross compile to ppc binaries from an intel macintosh. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 21:30:21 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 21:27:07 2008 Subject: [GHC] #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) In-Reply-To: <044.a6b75e88dad86d305cedec64af5f04be@localhost> References: <044.a6b75e88dad86d305cedec64af5f04be@localhost> Message-ID: <053.fad8c86936a1b7a6fff2e06e5b291edb@localhost> #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) ----------------------+----------------------------------------------------- Reporter: shahn | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ----------------------+----------------------------------------------------- Changes (by PaulLiu): * architecture: x86_64 (amd64) => Multiple Comment: This bug affects 32-bit machines too if the callback function is made of type: `CChar -> IO ()`, and when C function calls it with -1, it would receive 255 instead. Functions like `rts_mkInt8, rts_mkInt16`, etc. in `RtsAPI.c` would cast values into `StgInt` after applying a mask. This mask would definitely change the sign of negative numbers. So I wonder why the actual callback into Haskell function would ignore such mask and treat it just like an ordinary `StgInt` casted back into `Int8, Int16`, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 21:42:33 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 21:39:21 2008 Subject: [GHC] #2635: ghc panic In-Reply-To: <044.5ed00131488dc69dfc402e9550007157@localhost> References: <044.5ed00131488dc69dfc402e9550007157@localhost> Message-ID: <053.76ea5d762043cd2681ca5dc1cdef1c10@localhost> #2635: ghc panic -------------------------+-------------------------------------------------- Reporter: jorzo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: powerpc | Os: MacOS X -------------------------+-------------------------------------------------- Comment (by jorzo): Also, ghc-6.8.3: internal error: resurrectThreads: thread blocked in a strange way (GHC version 6.8.3 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 22:04:41 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 22:01:32 2008 Subject: [GHC] #2627: GADT + Type family doesn't unify like I expect In-Reply-To: <044.4166c66675f16702cbe4b15c24b7a007@localhost> References: <044.4166c66675f16702cbe4b15c24b7a007@localhost> Message-ID: <053.0c0f0e94e056961886d92a62f3ed6c47@localhost> #2627: GADT + Type family doesn't unify like I expect -------------------------------------+-------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T2627 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by chak): * testcase: => T2627 Comment: Fixed the main issue (and added the code to the test suite). However, the `TcTyFuns.uMeta: unexpected synonym family` issue is still remaining. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 22:51:43 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 22:48:33 2008 Subject: [GHC] #1775: type families: poor error massages when lacking instances In-Reply-To: <044.ae7002ef9322e9aedd7e8a4d39f2fbee@localhost> References: <044.ae7002ef9322e9aedd7e8a4d39f2fbee@localhost> Message-ID: <053.d538499ff5b50e39542cf9cad01cd0dc@localhost> #1775: type families: poor error massages when lacking instances ----------------------+----------------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: With the new solver, we get the more conventional error message: {{{ /Users/chak/Code/haskell/Bug2.hs:13:8: Couldn't match expected type `Elem [a]' against inferred type `a' `a' is a rigid type variable bound by the instance declaration at /Users/chak/Code/haskell/Bug2.hs:12:21 In the expression: (:) In the definition of `cons': cons = (:) In the instance declaration for `Collection [a]' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 29 23:16:15 2008 From: trac at galois.com (GHC) Date: Mon Sep 29 23:13:05 2008 Subject: [GHC] #714: Inconsistency between handling functional dependencies in class and signature constraints In-Reply-To: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> References: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> Message-ID: <071.3c87cb6c49f6cc031612c3855448e066@localhost> #714: Inconsistency between handling functional dependencies in class and signature constraints -------------------------------------+-------------------------------------- Reporter: claus.reinke@talk21.com | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by chak): Concerning {{{ type family TF a -- class TF a ~ b => CTF a -- Not in scope: type variable `b' tf :: TF a ~ b => a tf = undefined }}} What is the problem with the following answer? {{{ *Main> :t tf tf :: a }}} The constraint `TF a ~ b` can always be satisfied by `b := TF a` and does not put any restriction on the application of `tf`. Hence, GHC reckons the types `a` and `TF a ~ b => a` are interchangeable. (If you want the verbatim signature given for `tf`, use `:i tf`.) The situation is different for type classes, as `FD a b` signifies that all methods of `FD` are available in `fd`. There is nothing corresponding for TFs. The same holds for the super class constraint `TF a ~ b`. It is meaningless; hence, I cannot see why we should support it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 01:34:11 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 01:31:01 2008 Subject: [GHC] #2627: GADT + Type family doesn't unify like I expect In-Reply-To: <044.4166c66675f16702cbe4b15c24b7a007@localhost> References: <044.4166c66675f16702cbe4b15c24b7a007@localhost> Message-ID: <053.b112691818424829608a0e1d225db7e6@localhost> #2627: GADT + Type family doesn't unify like I expect -------------------------------------+-------------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2627 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: Fixed the panic, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 04:02:48 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 03:59:36 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.382f204bfc1e2d82b0f1b8778c9e1931@localhost> #2081: GHC reports internal error: stg_ap_v_ret -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Changes (by simonmar): * milestone: 6.10 branch => 6.10.1 Comment: I want to get to the bottom of this (the `timeout` problem that Thorkil reports above) before the release. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 04:04:56 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 04:01:46 2008 Subject: [GHC] #714: Inconsistency between handling functional dependencies in class and signature constraints In-Reply-To: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> References: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> Message-ID: <071.702f6e9a986a258a9a8217fd51026713@localhost> #714: Inconsistency between handling functional dependencies in class and signature constraints -------------------------------------+-------------------------------------- Reporter: claus.reinke@talk21.com | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonpj): An instance declaration is a bit like a function type signature, but a class declaration is different. It ''looks'' a bit like a signature, but it is used the other way round. Consider {{{ class C a => D a where ... }}} This means that "we can get a dictionary for (C a) from a dictionary for (D a)". On the other hand {{{ instance C a => D [a] where ... }}} means "we can get a dictionary for (D [a]) from a dictionary for (C a)". Notice the reversal. So (reversing my previous comment above) I don't think it's inconsistent to have different rules for class and instance decls. So I think Manuel is right here. (And the user manual could be improved.) I don't think it's impossible to make sense of {{{ class C a b => D a }}} if (C a b) has a functional dependency. But if so, I'd prefer to write {{{ class C a (F b) => D a }}} Let's see if there are examples that give convincing evidence to the contrary. Perhaps these exist -- Claus describes the problem as acute. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From Christian.Maeder at dfki.de Tue Sep 30 04:07:41 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Tue Sep 30 04:04:27 2008 Subject: [GHC] #2012: compiling via-C does not work on ppc In-Reply-To: <054.069b972bedc30712099b1d55dfc4ea62@localhost> References: <045.6ad3ccd84b7b179a5baec1657fb43453@localhost> <054.069b972bedc30712099b1d55dfc4ea62@localhost> Message-ID: <48E1DE4D.8040308@dfki.de> > Changes (by igloo): > > * milestone: 6.10.1 => 6.12 branch > > Comment: > > I don't think we're likely to fix this before -fvia-C is removed in 6.12. > The workaround is just to use `-fasm`, of course. I wonder how porting to other platforms will be achieved in the future without going via C. Cheers Christian From trac at galois.com Tue Sep 30 05:09:20 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 05:06:11 2008 Subject: [GHC] #714: Inconsistency between handling functional dependencies in class and signature constraints In-Reply-To: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> References: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> Message-ID: <071.820e1f0ac389f1f899d6d81a889a3add@localhost> #714: Inconsistency between handling functional dependencies in class and signature constraints -------------------------------------+-------------------------------------- Reporter: claus.reinke@talk21.com | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by claus): Replying to [comment:10 chak]: >What is the problem with the following answer? {{{ *Main> :t tf tf :: a }}} > The constraint `TF a ~ b` can always be satisfied by `b := TF a` and does not put any restriction on the application of `tf`. There should be the restriction that there '''exists''' at least one type family instance (type function application is strict, not lazy, right?-) at the point of use. There isn't one at all here. > The same holds for the super class constraint `TF a ~ b`. It is meaningless; hence, I cannot see why we should support it. It brings a short name `b` into scope, bound to the result of the type function application. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 05:23:58 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 05:20:46 2008 Subject: [GHC] #714: Inconsistency between handling functional dependencies in class and signature constraints In-Reply-To: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> References: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> Message-ID: <071.f990a0835e598ca514053f2a033b8042@localhost> #714: Inconsistency between handling functional dependencies in class and signature constraints -------------------------------------+-------------------------------------- Reporter: claus.reinke@talk21.com | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by claus): Replying to [comment:11 simonpj]: > An instance declaration is a bit like a function type signature, but a class declaration is different. It ''looks'' a bit like a signature, but it is used the other way round. That is because superclass context constraints are required earlier than other context constraints: you cannot even write down a class constraint unless there are corresponding superclass instances, whereas you can write down instances and function types with unsatisfied contexts, you just can't use them if the context constraints can't be satisfied. So, by the time you have a handle on a class constraint that isn't outright invalid, you know you've already checked its superclass constraints, which is why you can use the implication backwards. > {{{ > class C a b => D a > }}} > if (C a b) has a functional dependency. But if so, I'd prefer to write > {{{ > class C a (F b) => D a > }}} The whole point was to bring `b` into scope as functionally dependent on `C a _`, thereby ''modelling'' a type function in the scope, using the (class) contexts for type-level "let"-bindings. Which is why the inconsistent handling of contexts in different locations hurts. > Let's see if there are examples that give convincing evidence to the contrary. Perhaps these exist -- Claus describes the problem as acute. If the patient was in acute trouble 3 years ago, it might not matter now. As far as I can recall, the discussion was on TF vs FD, and I was trying to demonstrate that FD, fully implemented, can do everything that TF can. As I have seen no indication that any other compiler is going to implement TF, it still seems important to me to have FD supported well. -- Ticket URL: GHC The Glasgow Haskell Compiler From igloo at earth.li Tue Sep 30 06:16:57 2008 From: igloo at earth.li (Ian Lynagh) Date: Tue Sep 30 06:13:42 2008 Subject: [GHC] #2012: compiling via-C does not work on ppc In-Reply-To: <48E1DE4D.8040308@dfki.de> References: <045.6ad3ccd84b7b179a5baec1657fb43453@localhost> <054.069b972bedc30712099b1d55dfc4ea62@localhost> <48E1DE4D.8040308@dfki.de> Message-ID: <20080930101657.GA575@matrix.chaos.earth.li> Hi Christian, On Tue, Sep 30, 2008 at 10:07:41AM +0200, Christian Maeder wrote: > > > > I don't think we're likely to fix this before -fvia-C is removed in 6.12. > > The workaround is just to use `-fasm`, of course. > > I wonder how porting to other platforms will be achieved in the future > without going via C. Porting uses the unregisterised via C route, not the -fvia-C evil mangler route. The unregisterised route will still be supported. Thanks Ian From trac at galois.com Tue Sep 30 07:35:58 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 07:32:47 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources In-Reply-To: <044.b162acc88d57978452165d6180518f14@localhost> References: <044.b162acc88d57978452165d6180518f14@localhost> Message-ID: <053.f9444abd3cd8ac7438031135c60509c9@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources -----------------------------+---------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Sources aren't enough for most uses - you also need the .cabal file, and you might also need other package bits. In short, you really need the whole Cabal sdist to make any sense of the sources. Perhaps the right thing is to include the URL from which you can download the package sources? cabal-install could automatically set the field, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 07:54:33 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 07:51:18 2008 Subject: [GHC] #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) In-Reply-To: <044.a6b75e88dad86d305cedec64af5f04be@localhost> References: <044.a6b75e88dad86d305cedec64af5f04be@localhost> Message-ID: <053.be1d61a5665ca5733c236774b34d3542@localhost> #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) ----------------------+----------------------------------------------------- Reporter: shahn | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: reopened => new * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 08:04:36 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 08:01:22 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources In-Reply-To: <044.b162acc88d57978452165d6180518f14@localhost> References: <044.b162acc88d57978452165d6180518f14@localhost> Message-ID: <053.96d53f6cfe5cacded6a416432b907e21@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources -----------------------------+---------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by claus): Replying to [comment:1 simonmar]: > Sources aren't enough for most uses - you also need the .cabal file, and you might also need other package bits. In short, you really need the whole Cabal sdist to make any sense of the sources. Oh, bother. You're right, of course. > Perhaps the right thing is to include the URL from which you can download the package sources? cabal-install could automatically set the field, for example. .cabal itself already has a `package-url` field. What I was hoping for was the actual locally available source corresponding to an installed package - the one that a source-based tool might need to find (without going online) if interface files are not enough. There is a slight conflict of interests here, between wanting a pure sdist from which other variations of the package could be recreated, and wanting a pre-configured sdist that exactly matches the installed package. Perhaps pointing to a locally installed sdist, and keeping the configuration in the sdist, might suffice. Btw, I've filed a corresponding [http://hackage.haskell.org/trac/hackage/ticket/364 cabal ticket], as well, since cabal and ghc-pkg probably need to coordinate on this one (one providing the field, the other filling it). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 08:12:44 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 08:09:30 2008 Subject: [GHC] #2635: ghc panic In-Reply-To: <044.5ed00131488dc69dfc402e9550007157@localhost> References: <044.5ed00131488dc69dfc402e9550007157@localhost> Message-ID: <053.56d942a2e70c33a51e0c2938347dfe30@localhost> #2635: ghc panic ----------------------+----------------------------------------------------- Reporter: jorzo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.10 branch Comment: It sounds very much like you're experiencing random corruption, such as you might get from bad hardware. Since you're running under an emulator, I'd immediately suspect either the emulator or your hardware. Can you eliminate either of these? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 10:26:15 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 10:23:00 2008 Subject: [GHC] #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) In-Reply-To: <044.a6b75e88dad86d305cedec64af5f04be@localhost> References: <044.a6b75e88dad86d305cedec64af5f04be@localhost> Message-ID: <053.fde0a59b3e8257b627d1928d805e4050@localhost> #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) ----------------------+----------------------------------------------------- Reporter: shahn | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Tue Sep 30 04:56:11 PDT 2008 Simon Marlow * fix #2594: we were erroneously applying masks, as the reporter suggested }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 11:25:40 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 11:22:30 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources In-Reply-To: <044.b162acc88d57978452165d6180518f14@localhost> References: <044.b162acc88d57978452165d6180518f14@localhost> Message-ID: <053.3ba175990d5d3491e5ef630a067ee0ab@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources -----------------------------+---------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * milestone: => _|_ Comment: It's hard to know exactly what to do in this area until we have a prospective client actively asking for something. So I'll drop this into the _|_ milestone until we have more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 15:59:29 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 15:56:16 2008 Subject: [GHC] #2630: installed packages should have a src-dirs field, for access to optionally installed sources In-Reply-To: <044.b162acc88d57978452165d6180518f14@localhost> References: <044.b162acc88d57978452165d6180518f14@localhost> Message-ID: <053.8083e42dc6c0828ae3e0b5c77d59acd6@localhost> #2630: installed packages should have a src-dirs field, for access to optionally installed sources ------------------------------+--------------------------------------------- Reporter: claus | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Comment (by claus): I was of course thinking of a future HaRe/Ghc, but if you dislike vague future references, here are two simple use cases: (a) just last week, I wanted to trace the import hierarchies of my 6.8.3 installation, for which I don't have sources (b) even haddock needs package sources long enough to create its `*.haddock` files, and if any of the dependencies was installed without being haddocked, I need to be able to remedy that In cases like (a), I'd like to be able to install the package sources once, and then for an import tracer to be able to look up the correct package sources whenever there are cross-package references in the code. In cases like (b), I'd like to be able to add `.haddock` files to installed packages without having to worry about getting the right sources, because the right sources were installed with the package. I'm not thinking of anything complex yet, for starters just: "the local sources for this package are in this directory: `

`" or "local sources for this package have not (yet) been installed" would help. Then the tools would have to deal with those sources, and with associating them with the binary packages, but at least the tools would be able to find the sources easily. For Ghc Api clients like Ghc, I'd hope that extracting the source dirs from the package database, adding them to the import path and asking for `-fforce-recomp` would be sufficient, or that `-fforce-recomp` would look up the sources itself, but that might be optimistic?-) I'm not sure whether it would be sufficient, but is there any reason not to have a `src-dirs` field in installed packages descriptions? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 19:20:04 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 19:16:51 2008 Subject: [GHC] #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. In-Reply-To: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> References: <043.63306a2cc0e922a8f292cc5cebf4f918@localhost> Message-ID: <052.27e21962598a127b1b54a403161ee18b@localhost> #2411: RaiseAsync and STM segfault with stop_at_atomically in some circumstances. ------------------------------+--------------------------------------------- Reporter: sclv | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 19:22:27 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 19:19:12 2008 Subject: [GHC] #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) In-Reply-To: <044.a6b75e88dad86d305cedec64af5f04be@localhost> References: <044.a6b75e88dad86d305cedec64af5f04be@localhost> Message-ID: <053.7e95d3150d2ace29ed453067b9b08f3f@localhost> #2594: Wrong size for Int in arguments to functions wrapped to FunPtr by FFI wrappers (on 64-bit machine) ----------------------+----------------------------------------------------- Reporter: shahn | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 30 21:12:14 2008 From: trac at galois.com (GHC) Date: Tue Sep 30 21:09:04 2008 Subject: [GHC] #714: Inconsistency between handling functional dependencies in class and signature constraints In-Reply-To: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> References: <062.a7978807e311bf94b9011dbbf8edf8af@localhost> Message-ID: <071.7f3265c8ae321a5b7593d111951ffdac@localhost> #714: Inconsistency between handling functional dependencies in class and signature constraints -------------------------------------+-------------------------------------- Reporter: claus.reinke@talk21.com | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown/Multiple Os: Unknown/Multiple | -------------------------------------+-------------------------------------- Comment (by chak): Replying to [comment:12 claus]: > Replying to [comment:10 chak]: > >What is the problem with the following answer? {{{ *Main> :t tf tf :: a }}} > > The constraint `TF a ~ b` can always be satisfied by `b := TF a` and does not put any restriction on the application of `tf`. > > There should be the restriction that there '''exists''' at least one type family instance (type function application is strict, not lazy, right?-) at the point of use. There isn't one at all here. Type families are neither strict nor lazy (or rather, I guess, you mean non-strict). In fact, given that the type language is supposed to be strongly normalising, the outcome of normalisation is independent of the evaluation order. There is absolutely no requirement that a family instance needs to be in scope in that example. Given the absence of instances for `TF`, `(TF a)` is simply a type that is only equal to itself and which is not inhabited, except for bottom. `(TF a)` is already fully normalised. So, I maintain, GHC is doing the right thing. > > The same holds for the super class constraint `TF a ~ b`. It is meaningless; hence, I cannot see why we should support it. > > It brings a short name `b` into scope, bound to the result of the type function application. But that name does not occur anywhere else. Hence, it will have no effect whatsoever on the typing of the rest of the program. Judging from your previous comment, I believe I know what you were trying to do. Given {{{ class TF a ~ b => CTF a }}} your intention was that whenever somebody declares an instance {{{ instance CTF t }}} the superclass rules would require that there is also an instance for `TF t`. Is that right? Unfortunately, this wouldn't work anyway, for the same reason that `:t tf` gives you `a`, not `TF a ~ b => a`. A superclass equality of the form `TF a ~ b`, where `b` doesn't occur anywhere else is trivial to satisfy: just instantiate `b` with `TF a`. (This again works even if there is no single instance for `TF`.) -- Ticket URL: GHC The Glasgow Haskell Compiler