March 2013 - ghc-tickets

[GHC] #7650: can't use combining characters in identifiers
by GHC 23 Apr '13

23 Apr '13

#7650: can't use combining characters in identifiers -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86 Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- ghc doesn't let me use combining characters in unicode identifiers. Here's a test case with U+308 (COMBINING DIAERESIS) but it affects all accents: {{{ % cat comb.hs main = print spın̈alTap where spın̈alTap = 11 }}} {{{ % ghc comb.hs [1 of 1] Compiling Main ( comb.hs, comb.o ) comb.hs:1:18: lexical error at character '\776' }}} (This is actually with ghc 7.6.2 but the `Version` drop-down only goes up to 7.6.1.) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7662: Improve GC of mutable objects
by GHC 23 Apr '13

23 Apr '13

#7662: Improve GC of mutable objects -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Haskell is a purely functional language at its core, but it can be also used for workloads involving mutation; it is for these workloads that our GC can be pretty poorly tuned (historically, we’ve fixed these issues case-by-case when they were causing problems for users, e.g. #650). Fortunately, the question of generational garbage collection in the face of lots of mutability is a well-studied one (c.f. the JVM) so this bug asks whether or not we can systematically appropriate any of the machinery developed here for GHC. Some ideas include: * Utilizing card marking at the page level for write barriers, instead of our current mutable lists, * Separating mutable and immutable (and lazy) data on the heaps, to make the previous scheme more likely to work well, * Organizing our generations in different pages, so that checking the generation of any object is as simple as a pointer comparison, * Figure out if we can do better than permanently keeping all mutable arrays permanently on the mutable list (which is really killer when you have lots of tiny mutable arrays), * More mutable closure types to remove the indirection that would normally result from an IORef (actually, you can UNPACK these, and I’m not 100% what happens in that case; it depends on how MutVar#s are represented) There’s probably more things but this is just a start to get things rolling. Test cases and benchmarks also appreciated! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7606: Stride scheduling for Haskell threads with priorities
by GHC 23 Apr '13

23 Apr '13

#7606: Stride scheduling for Haskell threads with priorities -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Currently, GHC uses a round-robin scheduler for Haskell threads, with some heuristics for when threads should be bumped to the front of the queue. This patch set replaces this scheduler with 'stride scheduling', as described by Waldspurger and Weihl '95, which is an efficient, deterministic method for scheduling processes with differing priorities. Priorities are assigned by giving 'tickets' to threads; a thread with twice as many tickets as another will run twice as often. I’d like to replace the round-robin scheduler completely with this scheduler. Here are nofib benchmarks comparing the old scheduler to the new: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.0% -52.2% -18.8% -18.6% -83.1% Max +1.0% +4.2% +4.9% +5.1% +7.7% Geometric Mean +0.1% -2.8% -0.9% -0.9% -2.9% }}} Here are some technical details: * Without any changes to ticket values, scheduling behavior should be functionally identical to round-robin. (By default, new threads, including the IO thread, get allocated the max nubmer of tickets possible.) This is not quite identical, since our heap does not have FIFO property (see below.) * The current patch-set uses a very simple (e.g. undergrad level) resizable-array backed heap to implement the priority queue; we can play some tricks to reduce the memory footprint of the priority queue (e.g. using the container_of macro to eliminate the extra keys store); and a more fancy data structure would make it easier for us to surgically remove entries or reweight them, but I wanted to keep overhead low. If anyone has a pet implementation of priority queues in C feel free to swap it in. Right now, this only affects the uses of promoteInRunQueue() in Messages.c; I still need to check if #3838 has regressed. * We get three new primops: `setTickets#`, `getTickets#` and `modifyTickets#`. We don't support creating threads with specific numbers of tickets (mostly because that would have added an annoyingly large set of extra primops); instead, you're expected to spawn a thread which gets max-ticket allocation, and then weight it down. * `_link` is no longer used for linking TSOs in the run queue. I have tried my best to stamp out any code which operated on this assumption, but I may have missed some. * Modifying a TSO's tickets takes out the scheduler lock; the hope is that this operation is quick and rare enough that a global lock here is not too bad. * We are unfortunately stuck with some magic constants w.r.t. ticket values: 1 << 20 is the maximum number of tickets our implementation is hard-coded to support. * Sleeping and blocked tasks do not get any 'bonus' for being blocked. * In an ideal world, when a thread hits a black hole, it should temporarily give its tickets to the thread evaluating the black hole, so it will unblock more quickly. Unfortunately, implementing this is pretty complicated (the blackhole evaluating thread could die; or it could get stuck on a blackhole itself and need to gift its tickets; it shouldn't be able to give away the tickets it was gifted.) So this implementation leaves that out. Similar semantics for MVars are probably possible, but will require userland assistance too. I haven't prepared a patch to base yet with a user-level API, but here is a proposed draft: {{{ type Tickets = Int -- | Maximum number of tickets we support a thread having. (Currently 2 >> 20) -- Note that this doesn't bound the *global* maximum tickets. maxTickets :: Tickets -- | Changes the number of tickets allocated to a thread. The ticket count must -- not be less than or equal to zero, or greater than maxTickets. (Corresponds -- to setTickets# primop) setTickets :: ThreadId -> Tickets -> IO () -- | Returns the number of tickets currently allocated to a thread. (Corresponds to -- getTickets# primop) getTickets :: ThreadId -> IO Tickets -- | Atomically performs a linear transformation on the number of tickets a thread; -- e.g. scaling the number of tickets by a rational number, adding another fixed -- set of tickets, and then returning the number of 'leftover' tickets from the operation; e.g. -- if the net amount of tickets is reduced, then the returned result is positive; -- if the net amount of tickets is increased, the returned result is negative. -- In the absence of concurrent threads, the following property holds forall -- t, m and x: -- -- do r <- getTickets t -- d <- scaleTickets t m x -- r' <- getTickets t -- return (r == r' + d) -- -- If the scaling would reduce the number of tickets below zero or increase the -- number of tickets beyond maxTickets, this function will instead fail with -- an exception. This function will be subject to some rounding error; powers of two -- are, however, likely to be exact. (Corresponds to modifyTickets# primop; note -- that the sentinel value for failure is maxTickets + 1, since it is impossible for -- a thread's ticket value to change by that much.) modifyTickets :: ThreadId -> Ratio Int -> Tickets -> IO Tickets -- | Forks a new thread, transferring some percentage of tickets from the current -- thread to it (so the net number of tickets stays constant.) Fails if the rational -- is greater than 1 or less than or equal to zero, or if there are not enough tickets -- in the current thread. forkIOWith :: IO a -> Ratio Int -> IO ThreadId }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #7786: strange errors when deducing constraints
by GHC 22 Apr '13

