May 2014 - 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