- Glasgow-haskell-users

ghc-mtl and ghc-7.2.1
by José Romildo Malaquias 07 Sep '11

07 Sep '11

Hello. In order to compile ghc-mtl-1.0.1.0 (the latest released version) with ghc-7.2.1, I would apply the attached patch, which removes any references to WarnLogMonad. ghc-7.2.1 does not have the monad WarnLogMonad anymore. As I do not know the details of the GHC api, I am not sure if this is enough to use ghc-mtl with ghc-7.2.1. I want ghc-mtl in order do build lambdabot. Any thoughts? Romildo

2 1

Inliner non-termination
by Ron Alford 07 Sep '11

07 Sep '11

>From the known bugs (http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc) """GHC's inliner can be persuaded into non-termination using the standard way to encode recursion via a data type... We have never found another class of programs, other than this contrived one, that makes GHC diverge, and fixing the problem would impose an extra overhead on every compilation. So the bug remains un-fixed.""" There are now three more examples, at least two of which weren't 'contrived': http://hackage.haskell.org/trac/ghc/ticket/5448 http://hackage.haskell.org/trac/ghc/ticket/5400 http://hackage.haskell.org/trac/ghc/ticket/3872 It took me about 4-6 hours to track down this bug in my own code (#5448) since it required repeatedly bisecting a larger program until I had a small testcase. In the test program, I can get around it with {-# NOINLINE funcEq #-}. In the program it came from, though, FuncEq is an imported value, so I have to either compile with -O0, or change put the pragma in the imported library, where it will effect a fair amount of code that /doesn't/ hit this bug. If adding the check is too expensive, can the inliner have a configurable recursion bount (ala -fcontext-stack)? -Ron Alford

2 2

Re: Parallel --make (GHC build times on newer MacBook Pros?)
by Evan Laforge 05 Sep '11

05 Sep '11

> Ah, but you're measuring the startup time of ghc --make, which is not the same as the work that each individual ghc would do if ghc were invoked separately on each module, for two reasons: Excellent, sign me up for this plan then :) ghc on a single file is very quick.

1 0

GHC build times on newer MacBook Pros?
by Johan Tibell 05 Sep '11

05 Sep '11

Hi! I'm looking to upgrade my laptop so that I can (among other things) compile GHC faster. I'll either get the 13" 2.7GHz dual-core Intel Core i7 model or the 15" 2.2GHz quad-core Intel Core i7 model. Anyone know if it's worth to get the 15" model? According to these benchmarks it should be quite a bit faster: http://www.primatelabs.ca/geekbench/mac-benchmarks/ but I don't know if I can get enough parallelism out of GHC's build to use all 4 cores in the 15" model. -- Johan

11 23

Superclass defaults
by Simon Peyton-Jones 05 Sep '11

05 Sep '11

(Adding GHC users, and changing title.) | Conor McBride wrote: | > http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances | > I don't know if it's likely to be implemented in GHC anytime soon,.. | > So things are looking up. It should soon be technically feasible to | > separate the issues of whether the Monoid operator should be (<>) and | > whether it should actually live in a Semigroup superclass... | | Nice. But will it be happening soon, or not? And how soon is | soon? Not soon enough to be useful for this mappend question. But, concerning proposed extensions to GHC about class aliases/superclass defaults etc, the truth is that the biggest reason for inertia here at GHC HQ is not so much the implementation effort (athough that is always an issue). Rather, it's uncertainty about (a) Is there a reasonably large group of users who really want such a change? Or is it just "nice to have"? (b) What is the "right" design? (c) Does it pay its way? (ie do the programming benefits justify the cost in terms of both language complexity and ongoing maintenance burden of one more feature to bear in mind when changing anything) With help from Conor we have made some progress on this: we have a draft design: http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances If you care about the issue, maybe you can help resolve the above questions. In particular, to give concrete evidence for (b), working out some case studies would be a Good Thing. The examples given in other proposals using the extension proposed here would be one starting point. If someone felt able to act as moderator for the discussion, willing to summarise conclusions, open questions, and so on, on the wiki page, that would be enormously helpful. I am in too many inner loops. But I *am* willing to contemplate such an extension -- it has the same flavour as default methods themselves, which are a very useful part of H98. Simon