22 Apr '13

#7786: strange errors when deducing constraints -----------------------------+---------------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Please load attached file in ghci and observe the resulting error message. I have added my commentaries inline to what appears fishy to me. All may technically be ok, but look quite confusing. {{{ [1 of 1] Compiling Main ( pr7786.hs, interpreted ) pr7786.hs:74:22: Couldn't match type `Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv' with 'Empty [KeySegment] Inaccessible code in a pattern with constructor Nil :: forall (k :: BOX). Sing (Inventory k) ('Empty k), in a pattern binding in 'do' block }}} Yes, ok, (Nil :: Sing Empty) does not unify with (forall xxx. Nil :: Sing xxx). {{{ Relevant bindings include addSub :: Database inv -> Sing [KeySegment] k -> Database sub -> Maybe (Database (BuriedUnder sub k inv)) (bound at pr7786.hs:74:1) db :: Database inv (bound at pr7786.hs:74:8) k :: Sing [KeySegment] k (bound at pr7786.hs:74:11) sub :: Database sub (bound at pr7786.hs:74:13) In the pattern: Nil In the pattern: Nil :: Sing xxx In a stmt of a 'do' block: Nil :: Sing xxx <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db) pr7786.hs:78:31: Could not deduce (Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv ~ 'Empty [KeySegment]) from the context (Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv ~ 'Empty [KeySegment]) }}} This one is highly disturbing. I think the user should never see such a message. Scary. ''This is the reason for the ticket''. {{{ bound by a pattern with constructor Nil :: forall (k :: BOX). Sing (Inventory k) ('Empty k), in a pattern binding in 'do' block at pr7786.hs:74:22-24 Relevant bindings include addSub :: Database inv -> Sing [KeySegment] k -> Database sub -> Maybe (Database (BuriedUnder sub k inv)) (bound at pr7786.hs:74:1) db :: Database inv (bound at pr7786.hs:74:8) k :: Sing [KeySegment] k (bound at pr7786.hs:74:11) sub :: Database sub (bound at pr7786.hs:74:13) In the second argument of `($)', namely `Sub db k sub' In a stmt of a 'do' block: return $ Sub db k sub In the expression: do { Nil :: Sing xxx <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db); return $ Sub db k sub } Failed, modules loaded: none. }}} '''Now comment line 74 and uncomment l. 75 and reload:''' {{{ pr7786.hs:75:22: Couldn't match type `Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv' with `Intersect [KeySegment] (BuriedUnder sub1 k1 ('Empty [KeySegment])) inv1' }}} Hmm, I vaguely understand why those new degrees of freedom arise. {{{ NB: `Intersect' is a type function, and may not be injective }}} Probably irrelevant, no need to backwards guess here, as we have -XScopedTypeVariables turned on. {{{ The type variables `sub', `k', `inv' are ambiguous Expected type: Sing (Inventory [KeySegment]) (Intersect [KeySegment] (BuriedUnder sub1 k1 ('Empty [KeySegment])) inv1) Actual type: Sing (Inventory [KeySegment]) (Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv) Relevant bindings include addSub :: Database inv1 -> Sing [KeySegment] k1 -> Database sub1 -> Maybe (Database (BuriedUnder sub1 k1 inv1)) (bound at pr7786.hs:74:1) db :: Database inv1 (bound at pr7786.hs:74:8) k :: Sing [KeySegment] k1 (bound at pr7786.hs:74:11) sub :: Database sub1 (bound at pr7786.hs:74:13) In the pattern: Nil :: Sing ((sub `BuriedUnder` k) Empty `Intersect` inv) In a stmt of a 'do' block: Nil :: Sing ((sub `BuriedUnder` k) Empty `Intersect` inv) <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db) In the expression: do { Nil :: Sing ((sub `BuriedUnder` k) Empty `Intersect` inv) <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db); return $ Sub db k sub } Failed, modules loaded: none. }}} '''Now comment line 75 and uncomment l. 76 and reload:''' {{{ [1 of 1] Compiling Main ( pr7786.hs, interpreted ) pr7786.hs:76:51: Couldn't match type `Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv' with 'Empty [KeySegment] Expected type: Sing (Inventory [KeySegment]) ('Empty [KeySegment]) Actual type: Sing (Inventory [KeySegment]) (Intersect [KeySegment] (BuriedUnder sub k ('Empty [KeySegment])) inv) }}} Err... But (Nil :: Sing Empty) is ''exactly'' the annotation on the Nil constructor in the GADT definition! {{{ Relevant bindings include addSub :: Database inv -> Sing [KeySegment] k -> Database sub -> Maybe (Database (BuriedUnder sub k inv)) (bound at pr7786.hs:74:1) db :: Database inv (bound at pr7786.hs:74:8) k :: Sing [KeySegment] k (bound at pr7786.hs:74:11) sub :: Database sub (bound at pr7786.hs:74:13) In the first argument of `return', namely `(buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db)' In a stmt of a 'do' block: Nil :: Sing Empty <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db) In the expression: do { Nil :: Sing Empty <- return (buryUnder (dbKeys sub) k Nil `intersectPaths` dbKeys db); return $ Sub db k sub } Failed, modules loaded: none. }}} '''Now comment line 76 and uncomment l. 77 and reload:''' All is dandy! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7786> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7626: Add common utility variants of trace to Debug.Trace
by GHC 21 Apr '13

