- Glasgow-haskell-users

Using mutable array after an unsafeFreezeArray, and GC details
by Brandon Simmons 11 May '14

11 May '14

I have an unusual application with some unusual performance problems and I'm trying to understand how I might use unsafeFreezeArray to help me, as well as understand in detail what's going on with boxed mutable arrays and GC. I'm using the interface from 'primitive' below. First some basic questions, then a bit more background 1) What happens when I do `newArray s x >>= \a-> unsafeFreezeArray a >> return a` and then use `a`? What problems could that cause? 2) And what if a do a `cloneMutableArray` on `a` and likewise use the resulting array? Background: I've been looking into an issue [1] in a library in which as more mutable arrays are allocated, GC dominates (I think I verified this?) and all code gets slower in proportion to the number of mutable arrays that are hanging around. I've been trying to understand how this is working internally. I don't quite understand how the "remembered set" works with respect to MutableArray. As best I understand: the remembered set in generation G points to certain objects in older generations, which objects hold references to objects in G. Then for MutableArrays specifically, card-marking is used to mark regions of the array with garbage in some way. So my hypothesis is the slowdown is associated with the size of the remembered set, and whatever the GC has to do on it. And in my tests, freezing the array seems to make that overhead (at least the overhead proportional to number of arrays) disappear. Now I'm really lost in the woods though. My hope is that I might be able to safely use unsafeFreezeArray to help me here [3]. Here are the particulars of how I use MutableArray in my algorithm, which are somewhat unusual: - keep around a small template `MutableArray Nothing` - use cloneMutableArray for fast allocation of new arrays - for each array only a *single* write (CAS actually) happens at each position In fact as far as I can reason, there ought to be no garbage to collect at all until the entire array becomes garbage (the initial value is surely shared, especially since I'm keeping this template array around to clone from, right?). In fact I was even playing with the idea of rolling a new CAS that skips the card-marking stuff. Any guidance is appreciated. Thanks, Brandon [1]: http://stackoverflow.com/questions/23462004/code-becomes-slower-as-more-box… [2]: http://www.haskell.org/pipermail/glasgow-haskell-users/2012-March/022142.ht… [3]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/EagerPromot…

4 10

GHC rewrite rules and constructor wrappers?
by Conal Elliott 06 May '14

06 May '14

I'm trying to sort out the relationship of GHC rewrite rules and constructor wrappers. I have rules like > "reify/(:<)" reifyEP (:<) = kPrim VecSP This rule seems to fire for `reifyEP ($W:<)` rather than `reifyEP (:<)`. If I'm tracking (uncertain), `($W:<)` inlines to `(:<)`. Sometimes I'm able to preserve the `$W` form, but sometimes I get the bare form when inlining a definition from another already-compiled module. In those cases, I don't know how to get my rules to fire. Advice and explanation appreciated, including pointers explanations of the role of these wrappers in GHC. -- Conal

2 1

RFC: include a cabal-install executable in future GHC releases
by Carter Schonwald 04 May '14

04 May '14

Hey everyone, I'd like to propose that GHC releases 7.8.1 onwards include a cabal-install (aka cabal) executable, but not include the library deps of cabal-install that aren't already distributed with ghc.(unless ghc should have those deps baked in, which theres very very good reasons not to do.). currently if someone wants just a basic haskell install of the freshest ghc they have to install a ghc bindist, then do a boostrap build of cabal-install by hand (if they want to actually get anything done :) ). This is not a human friendly situation for folks who are new to haskell tooling, but want to try out haskell dev on a server style vm or the like! point being: It'd be great for haskell usability (and egads amounts of config time, even by seasoned users) the ghc bindists / installers included a cabal-install binary thoughts? -Carter

15 32

"haskeline dylib failure on MacOS in GHC HEAD"
by Conal Elliott 02 May '14

02 May '14

I built GHC HEAD on MacOS 10.9.2 from GitHub yesterday and am getting an error when trying to use a problem (HERMIT) that uses haskeline: Loading package haskeline-0.7.1.2 ... <command line>: can't load .so/.DLL for: /Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib (dlopen(/Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib, 9): Symbol not found: _terminfozm0zi4zi0zi0_SystemziConsoleziTerminfoziBase_termText1_closure Referenced from: /Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib Expected in: /Users/conal/install/quickest/lib/ghc-7.9.20140430/bin/../terminfo-0.4.0.0/libHSterminfo-0.4.0.0-ghc7.9.20140430.dylib in /Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib) bash-3.2$ ls -l /Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib -rwxr-xr-x+ 1 conal staff 2337596 May 2 10:22 /Users/conal/.cabal/lib/x86_64-osx-ghc-7.9.20140430/haskeline-0.7.1.2/libHShaskeline-0.7.1.2-ghc7.9.20140430.dylib Any ideas? -- Conal

1 0

Removing -fext-core
by Austin Seipp 30 Apr '14

30 Apr '14

Hello all, Recently I was wondering something: is there any reason to keep -fext-core around? In particular, it's been broken for a while at this point, see GHC bug #5630[1] As far as I'm aware there really aren't any users of it still around these days, at least none working with a modern GHC. And it seems like if people were to need access to Core, they could use a plugin or some such to get direct access to what they want. Simon mentioned removing ExtCore in face of replacing it with IfaceSyn in the compiler. I'm not entirely sure how much work that would be to bring it all up to scratch if people needed it, but maybe it's worth thinking about. One other issue is a notion of semantics which is present in External Core, but we also now have a documented semantics for GHC's core language as well (which has evolved quite a bit), so I don't know how much that matters. So long story short: I don't think anyone is using it, maintaining it, and it seems subsumed by more recent events. Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, unless someone is willing to step up and really maintain it. If you're using it, you should probably speak up soon I'd imagine... [1] https://ghc.haskell.org/trac/ghc/ticket/5630 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 4

