- Glasgow-haskell-users

GHC 7.10.1 tickets
by Austin Seipp 21 Jul '14

21 Jul '14

Hello *, We need to be sorting out tickets for 7.10.1. Last week, I spent some time remilestoning things to get them into the rough correct places (roughly), but we all need some help to get an idea of what we should fix for the release. Here's a query to look at: https://ghc.haskell.org/trac/ghc/query?status=!closed&milestone=7.10.1&orde… I have already categorized these tickets roughly, but we'll probably still address some of the priorities on existing tickets of course. These are all of the 7.10.1 tickets currently, but there are some important things to note: 1) There are a lot of them! 2) Most of the development team is probably not going to pay attention to many of them unless they are high or highest priority in Trac. (That's just the result of having so many tickets for 7.10.1 at the moment.) So I'm asking if people out there with the time can help chip in and give some input on the ticket! - If there's a ticket that interests you, please comment on it! - Say why you think it should have its priority elevated for 7.10.1. - It will certainly be easier if you offer to help. Then we can move it upwards and we'll look at it. Finally, if you are *really* dedicated or a newcomer - please go through the tickets and see if any of them can be closed, reassigned, marked as duplicates, etc. There are certainly some dead tickets and probably easy tickets for newcomers, so just spend a few minutes looking if you're interested! (Otherwise they just end up getting punted off in batch modifications) Thanks! ~~~~~~~ BTW, for developers, you can look at your assigned tickets for 7.10.1 here, it's also always on the sidebar: https://ghc.haskell.org/trac/ghc/query?owner=%24USER&status=infoneeded&stat… -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Avoiding BlockedIndefinitelyOnSTM exceptions
by Gabriel Gonzalez 21 Jul '14

21 Jul '14

I have what may sound like an unusual request: I would like to automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a primitive that looks something like this: safe :: STM a -> STM (Maybe a) This hypothetical `safe` primitive would attempt a transaction, and if `ghc` detects that this transaction would fail because of an `BlockedIndefinitelyOnSTM` exception it will return `Nothing` instead of throwing an uncatchable exception. I originally simulated a limited form of this behavior using `pipes-concurrency`. I instrumented the garbage collector (using weak references) to detect when an STM variable was garbage collected and to safely cancel any transactions that depended on those variables. You can see the implementation here: https://github.com/Gabriel439/Haskell-Pipes-Concurrency-Library/blob/23e7e2… The original purpose behind this was to easily read and write to a channel without having to count references to the channel. I reasoned that the garbage collector *already knew* how many open references there were to channel, so I thought "why not use the garbage collector to gracefully cancel transactions that would block just before they would trigger the exception?" This worked really well up until ghc-7.8 changed something and the above trick no longer works. To be honest, I'm surprised that it ever worked at all, which is why I'm not requesting restoring the original behavior. Instead, I think providing something like the above `safe` primitive would be nicer, if possible. Would it be possible to implement something like `safe`? Alternatively, is it possible to make the `BlockedIndefinitelyOnSTM` exception catchable? P.S. I'm also interested in learning more about what may have caused the change in behavior in the transition from ghc-7.6 to ghc-7.8. What changes were made to the interaction between STM and weak references that may have triggered this?

4 7

Failure compiling ghc-mtl with ghc-7.8.{2,3}
by i hamsa 20 Jul '14

20 Jul '14

I was trying to upgrade to ghc-7.8 the other day, and got this compilation failure when building ghc-mtl-1.2.1.0 (see the end of the message). I'm using the haskell overlay on Gentoo Linux straight out of the box, no local cabal installations of anything. Now I was told that other people can compile ghc-mtl with 7.8 just fine, so there must be something broken in my specific configuration. What would be an effective way to approach the situation? In the sources I see that an instance of MonadIO GHC.Ghc does exist. I don't understand these errors. Are there multiple different MonadIO classes in different modules? Thank you and happy hacking. Now the errors: Control/Monad/Ghc.hs:42:15: No instance for (GHC.MonadIO Ghc) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (GHC.ExceptionMonad Ghc) Control/Monad/Ghc.hs:46:15: No instance for (MonadIO GHC.Ghc) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (MonadIO Ghc) Control/Monad/Ghc.hs:49:15: No instance for (GHC.MonadIO Ghc) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (GHC.GhcMonad Ghc) -- this is the real i

2 3

Avoiding BlockedIndefinitelyOnSTM exceptions
by Brandon Simmons 18 Jul '14

18 Jul '14

> I have what may sound like an unusual request: I would like to > automatically avoid `BlockedIndefinitelyOnSTM` exceptions with a > primitive that looks something like this: Have you seen ezyang's post here? Lots of hairy details that are probably relevant http://blog.ezyang.com/2011/07/blockedindefinitelyonmvar/ Brandon

1 0

extra "ambiguous type variable" errors after a "couldn't match" error?
by Evan Laforge 17 Jul '14

17 Jul '14

7.8.3 has a new behaviour where a "plain" type error will cause "ambiguous type variable" errors, e.g.: module M where broken :: [Int] broken = () ambiguous :: a -> [String] ambiguous _ = map show [1..] When imported in ghci, I get: M.hs:4:10: Couldn't match expected type ‘[Int]’ with actual type ‘()’ In the expression: () In an equation for ‘broken’: broken = () M.hs:7:19: No instance for (Show a0) arising from a use of ‘show’ The type variable ‘a0’ is ambiguous [ ... and then more for Enum and Num ] It seems like the 'a' type variable causes this to happen. But I don't see why a type error in another place should cause 'ambiguous' to become ambiguous.

2 2

Why no `instance (Monoid a, Applicative f)=> Monoid (f a)` for IO?
by Brandon Simmons 15 Jul '14

15 Jul '14

It seems to me that this should be true for all `f a` like: instance (Monoid a, Applicative f)=> Monoid (f a) where mappend = liftA2 mappend mempty = pure mempty But I can't seem to find the particular `instance (Monoid a)=> Monoid (IO a)` anywhere. Would that instance be incorrect, or does it live somewhere else? FWIW I noticed this when I started thinking about an instance I wanted for 'contravariant': instance (Monoid a, Applicative f)=> Monoid (Op (f a) b) where mempty = Op $ const $ pure mempty mappend (Op f) (Op g) = Op (\b-> liftA2 mappend (f b) (g b)) at which point I realized (I think) all `f a` are monoidal, and so we ought to be able to get the instance above with just a deriving Monoid. Brandon

2 2

Fwd: how to get ghci to load compiled modules in 7.8?
by Evan Laforge 14 Jul '14

14 Jul '14

I sent this to haskell-cafe, but there was no response. On stackoverflow there was no response either. I'm trying one last time, but adding ghc-users (which I should have done at the beginning!). Surely it can't be that no one knows how to load modules in ghci? I know a lot of work was done to enable this, as in https://ghc.haskell.org/trac/ghc/wiki/DynamicByDefault, it seems a waste if no one actually knows how to use it! The 7.8.1 release notes make reference to -dynamic-too, and an unexplained "Dynamic Ghci", but implies ghci should just work. Do I need to compile ghci myself in a dynamic way? The DynamicByDefault page also implies that, but I assumed the binary distributions would come with it compiled the right way. This has almost disabled ghci for my work (it can be used, but very slowly and with much retyping of commands, and I find myself avoiding the REPL now), so it's a big regression from 7.6! I added another paragraph from the stackoverflow question. Also, I can't get this to work on linux either, not just OS X. BTW, I got a nice bump in my profiles after upgrading, so 7.8 is mostly good news. Just this one awkward thing keeps it from being all good news. ---------- Forwarded message ---------- I recently upgraded to 7.8.2 and I have a silly question. How do you get ghci to load compiled modules? When I try this: % cat >T.hs module T where x :: Int x = 42 % ghc -c -dynamic-too T.hs % s T.dyn_hi T.dyn_o T.hi T.hs T.o % ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Prelude> :l T [1 of 1] Compiling T ( T.hs, interpreted ) Ok, modules loaded: T. *T> It still loads the file interpreted, even though there is a .dyn_o present. What am I doing wrong? This is on x86-64 OS X. There is one other thing which may be related. Since I load everything interpreted now, I've noticed that the input gets very laggy when I have a hundred or so modules loaded. Also the haskeline state gets confused, e.g. I hit escape k to get the previous line, but then it spontaneously goes back into insert mode again. It stays balky and awkward for about 15 seconds before returning to normal slightly. It's almost as if, after loading all the bytecode, it's still doing tons of work in the background, with constant GC freezes. But what work could it be doing? The bytecode is loaded and I haven't asked it to do anything yet! I don't know if this is new to 7.8, or if it's a result of loading bytecode instead of binary. Update: loading with -fobject-code to force compilation reduces some of the balkiness, but some is still there! So maybe this is a regression from 7.6?

2 5

Re: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
by Christiaan Baaij 14 Jul '14

14 Jul '14

Thanks, the work-around did the trick. On 14 July 2014 16:34, Mark Lentczner <mark.lentczner(a)gmail.com> wrote: > Yes - this is a known problem in GHC (#9257 > <https://ghc.haskell.org/trac/ghc/ticket/9257>) > The problem is that there is one gcc invocation in the "make install" step > (!) and that the clang/gcc detection isn't applied at bindist configuire > time. Hence, that gcc invocation is based on the compiler of the machine > that built the bindist (clang), not the compiler of the machine it is being > installed on (gcc). > > Note that this doesn't affect the installed GHC system: The compiler > detection at bindist configure time *is* applied to the ghc tree it > installs, just not the bindist make itself! > > Work around is very easy: > > make install CC_CLANG_BACKEND=0 > > > - Mark > >

1 0

Fwd: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
by Brandon Allbery 14 Jul '14

14 Jul '14

FWIW Mark had this reply but is apparently not subscribed to, or being rejected by, ghc-users and asked me to forward it. ---------- Forwarded message ---------- From: Mark Lentczner <mark.lentczner(a)gmail.com> Date: Mon, Jul 14, 2014 at 7:34 AM Subject: Re: Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine To: Christiaan Baaij <christiaan.baaij(a)gmail.com> Cc: glasgow-haskell-users <glasgow-haskell-users(a)haskell.org> Yes - this is a known problem in GHC (#9257 <https://ghc.haskell.org/trac/ghc/ticket/9257>) The problem is that there is one gcc invocation in the "make install" step (!) and that the clang/gcc detection isn't applied at bindist configuire time. Hence, that gcc invocation is based on the compiler of the machine that built the bindist (clang), not the compiler of the machine it is being installed on (gcc). Note that this doesn't affect the installed GHC system: The compiler detection at bindist configure time *is* applied to the ghc tree it installs, just not the bindist make itself! Work around is very easy: make install CC_CLANG_BACKEND=0 - Mark -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Installing ghc-7.8.3 OS X bindist fails on Xcode 4 CLI-only machine
by Christiaan Baaij 14 Jul '14

14 Jul '14

Hi, I'm having problems installing the OS X bindist of GHC 7.8.3 on my machine. Here are the specs for my machine: Hardware: MacBook Pro, 13-inch, Mid 2009 Operating System: OS X 10.8.5 gcc: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Note that I only have the Xcode 4 CLI tools installed, not Xcode 4 itself. The line that fails is: > /usr/bin/gcc -E -m64 -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs -P -DINSTALLING -DLIB_DIR='"/opt/ghc/7.8.3/lib/ghc-7.8.3"' -DINCLUDE_DIR='"/opt/ghc/7.8.3/lib/ghc-7.8.3/include"' -DPAPI_INCLUDE_DIR="" -DPAPI_LIB_DIR="" -DFFI_INCLUDE_DIR= -DFFI_LIB_DIR= '-DFFI_LIB="Cffi"' -x c -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header rts/package.conf.in -o rts/dist/package.conf.install.raw > cc1: error: unrecognized command line option "-Wno-invalid-pp-token" > cc1: error: unrecognized command line option "-Wno-unicode" > make[2]: *** [rts/dist/package.conf.install] Error 1 > make[1]: *** [install] Error 2 > make: *** [install] Error 2 Earlier in the configuration process I see: > checking XCode version... xcode-select: Error: No Xcode is selected. Use xcode-select -switch <path-to-xcode>, or see the xcode-select manpage (man xcode-select) for further information. > not found (too old?) Could that be the culprit? The entire installation log can be found here: https://gist.github.com/christiaanb/ec06e93fa16fdfdb5fa3 -- Christiaan

2 1