- ghc-devs - Haskell.org

Fwd: Thread-safe Hint
by Corentin Dupont 28 Aug '15

28 Aug '15

Hello, I am wondering if GHC is now thread-safe. I am using Hint, and it reports that GHC is not thread-safe, and that I can't safely run two instances of the interpreter simultaneously. Is that still the case? Thanks! Corentin ---------- Forwarded message ---------- From: Daniel Gorín <jcpetruzza(a)gmail.com> Date: Thu, Aug 27, 2015 at 5:09 PM Subject: Re: Thread-safe Hint To: Corentin Dupont <corentin.dupont(a)gmail.com> Hi Corentin, sorry for the late reply. Until relatively recently, the problem was still on. But I too remember seeing something related to this issue being fixed (iirc, the problem was the runtime linker, which used global state), so perhaps it is already fixed in 7.10. If you can verify this, it shouldn’t be hard to show the error message only on old versions of ghc. I’ll be away for a couple of weeks, but if you want to look into this and send a patch, I’ll merge it when I return. Cheers, Daniel > On 24 Aug 2015, at 10:43 am, Corentin Dupont <corentin.dupont(a)gmail.com> wrote: > > Hello Daniel, > I noticed the following message in Hint: > This version of GHC is not thread-safe,can't safely run two instances of the interpreter simultaneously. > > Is it still the case with recent versions of GHC? > It would be neat to be able to launch several instances of the interpreter. In my game Nomyx I have several "match-up" going on and having one instance of the interpreter would be nicer. Otherwise I am obliged to reset the interpret each time I want to interpret something, which is time consuming (2-3 seconds). > > Thanks, > C

1 0

Compiling cabal with GHC HEAD
by Oleg Grenrus 27 Aug '15

27 Aug '15

I tried to fix compilation of Cabal using Cabal HEAD. It’s trivial patch: https://github.com/phadej/cabal/commit/525e0680505c74f42a321e55b357a2722279… but it breaks build on every other released GHC: https://travis-ci.org/phadej/cabal/builds/76288656 — The original issue GHC-7.11 complained was: Distribution/Client/Types.hs:71:10: error: Illegal instance declaration for ‘PackageFixedDeps InstalledPackageInfo’ (All instance types must be of the form (T t1 ... tn) where T is not a synonym. Use TypeSynonymInstances if you want to disable this.) In the instance declaration for ‘PackageFixedDeps InstalledPackageInfo’ So I had to add TypeSynonymInstances and FlexibleInstances And also had to change import of InstalledPackageInfo(exposed) in Haddock module. — At this point I’m really confused. I cannot find ‘InstalledPackageInfo_’ symbol anywhere. Can someone explain what happens?

2 3

www.haskell.org/ghc
by Richard Eisenberg 26 Aug '15

26 Aug '15

Hi all, I want to write a URL to represent GHC. It seems that www.haskell.org/ghc is the right one. But that page is quite ugly! A full redesign is always a challenge, so I'll make a simple request: remove announcements of old releases, for some definition of old. (I suggest: all releases from current major version + last release from previous major version.) Right now, I have to scroll down to get to "What is GHC?" and it's a little embarrassing. Thanks! Richard

5 5

OVERLAPPABLE/OVERLAPPING/OVERLAPS pragmas are confusing
by Johan Tibell 25 Aug '15

25 Aug '15

It was brought to my attention that cassava, my library, uses OverlappingInstances, which is now deprecated. There's a suggested fix here: https://github.com/tibbe/cassava/pull/95. The fix seems correct but, as Mikhail points out, makes some client code no longer compile (due to a now missing OVERLAPPABLE pragma). What's the right way to migrate code? Just switching my library to the new pragmas breaks code, so that doesn't seem very attractive. Do clients have to migrate before the libraries they use? -- Johan

4 5

Two step allocator for 64-bit systems
by Erik de Castro Lopo 24 Aug '15

24 Aug '15

Dear Giovanni, Your commit: commit 0d1a8d09f452977aadef7897aa12a8d41c7a4af0 Author: Giovanni Campagna <gcampagn(a)cs.stanford.edu> Date: Fri Jul 17 11:55:49 2015 +0100 Two step allocator for 64-bit systems fails for me on Arm64 (also known as AArch64) Linux. I was wondering if you might be able to look at this ticket I've raised and hopefully shed some light on this issue: https://ghc.haskell.org/trac/ghc/ticket/10682 Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2 1

Request for input on #7253: Top-level bindings in GHCI
by Alex Rozenshteyn 24 Aug '15

24 Aug '15

