- Glasgow-haskell-users

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

ANNOUNCE: GHC version 7.8.3
by Austin Seipp 11 Jul '14

11 Jul '14

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.8.3 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.3. This is an important bugfix release relative to 7.8.2 (with over 50 defects fixed), so we highly recommend upgrading from the previous 7.8 releases. The full release notes are here: https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/release-7-8-3.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Platforms http://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ Included in this email is a signed copy of the SHA256 hashes for the tarballs, using my GPG key (keyid 0x3B58D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0