Re: GHC status report

It turns out that the 7.8 update fixed problems that were NOT fixed by using -fno-ghci-sandbox with earlier versions of ghci, like 7.6.3, so this flag by itself did not address the issue. I assumed (perhaps incorrectly) that a full explanation must include the new dynamic linking support. With 7.6

Re: GHC status report

On Thu, May 1, 2014 at 5:30 PM, Simon Marlow wrote: > We should fix this (or at least make it a lot less likely). Is there a > ticket? > Not yet. I just converted to 7.8.2 the other day (I'd been running the release candidate) and wanted to duplicate the problem first. I haven't been writing co

Re: GHC status report

With the old custom linker we weren't able to get our custom MPFR linked in properly on all platforms for use in ghci. On Macs we ran into some rather interesting problems. We could get it to work for actual executables, but ghci would segfault with stuff resolved to clearly wrong addresses. If I

Re: GHC status report

another example of a library that becomes usable in ghci with 7.8 is llvm-general. Namely, with ghc 7.8, when llvm-general is built so it dynamically links to the system's LLVM library, I can run / invoke LLVM operations in GHCi. I believe that this is due to the same reason many other libraries

Re: GHC status report

On 01/05/14 15:27, Edward Kmett wrote: Figured I'd make one case for dynamic linking: https://github.com/ekmett/rounded Dynamic linking is finally enabling us to build a version of MPFR bindings for Haskell for scientific/high precision computing with 7.8. I would really hate to lose it after a

Re: GHC status report

On 01/05/14 14:48, Dominick Samperi wrote: The problem with some graphics libraries used via FFI (and other libraries that are not thread-safe), if I understand the situation correctly, is that ghci forks a thread when it shouldn't, causing some programs to miscalculate the available stack space

RE: Unexpected failure to inline, even with pragma

Dear Joachim, et al., Yes, you were right, this does fix it. This confuses me even more as to why it *did* inline Foo.Bar.foo in Foo.Bar.bar without -O, though. Is -O required for optimization across module bounds? Also, since I really want a certain level of inlining for a plugin I'm working

Re: GHC status report

Figured I'd make one case for dynamic linking: https://github.com/ekmett/rounded Dynamic linking is finally enabling us to build a version of MPFR bindings for Haskell for scientific/high precision computing with 7.8. I would really hate to lose it after all of these years trying to get it work,

Re: validate on Mavericks

I've posted this problem as #9047 (https://ghc.haskell.org/trac/ghc/ticket/9047), but I have no information to help you -- sorry! Richard On May 1, 2014, at 3:32 AM, Kazu Yamamoto (山本和彦) wrote: > Hi, > > Many tests for validate on master fail on Mavericks. This is because clang > produces so

Re: Unexpected failure to inline, even with pragma

Hi, Am Donnerstag, den 01.05.2014, 12:59 + schrieb p.k.f.holzensp...@utwente.nl: > $ ghc -ddump-inlinings -fforce-recomp Main.hs You need to pass "-O" to ghc. (I didn’t check if that fixes it, but without it the optimizer does very very little.) Greetings, Joachim -- Joachim “nomeata” Bre

Re: GHC status report

The problem with some graphics libraries used via FFI (and other libraries that are not thread-safe), if I understand the situation correctly, is that ghci forks a thread when it shouldn't, causing some programs to miscalculate the available stack space (because they think there is only one thread)

Unexpected failure to inline, even with pragma

Dear GHC-ers, It seems I do not quite understand the behaviour of the inliner. Consider these two modules: module Foo.Bar where foo :: Char -> IO () foo = putChar {-# INLINE bar #-} bar :: String -> IO () bar = mapM_ foo module Main where import Foo.Bar main = bar "done" I would expect t

[PATCH] make UNREG build as a platform with 0 hardware registers

From: Sergei Trofimovich 83a003fcaec93dbfd5b46837f2bf3353412b9877 introduced optimization which likes to know if a reg is a hardware reg via 'globalRegMaybe': But --enable-unregisterised does not define that function: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20

Re: GHC status report

On 01/05/2014 02:26, George Colpitts wrote: To elaborate, in the past, I had a lot of problems using libraries from the ghci prompt on the Mac but I haven't tried recently. As an example, on the web page for the book the Haskell School of Ex

validate on Mavericks

Hi, Many tests for validate on master fail on Mavericks. This is because clang produces some warnings. Here is an example: => AssocTyDef03(normal) 3519 of 3960 [0, 1649, 0] cd ./typecheck/should_fail && '/Users/kazu/work/ghc/bindisttest/install dir/bin/ghc ' -fforce-recomp -dcore-lint -dc

RE: Overloaded record fields: we ought to change the name of FldTy

I’m reviewing the patch now. From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Johan Tibell Sent: 30 April 2014 19:14 To: Adam Gundry Cc: ghc-devs@haskell.org Subject: Re: Overloaded record fields: we ought to change the name of FldTy On Wed, Apr 30, 2014 at 5:22 PM, Adam Gundry

RE: GHC status report

| Dynamic linking has been a huge headache in GHC, and it's not clear that | it's an overall improvement compared with the static linker. Now that | 7.8 is out of the way, it's time to have a conversation about whether we | want to do dynamic linking again for 7.10, or revert to static linking. I

Related to #8677, I'm getting "p_dyn" libraries for package ‘integer-gmp’

HI, I'm getting hit by an issue relating to tick 8677 https://ghc.haskell.org/trac/ghc/ticket/8677 I'm sure the problem I'm facing is a user error, though I'm not sure how to resolve it. I'm compiling with `-Odph -rtsopts -threaded -fno-liberate-case -funfolding-use-threshold1000 -funfolding-keen