I'm thinking of working on this ticket ( https://ghc.haskell.org/trac/ghc/ticket/7253) so, as per mpickering's suggestion (https://phabricator.haskell.org/chatlog/channel/3/?at=1353572) I'm emailing the list to solicit input. My first instinct was to treat declarations like "a = 1" in GHCI as equivalent to "let a = 1"; this would be a straightforward matter of parsing. On the other hand, as thoughtpolice comments, let-bound variables are treated subtly differently than top-level bindings, so the proper solution may be more involved. Comments?

3 2

Access to class defaults and derived instances
by David Feuer 24 Aug '15

24 Aug '15

>From time to time, a library lacks an instance for something that I want. For example, I may need to convert data Foo = Bar (Vector Baz) to FishFood, but (to avoid unreasonable dependencies) Vector doesn't have a ToFishFood instance, so I can't just write instance ToFishFood Foo and (using Generic magic) be done with it. Instead, I must write the instance completely by hand, which could be painful. I *could* write an orphan instance, but orphans are evil. What I wish I could do: newtype Vec a = Vec (Vector a) instance ToFishFood a => (newtype Vec) a where -- if needed toFishFood (v :: Vector a) = ... That is, I want to write a super-secret orphan instance for Vector and transfer it to Vec via GND precisely when it is legal to do so. The secret instance could itself be derived (if the constructors are visible) or could make use of default member definitions.

2 2

Releasing resources associated with a RTS worker thread?
by Joe Hendrix 24 Aug '15

24 Aug '15

I am working on FFI bindings to C++ code that associates several memory pools to each thread using the library. When a thread is done using the library, it can call a C function to release the memory pool objects. In the Haskell bindings, I’d like to be able to attach a finalizer that called this cleanup code whenever an RTS OS thread is shutdown. It appeared that the main place that happens is here: https://github.com/ghc/ghc/blob/master/rts/Capability.c#L562-L577 I did not see a way to register a finalizer that is run before the call to shutdownThread. Could this be something worth adding to the RTS? It seems like the most straightforward way would be to add a finalizer list to each task object, and expose a C function for adding callbacks to it. As a fallback, it should be possible to modify the memory pools in the C++ code so that they can be disabled. According to the author of the C++ code, this should have about a 10% slowdown on execution, so it would be nice if I could keep them enabled without a risk of memory leaks. Regards, Joe

1 0

How is this Generic-based instance implementation optimized by GHC?
by Ömer Sinan Ağacan 23 Aug '15

23 Aug '15

Hi all, I'm very confused by an optimization GHC is doing. I have this code: data Tree a = Leaf a | Branch (Tree a) (Tree a) deriving (Generic, Show, NFData) data Tree1 a = Leaf1 a | Branch1 (Tree1 a) (Tree1 a) deriving (Show) instance NFData a => NFData (Tree1 a) where rnf (Leaf1 a) = rnf a rnf (Branch1 t1 t2) = rnf t1 `seq` rnf t2 When I benchmarked rnf calls I realized that they're too close, and I looked at simplifier outputs. I believe these are relevant parts: Rec { Main.$fNFDataTree_$crnf [Occ=LoopBreaker] :: forall a_ab5v. NFData a_ab5v => Tree a_ab5v -> () Main.$fNFDataTree_$crnf = \ (@ a17_ab5v) ($dNFData_ab5w :: NFData a17_ab5v) (eta_B1 :: Tree a17_ab5v) -> case eta_B1 of _ [Occ=Dead] { Leaf g1_aaHO -> ($dNFData_ab5w `cast` (Control.DeepSeq.NTCo:NFData[0] <a17_ab5v>_N :: NFData a17_ab5v ~R# (a17_ab5v -> ()))) g1_aaHO; Branch g1_aaHP g2_aaHQ -> case Main.$fNFDataTree_$crnf @ a17_ab5v $dNFData_ab5w g1_aaHP of _ [Occ=Dead] { () -> Main.$fNFDataTree_$crnf @ a17_ab5v $dNFData_ab5w g2_aaHQ } } end Rec } Rec { Main.$fNFDataTree1_$crnf [Occ=LoopBreaker] :: forall a_abd4. NFData a_abd4 => Tree1 a_abd4 -> () Main.$fNFDataTree1_$crnf = \ (@ a17_abd4) ($dNFData_abd5 :: NFData a17_abd4) (eta_B1 :: Tree1 a17_abd4) -> case eta_B1 of _ [Occ=Dead] { Leaf1 a18_a4tg -> ($dNFData_abd5 `cast` (Control.DeepSeq.NTCo:NFData[0] <a17_abd4>_N :: NFData a17_abd4 ~R# (a17_abd4 -> ()))) a18_a4tg; Branch1 t1_a4th t2_a4ti -> case Main.$fNFDataTree1_$crnf @ a17_abd4 $dNFData_abd5 t1_a4th of _ [Occ=Dead] { () -> Main.$fNFDataTree1_$crnf @ a17_abd4 $dNFData_abd5 t2_a4ti } } end Rec } First one is generated by GHC and second one is hand-written. If you compare, you'll see that they're identical. This looks like some serious magic, because first one is generated from a default method that uses Generic methods and types. Does anyone know how is that possible? Which optimization passes are involved in this? Thanks.

2 2

armv7 "invalid instruction" problem building cabal
by Ben Burdette 21 Aug '15

21 Aug '15

I've been trying to get going with ghc 7.10.2 on armv7 debian, problem is described here: http://stackoverflow.com/questions/32124334/ghc-armv7-binary-cabal-illegal-… thanks for any help! Ben

2 5