how to compile non-dynamic ghc-7.8.2 ?
by John Lato 30 Apr '14

30 Apr '14

Hello, I'd like to compile ghc-7.8.2 with DynamicGhcPrograms disabled (on 64-bit linux). I downloaded the source tarball, added DYNAMIC_GHC_PROGRAMS = NO to mk/build.mk, and did ./configure && ./make. ghc builds and everything seems to work (cabal installed a bunch of packages, ghci seems to work), however whenever I try to run Setup.hs dynamically (either 'runghc Setup.hs configure' or loading it with ghci and executing 'main') it dumps core. Compiling Setup.hs works, and nothing else has caused ghci to crash either (this email is a literate haskell file equivalent to Setup.hs). Building with DYNAMIC_GHC_PROGRAMS = YES works properly. With that in mind, I have a few questions: How should I compile a non-dynamic ghc? Is this a bug in ghc? Thanks, John L. * Setup.hs > import Distribution.Simple > main = defaultMain

6 9

Re: [core libraries] Re: Tightening up on inferred type signatures
by Ganesh Sittampalam 30 Apr '14

30 Apr '14

On 23/04/2014 20:04, dm-list-haskell-libraries(a)scs.stanford.edu wrote: > Edward Kmett <ekmett(a)gmail.com> writes: > >> You can wind up in perfectly legitimate situations where the name for the >> type you are working with isn't in scope, but where you can write a >> combinator that would infer to have that type. I'd hate to lose that. >> >> It is admittedly of marginal utility at first glance, but there are some >> tricks that actually need it, and it can also arise if a type synonym >> expands to a type that isn't exported or brought into scope, so trying to >> push this line of reasoning too far I is possibly not too productive. > > Good point. In particular, it's not weird at all want to export type > synonyms on their own, particularly where ghost type parameters are used > to select between only a few cases. Consider something like this > (inspired by postgresql-orm): Is there an abstraction being protected by only exporting the type synonym in cases like this? Cheers, Ganesh

2 2

Fwd: Type/type class information in GHC plugin
by Shen Chen Xu 27 Apr '14

27 Apr '14

Hello everyone, I would like to write a GHC plugin which adds wrapper to functions. Say I have a function addWrapper :: Ord a => (a -> b) -> a -> b which is supposed to transform (assuming the argument is in the Ord class) foo = \ x -> ... into foo = addWrapper (\ x -> ...) This works fine if I'm only interested in wrapping functions of type Int -> Int, in which case I make addWrapper to also have type addWrapper :: (Int -> Int) -> Int -> Int and use mkCoreApp to apply addWrapper to the right hand side. However, if I want it to be polymorphic as described above, the transformed GHC Core for an Int -> Int function should look like foo = addHook @ GHC.Types.Int @ GHC.Types.Int GHC.Classes.$fOrdInt (\ x -> ...) My question is, given the right hand side of foo, how do I construct the type/type class information inside Core shown above? Cheers, Shen

2 1

Help with cast error
by Conal Elliott 24 Apr '14

24 Apr '14

I'd appreciate help with a cast-related Core Lint error I'm getting with a GHC plugin I'm working on: Argument value doesn't match argument type: Fun type: Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) => EP (Enc (Vec ('S 'Z) Bool)) -> EP (Bool, ()) Arg type: ~R# (Enc (Vec ('S 'Z) Bool)) (Bool, ()) Arg: CO Sub (TFCo:R:EncVec[0] <'Z>_N <Bool>_N) ; (Sub TFCo:R:EncBool[0], Sub (TFCo:R:EncVec0[0] <Bool>_N))_R (I omitted the module prefixes for brevity.) Do I have a role wrong here, or maybe something more fundamental? I can easily supply more info if it'd help. Thanks, -- Conal

2 2

RE: [core libraries] Re: Tightening up on inferred type signatures
by Simon Peyton Jones 23 Apr '14

23 Apr '14

| Independent of language extensions, what about types and classes whose | names are not in scope. Is there an implicit "... if you import all | the relevant symbols" and the end of the rule? Good point. I'm honestly unsure how far to push this one! (It'd be relatively easy to check whether they were in scope and complain if not, but ...) Simon | -----Original Message----- | From: haskell-core-libraries(a)googlegroups.com [mailto:haskell-core- | libraries(a)googlegroups.com] On Behalf Of David Mazieres | Sent: 22 April 2014 00:41 | To: Simon Peyton Jones; Haskell Libraries (libraries(a)haskell.org) | core-libraries-committee(a)haskell.org; GHC users | Subject: [core libraries] Re: Tightening up on inferred type signatures | | Simon Peyton Jones <simonpj(a)microsoft.com> writes: | | > GHC generally obeys this rule | > | > * If GHC infers a type f::type, then it's OK for you to add a type | > signature saying exactly that. | | Independent of language extensions, what about types and classes whose | names are not in scope. Is there an implicit "... if you import all | the relevant symbols" and the end of the rule? | | David | | -- | You received this message because you are subscribed to the Google | Groups "haskell-core-libraries" group. | To unsubscribe from this group and stop receiving emails from it, send | an email to haskell-core-libraries+unsubscribe(a)googlegroups.com. | For more options, visit https://groups.google.com/d/optout.

2 1