21 Apr '13

#7626: Add common utility variants of trace to Debug.Trace -----------------------------+---------------------------------------------- Reporter: chrisseaton | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/base Version: 7.6.1 | Keywords: trace Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- As discussed on the libraries list. http://www.haskell.org/pipermail/libraries/2013-January/019319.html 'traceId' traces a value, and then returns that same value. This avoids the common case of 'trace a a'. {{{ traceId :: String -> String traceId a = trace a a }}} 'traceM' runs 'trace' and returns unit in an arbitrary monad. This is useful for writing traces in do-notation, as each can sit on their own line. {{{ traceM :: (Monad m) => String -> m () traceM string = trace string $ return () }}} For example: {{{ ... = do x <- ... traceM $ "x: " ++ show x y <- ... ... }}} That application of 'traceM' there can be temporarily commented out with a simple line comment. Finally, equivalents of 'traceShow' for those two functions. {{{ traceShowId :: (Show a) => a -> a traceShowId a = trace (show a) a }}} {{{ traceShowM :: (Show a, Monad m) => a -> m () traceShowM = traceM . show }}} Advantages: I use these functions in my code all the time. When I discussed it on the libraries list there were several enthusiastic +1s of people doing the same. Disadvantages: The documentation in the patch makes it clear that traceM does not actually add a trace action to the monad you're using, which is a potential point of confusion (http://www.haskell.org/pipermail/libraries/2013-January/019322.html) I had originally suggested that 'traceIO == traceM', but it turns out this is not so. Henning Thielemann suggested that 'traceM' was better achieved with directly using 'trace' and 'printf' (http://www.haskell.org/pipermail/libraries/2013-January/019320.html) Of course, any function can be replaced with its RHS, and whether or not the user uses 'show' or 'printf' or whatever is orthogonal. I haven't written any tests, as it's all output generating code, so I'm really not sure how that's tested in GHC - sorry. Status of patch: Applies against base 3b51b741f45d4d85e79b2128d00479ce230f72f2 and compiles with GHC 388e1e825f79f2d16536fc583a48e5ce9c191b06. I've run a full GHC compile cycle with it without problem. Includes documentation. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7626> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7740: Remove direct cabal imports in Linker and Finder modules
by GHC 21 Apr '13