14 28

Panic when using syb with GHC API
by Simon Hengel 01 Sep '11

01 Sep '11

Hello, I'm trying to query a type-checked module with syb, this works for a plain binding. But as soon as I add a type signature for that binding, I get an "panic!" I experienced similar problems with a renamed module. Are those data structures meant to be used with syb? And if yes, what did I miss? Bellow is some code to reproduce my issue. Any help is very much appreciated. -- A.hs module Main where import GHC import Outputable import Data.Generics import GHC.Paths (libdir) import Bag main :: IO () main = do m <- parse putStrLn $ showSDoc $ ppr $ m putStrLn "\n---\n" putStrLn $ showSDoc $ ppr $ selectAbsBinds m parse = runGhc (Just libdir) $ do _ <- getSessionDynFlags >>= setSessionDynFlags target <- guessTarget "B.hs" Nothing setTargets [target] Succeeded <- load LoadAllTargets modSum <- getModSummary $ mkModuleName "B" m <- parseModule modSum >>= typecheckModule return $ typecheckedSource m selectAbsBinds :: GenericQ [HsBindLR Id Id] selectAbsBinds = everything (++) ([] `mkQ` f) where f x@(AbsBinds _ _ _ _ _) = [x] f _ = [] -- B.hs module B where foo :: Char foo = 'f' Cheers, Simon

6 8

How to synchronously shutdown the event manager loop
by Bas van Dijk 31 Aug '11

31 Aug '11

