- Glasgow-haskell-users

Caching intermediate powers in GHC.Float
by Bas van Dijk 16 May '14

16 May '14

Does the following make sense: https://ghc.haskell.org/trac/ghc/ticket/9120 Bas

1 0

vector and GeneralizedNewtypeDeriving
by John Lato 15 May '14

15 May '14

Hello, Prior to ghc-7.8, it was possible to do this: > module M where > > import qualified Data.Vector.Generic.Base as G > import qualified Data.Vector.Generic.Mutable as M > import Data.Vector.Unboxed.Base -- provides MVector and Vector > > newtype Foo = Foo Int deriving (Eq, Show, Num, > M.MVector MVector, G.Vector Vector, Unbox) M.MVector is defined as > class MVector v a where > basicLength :: v s a -> Int etc. With ghc-7.8 this no longer compiles due to an unsafe coercion, as MVector s Foo and MVector s Int have different types. The error suggests trying -XStandaloneDeriving to manually specify the context, however I don't see any way that will help in this case. For that matter, I don't see any way to fix this in the vector package either. We might think to define > type role M.MVector nominal representational but that doesn't work as both parameters to M.MVector require a nominal role (and it's probably not what we really want anyway). Furthermore Data.Vector.Unboxed.Base.MVector (which fills in at `v` in the instance) is a data family, so we're stuck at that point also. So given this situation, is there any way to automatically derive Vector instances from newtypes? tl;dr: I would really like to be able to do: > coerce (someVector :: Vector Foo) :: Vector Int am I correct that the current machinery isn't up to handling this? Thanks, John

5 8

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

14 May '14

A couple of updates: Edward Yang responded here, confirming the sort of track I was thinking on: http://blog.ezyang.com/2014/05/ghc-and-mutable-arrays-a-dirty-little-secret/ And I can report that: 1) cloning a frozen array doesn't provide the benefits of creating a new array and freezing 2) and anyway, I'm seeing some segfaults when cloning, freezing, reading then writing in my library I'd love to learn if there are any other approaches I might take, e.g. maybe with my own CMM primop variants? Thanks, Brandon

6 7

HSghc-prim-0.3.1.0.o: unknown symbol 'memcpy'
by M Farkas-Dyck 11 May '14

11 May '14

I just built stock ghc 7.8.1 against musl on Linux x86_64. I get this: $ ghci GHCi, version 7.8.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... ghc: /lib/ghc-7.8.1/ghc-prim-0.3.1.0/HSghc-prim-0.3.1.0.o: unknown symbol `memcpy' ghc: unable to load package `ghc-prim' $ memcpy is defined in /lib/libc.a; how can I link it in? I tried -lc and -opt-lc options to ghci, in vain.

2 4

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