21 Apr '13

#7740: Remove direct cabal imports in Linker and Finder modules -----------------------------+---------------------------------------------- Reporter: rodlogic | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This is a low priority change, that mostly marks my first contribution :-) See pull request and additional details here: https://github.com/ghc/ghc/pull/6 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7761: iOS patch no 16: pass the correct -Dxxx_HOST_ARCH and -Dxxx_HOST_OS to hsc2hs by stage
by GHC 21 Apr '13

21 Apr '13

#7761: iOS patch no 16: pass the correct -Dxxx_HOST_ARCH and -Dxxx_HOST_OS to hsc2hs by stage ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: 7724 | Related: ------------------------------+--------------------------------------------- Currently hsc2hs always gets the build host's values, even when cross compiling. This patch makes it pass the correct values for the stage. There is no actual build failure that results from this being wrong, but it is only a matter of time before something breaks. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7759: iOS patch no 14: libraries/base changes
by GHC 21 Apr '13

21 Apr '13

#7759: iOS patch no 14: libraries/base changes --------------------------------+------------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.2 | Keywords: Os: Other | Architecture: arm Failure: Building GHC failed | Blockedby: Blocking: 7724 | Related: --------------------------------+------------------------------------------- In this patch there are two changes to apply to libraries/base. 'GHC/Event/KQueue.hsc': The issue here is that the #defines EVFILT_READ and EVFILT_WRITE have the values -1 and -2. The original code translates that to {{{filterRead = Filter -1}}} which is wrong Haskell and fails to compile. The modified code produces the correct code {{{filterRead = Filter (-1)}}} 'cbits/DarwinUtils.c': This code is needed for iOS as well as Darwin, and on iOS we need to explicitly include <mach/mach_time.h> which is the correct file for Mac OS/X too. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7719: System.Timeout.timeout may leak <<timeout>> exceptions
by GHC 21 Apr '13

21 Apr '13

#7719: System.Timeout.timeout may leak <<timeout>> exceptions -------------------------+-------------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.7 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: Blocking: | Related: -------------------------+-------------------------------------------------- The current implementation of {{{timeout}}} can leak {{{Timeout}}} exceptions if an asynchronous exception is delivered at the wrong time. The most worrysome such case is another {{{Timeout}}} exception raised by surrounding call to {{{timeout}}}. The following program reproduces the issue reliably for me: {{{ import System.Timeout import Control.Monad import Control.Concurrent t d = timeout d $ timeout d $ timeout d $ timeout d $ timeout d $ timeout (10^9) $ threadDelay 100 main = forever $ mapM_ t [1..200] -- > ghc -O2 -rtsopts -threaded --make TT.hs -- > ./TT +RTS -N1 -- TT: <<timeout>> }}} Context: A recent thread on {{{ghc-users}}}, starting with http://www.haskell.org/pipermail/glasgow-haskell- users/2013-February/023811.html, got me thinking about corner cases of timeout handling again. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #7760: iOS patch no 15: remove HSC2HS_EXTRA from hsc2hs's stage0 wrapper
by GHC 21 Apr '13

21 Apr '13

#7760: iOS patch no 15: remove HSC2HS_EXTRA from hsc2hs's stage0 wrapper --------------------------------+------------------------------------------- Reporter: StephenBlackheath | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.7 | Keywords: Os: Other | Architecture: Unknown/Multiple Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- hsc2hs gets built in stage0 and stage1. The stage0 binary is used during the build, and the stage1 binary is the one that get released. The hsc2hs that gets built in stage0 is used during the build in both in stage0 and in stage1. Currently some options specific to the platform are encoded into the hsc2hs wrapper script (inplace/bin/hsc2hs) in a variable called HSC2HS_EXTRA. The problem with this is that in stage0 and stage1 we need different options. The solution is very simple: Just don't put these options into the stage0 wrapper. The build system passes the right options for whatever stage it's up to anyway when it invokes it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3