Hello, In my (still unreleased) usb-1.0 (https://github.com/basvandijk/usb) library I use the GHC event manager for managing events from the underlying `libusb` C library. To work with the library a user has to initialize it using: newCtx ∷ IO Ctx The `Ctx` then allows the user to see the USB devices attached to the system using: getDevices ∷ Ctx → IO [Device] >From thereon a user can open devices using: openDevice ∷ Device → IO DeviceHandle and perform IO with them: readBulk ∷ DeviceHandle → EndpointAddress → Size → Timeout → IO (B.ByteString, Status) Internally the synchronous `readBulk` is implemented using asynchronous IO: first a request to read bytes from a USB device is asynchronously submitted. Then it waits on a lock (`takeMVar lock`). When the bytes are read an event is fired on a certain file descriptor. The GHC event manager then wakes up and calls a callback which will release the lock (`putMVar lock ()`). I choose to have one event loop per session (`Ctx`) with the usb library. This means that I make a new `EventManager` in `newCtx`: evtMgr ← EventManager.new register the `libusb` file descriptors with the event manager and fork a thread which will `loop` the `EventManager`: tid <- forkIOWithUnmask $ \unmask → unmask $ EventManager.loop evtMgr The underlying `libusb` C library needs to be deinitialized when you're done with it. However for safety and ease of use a user of my Haskell library doesn't need to explicitly deinitialize the library. Instead this happens automatically when the garbage collector collects an unreferenced `Ctx` by registering (using `Foreign.Concurrent.newForeignPtr`) the following finalizer with the `Ctx` foreign pointer: -- Stop the event handling loop by killing its thread: killThread tid ... -- Finally deinitialize libusb: c'libusb_exit ctxPtr As you see I also kill the thread which is running the event manager loop. However I think this is not the right way to do it because when I use the library I see the following message being continually printed after the `Ctx` is finalized: ghc: ioManagerWakeup: write: Bad file descriptor Note that when I remove the `killThread tid` the messages disappear. It seems that killing the event manager loop is not allowed. Is there another way of shutting down the event manager loop? I know I can shut it down by using the `shutdown` function. However this function is asynchronous. This won't work because I need to make sure the event loop is shutdown before I exit the `libusb` library (because that will close the file descriptors that the event loop is working with). I see the event manager provides the `finished` function which will poll the manager to see if it stopped looping. This function is not exported however. Is it possible to export this function? It would be even nicer to have a synchronous shutdown function so that I don't need to setup a loop that waits till the manager has been shut down. Regards, Bas

2 4

ghc fails to build due to trust issues
by Bas van Dijk 30 Aug '11

30 Aug '11

Hello, I'm trying to build recent ghc-HEAD using ghc-7.2.1 but get the following error: libraries/filepath/System/FilePath/Internal.hs:81:1: base:Data.List can't be safely imported! The package (base) the module resides in isn't trusted. I guess a "-trust base" flag has to be passed to ghc somewhere. Regards, Bas

2 2

ghc-pkg unregister disobedience
by Albert Y. C. Lai 30 Aug '11

30 Aug '11

For package P, "ghc-pkg unregister --user P" drops the global package if P is not in user. "ghc-pkg unregister --global P" drops the user package if P is in user. "ghc-pkg unregister --package-conf=<dir> P" drops the user or the global package, preferring the user one, if P is not found in <dir>. Same with "ghc-pkg --user unregister P", "ghc-pkg unregister P --user", etc. GHC versions 6.10, 6.12, 7.0, 7.2.

1 1

Bug in GC's ordering of ForeignPtr finalization?
by Ben Gamari 29 Aug '11

29 Aug '11

On Tue, 16 Aug 2011 12:32:13 -0400, Ben Gamari <bgamari.foss(a)gmail.com> wrote: > It seems that the notmuch-haskell bindings (version 0.2.2 built against > notmuch from git master; passes notmuch-test) aren't dealing with memory > management properly. In particular, the attached test code[1] causes > talloc to abort. Unfortunately, while the issue is consistently > reproducible, it only occurs with some queries (see source[1]). I have > been unable to establish the exact criterion for failure. > > It seems that the crash is caused by an invalid access to a freed Query > object while freeing a Messages object (see Valgrind trace[3]). I've > taken a brief look at the bindings themselves but, being only minimally > familiar with the FFI, there's nothing obviously wrong (the finalizers > passed to newForeignPtr look sane). I was under the impression that > talloc was reference counted, so the Query object shouldn't have been > freed unless if there was still a Messages object holding a > reference. Any idea what might have gone wrong here? Thanks! > After looking into this issue in a bit more depth, I'm even more confused. In fact, I would not be surprised if I have stumbled into a bug in the GC. It seems that the notmuch-haskell bindings follow the example of the python bindings in that child objects keep references to their parents to prevent the garbage collector from releasing the parent, which would in turn cause talloc to free the child objects, resulting in odd behavior when the child objects were next accessed. For instance, the Query and Messages objects are defined as follows, type MessagesPtr = ForeignPtr S__notmuch_messages type MessagePtr = ForeignPtr S__notmuch_message newtype Query = Query (ForeignPtr S__notmuch_query) data MessagesRef = QueryMessages { qmpp :: Query, msp :: MessagesPtr } | ThreadMessages { tmpp :: Thread, msp :: MessagesPtr } | MessageMessages { mmspp :: Message, msp :: MessagesPtr } data Message = MessagesMessage { msmpp :: MessagesRef, mp :: MessagePtr } | Message { mp :: MessagePtr } type Messages = [Message] As seen in the Valgrind dump given in my previous message, it seems that the Query object is being freed before the Messages object. Since the Messages object is a child of the Query object, this fails. In my case, I'm calling queryMessages which begins by issuing a given notmuch Query, resulting in a MessagesPtr. This is then packaged into a QueryMessages object which is then passed off to unpackMessages. unpackMessages iterates over this collection, creating MessagesMessage objects which themselves refer to the QueryMessages object. Finally, these MessagesMessage objects are packed into a list, resulting in a Messages object. Thus we have the following chain of references, MessagesMessage | | msmpp \/ QueryMessages | | qmpp \/ Query As we can see, each MessagesMessage object in the Messages list resulting from queryMessages holds a reference to the Query object from which it originated. For this reason, I fail to see how it is possible that the RTS would attempt to free the Query before freeing the MessagesPtr. Did I miss something in my analysis? Are there tools for debugging issues such as this? Perhaps this is a bug in the GC? Any help at all would be greatly appreciated. Cheers, - Ben

3 4