- Glasgow-haskell-users

[GHC Users] Dictionary sharing
by Jonas Almström Duregård 02 Jul '12

02 Jul '12

Hi, Is there a way to ensure that functions in a class instance are treated as top level definitions and not re-evaluated? For instance if I have this: >>> class C a where list :: [a] instance List a => List [a] where list = permutations list <<< How can I ensure that list :: [[X]] is evaluated at most once for any type X (throughout my program)? I assume this is potentially harmful, since list can never be garbage collected and there may exist an unbounded number of X's. I currently have a solution that uses Typeable to memoise the result of the function based on its type. Is there an easier way? Regards, Jonas

3 4

Compiling ghcjs
by Nathan Hüsken 02 Jul '12

02 Jul '12

Hi, I hope this is the correct list to ask this question. I am trying to compile the ghcjs compiler. I am on ubuntu 12.04 and have ghc-7.4.1 installed (via apt-get). I am following the instruction I found here: https://github.com/ghcjs/ghcjs The first trouble comes with "git pull ghcjs". I get: remote: Counting objects: 42, done. remote: Compressing objects: 100% (9/9), done. remote: Total 26 (delta 22), reused 21 (delta 17) Unpacking objects: 100% (26/26), done. >From github.com:ghcjs/packages-Cabal * [new branch] encoding -> ghcjs/encoding * [new branch] ghc-7.2 -> ghcjs/ghc-7.2 * [new branch] ghc-7.4 -> ghcjs/ghc-7.4 * [new branch] master -> ghcjs/master You asked to pull from the remote 'ghcjs', but did not specify a branch. Because this is not the default configured remote for your current branch, you must specify a branch on the command line. So I am doing: git pull ghcjs ghc-7.4 Then "git branch ghc-7.4 ghcjs/ghc-7.4" gives me: fatal: A branch named 'ghc-7.4' already exists. And finaly "perl boot" fails with: Error: libraries/extensible-exceptions/LICENSE doesn't exist. Maybe you haven't done './sync-all get'? at boot line 74, <PACKAGES> line 57. What can I do? Thanks! Nathan

2 1

Strange behavior when using stable names inside ghci?
by Facundo Domínguez 29 Jun '12

29 Jun '12

Hi, The program below when loaded in ghci prints always False, and when compiled with ghc it prints True. I'm using ghc-7.4.1 and I cannot quite explain such behavior. Any hints? Thanks in advance, Facundo {-# LANGUAGE GADTs #-} import System.Mem.StableName import Unsafe.Coerce import GHC.Conc data D where D :: a -> b -> D main = do putStr "type enter" s <- getLine let i = fromEnum$ head$ s++"0" d = D i i case d of D a b -> do let a' = a sn0 <- pseq a'$ makeStableName a' sn1 <- pseq b$ makeStableName b print (sn0==unsafeCoerce sn1)

4 4

Re: Fwd: ghc-7.6 branch
by Johan Tibell 29 Jun '12

29 Jun '12

(Moving lots of people to BCC. If you want to follow this discussion it will continue on the glasgow-haskell-users(a)haskell.org list.) On Tue, Jun 26, 2012 at 3:40 PM, Ian Lynagh <ian(a)well-typed.com> wrote: > Please attribute any blame to me, not Paolo; he's only doing what I > asked him to :-) No blame to attribute. I just want to see things changed. :) > When following option 1, I think starting from the HEAD rather than the > last release makes sense in general: Maybe. It doesn't matter as I want (2). > * Some of the recent changes may have been to make the library work with > GHC HEAD, and will therefore be necessary to work with the 7.6 branch This works already today. I periodically get patches to e.g. network and containers to make it work with the current GHC HEAD. That seems to work fine. > * Some libraries will need to have version bumps, which means that other > libraries will need to loosen their dependencies, which means another > release will be needed anyway GHC is no different that any other library here though. Library A is released and thus library B needs to be updated and released. The argument here is that the author of library A needs to make a release of the author of library B's package. > so I think it's a reasonable default. But if it doesn't apply for a > particular library, then no problem, just let us know - that's why we're > e-mailing you :-) So at least don't make releases of containers (I think that's the only library I maintain that's released by GHC nowadays.) Can I please have this preference sticky in case I'm on vacation next time one of these emails go out? Aside: I don't believe this has happened yet but imagine the odd feeling of a library author, whose library was recently added as a GHC dependency, getting an email saying that if he/she doesn't reply GHC will make a release of his/her library! > That sounds like it would also work. I assume there's some way to pull > to a tag. git fetch (and thus pull) retrieves all branches and tags by default (and thus all commits pointed to by them.) Cheers, Johan

5 9

Re: Fwd: ghc-7.6 branch
by Johan Tibell 27 Jun '12

27 Jun '12

On Wed, Jun 27, 2012 at 3:20 AM, Paolo Capriotti <p.capriotti(a)gmail.com> wrote: > On Wed, Jun 27, 2012 at 12:30 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: >>> * Some libraries will need to have version bumps, which means that other >>> libraries will need to loosen their dependencies, which means another >>> release will be needed anyway >> >> GHC is no different that any other library here though. Library A is >> released and thus library B needs to be updated and released. The >> argument here is that the author of library A needs to make a release >> of the author of library B's package. > > The difference is that here the dependency is mutual, in a way. GHC needs > library B to build, and library B needs to adapt to changes to GHC. Making a local change is not the same as making a release though. I make local changes to other people's code all the time, to unblock myself until the patches have made their way upstream. I'm not against that, I'm against releasing other people's code except they explicitly ask you to. > That's not what I wrote, however. We are just creating branches at this stage. > If we do make changes and need a version bump, we will coordinate again with > the maintainer to ensure everything goes upstream normally. I know that's not what you wrote (hence the "has not happened yet" part.) But consider the scenario for a second. If GHC adds a new package as a dependency now all of a sudden the maintainer of that package is in a situation where he/she explicitly needs to state a preference to have someone else not make release versions of his/her package! > It still makes sense for us to maintain a 'ghc-x.x' branch in each of the > mirrored resositories. It doesn't have to mirror an upstream branch > necessarily, but that's the easiest way to ensure all commits end up upstream. Except this is not what happens always. Commits have not always made it upstream in the past and sometimes packages released by GHC aren't uploaded to Hackage. > The current workflow is: > > - library needs a change > - make the change locally, validate, test > - send the patch upstream This doesn't always happen. > - wait for the patch to be integrated > - pull changes into the corresponding GHC mirror Just amend > - Before release, ask maintainer to make new release the package. and we'll be in the same situation of all other packages on Hackage. > Using tags as you propose should also be possible, but it would require a > release on the part of the library maintainer every time a change is made, and > then we need to update our mirror and point it to the new tag. I don't really object to you having unreleased changes for shorter periods of time. Just you releasing them. > The advantage would be that no revision of GHC ever depends an unreleased > revision of a library, but is this really worth the extra trouble? Those > intermediate releases are not particularly meaningful, and they may even end up > being unusable with every released version of GHC. I don't think this is necessary. The problem is releasing other people's code, not having temporary deviating branches. P.S. All these problems will disappear once we have proper ACLs on Hackage, as at that point no one but the maintainer and people he/she gives permission to can upload his/her package to Hackage. -- Johan

1 0

parallel garbage collection performance
by John Lato 27 Jun '12

27 Jun '12

Hello, I have a program that is intermittently experiencing performance issues that I believe are related to parallel GC, and I was hoping to get some advice on how I might improve it. Essentially, any given execution is either slow or fast (the same executable, without recompiling), most often slow. So far I can't find anything that would trigger either case. This is with ghc-7.4.2 on 64bit linux. Here are the statistics from running with -N4 -A8m -s: slow run: 16,647,460,328 bytes allocated in the heap 313,767,248 bytes copied during GC 17,305,120 bytes maximum residency (22 sample(s)) 601,952 bytes maximum slop 73 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1268 colls, 1267 par 8.62s 8.00s 0.0063s 0.0389s Gen 1 22 colls, 22 par 0.63s 0.60s 0.0275s 0.0603s Parallel GC work balance: 1.53 (39176141 / 25609887, ideal 4) MUT time (elapsed) GC time (elapsed) Task 0 (worker) : 0.00s ( 0.01s) 0.00s ( 0.00s) Task 1 (worker) : 0.00s ( 13.66s) 0.01s ( 0.04s) Task 2 (bound) : 0.00s ( 13.98s) 0.00s ( 0.00s) Task 3 (worker) : 0.00s ( 18.14s) 0.16s ( 0.44s) Task 4 (worker) : 0.53s ( 17.49s) 1.29s ( 4.25s) Task 5 (worker) : 0.00s ( 17.45s) 1.25s ( 4.42s) Task 6 (worker) : 0.00s ( 14.98s) 1.75s ( 6.90s) Task 7 (worker) : 0.00s ( 21.87s) 0.02s ( 0.06s) Task 8 (worker) : 0.01s ( 37.12s) 0.06s ( 0.17s) Task 9 (worker) : 0.00s ( 21.41s) 4.88s ( 15.99s) Task 10 (worker) : 0.84s ( 43.06s) 1.99s ( 8.25s) Task 11 (bound) : 6.39s ( 51.13s) 0.06s ( 0.18s) Task 12 (worker) : 0.00s ( 0.00s) 8.04s ( 21.42s) Task 13 (worker) : 0.43s ( 28.38s) 8.14s ( 22.94s) Task 14 (worker) : 5.35s ( 29.30s) 5.81s ( 22.02s) SPARKS: 7 (7 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.03s ( 0.01s elapsed) MUT time 43.88s ( 42.71s elapsed) GC time 9.26s ( 8.60s elapsed) EXIT time 0.01s ( 0.01s elapsed) Total time 53.65s ( 51.34s elapsed) Alloc rate 374,966,825 bytes per MUT second Productivity 82.7% of total user, 86.4% of total elapsed gc_alloc_block_sync: 1388000 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 -- -------------------------- Fast run: 42,061,441,560 bytes allocated in the heap 725,062,720 bytes copied during GC 36,963,480 bytes maximum residency (21 sample(s)) 1,382,536 bytes maximum slop 141 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 3206 colls, 3205 par 8.34s 1.87s 0.0006s 0.0089s Gen 1 21 colls, 21 par 0.76s 0.17s 0.0081s 0.0275s Parallel GC work balance: 1.78 (90535973 / 50955059, ideal 4) MUT time (elapsed) GC time (elapsed) Task 0 (worker) : 0.00s ( 0.00s) 0.00s ( 0.00s) Task 1 (worker) : 0.00s ( 0.00s) 0.00s ( 0.00s) Task 2 (worker) : 0.00s ( 11.50s) 0.00s ( 0.00s) Task 3 (worker) : 0.00s ( 12.40s) 0.00s ( 0.00s) Task 4 (worker) : 0.58s ( 12.20s) 0.59s ( 0.61s) Task 5 (bound) : 0.00s ( 12.89s) 0.00s ( 0.00s) Task 6 (worker) : 0.00s ( 13.40s) 0.02s ( 0.02s) Task 7 (worker) : 0.00s ( 14.66s) 0.00s ( 0.00s) Task 8 (worker) : 0.95s ( 14.18s) 0.69s ( 0.76s) Task 9 (worker) : 2.82s ( 13.50s) 1.37s ( 1.44s) Task 10 (worker) : 1.72s ( 17.59s) 1.07s ( 1.16s) Task 11 (worker) : 3.99s ( 24.68s) 0.37s ( 0.38s) Task 12 (worker) : 1.24s ( 24.25s) 0.80s ( 0.82s) Task 13 (bound) : 6.18s ( 25.02s) 0.04s ( 0.04s) Task 14 (worker) : 1.46s ( 23.42s) 1.59s ( 1.65s) Task 15 (worker) : 0.00s ( 0.00s) 0.66s ( 0.66s) Task 16 (worker) : 11.00s ( 23.36s) 1.67s ( 1.70s) SPARKS: 28 (28 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.04s ( 0.02s elapsed) MUT time 42.08s ( 23.02s elapsed) GC time 9.10s ( 2.04s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 51.69s ( 25.09s elapsed) Alloc rate 987,695,300 bytes per MUT second Productivity 82.3% of total user, 169.6% of total elapsed gc_alloc_block_sync: 164572 whitehole_spin: 0 gen[0].sync: 164 gen[1].sync: 18147 When I record an eventlog and view it with Threadscope, the slow run shows long frequent pauses for GC, whereas on a fast run GC is extremely fast. Running with the parallel collector disabled (-qg) is more-or-less consistently between these two runs. Given this, can anyone suggest any likely causes of this issue, or anything I might want to look for? Also, should I be concerned about the much larger gc_alloc_block_sync level for the slow run? Does that indicate the allocator waiting to alloc a new block, or is it something else? Am I on completely the wrong track? Thanks very much, John L.

7 12

Cannot build user's guide
by José Pedro Magalhães 26 Jun '12

26 Jun '12

Hi, I cannot build the user's guide. Doing make html stage=0 FAST=YES under docs/users_guide, I get: ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final html_docs/users_guide inplace/bin/mkUserGuidePart docs/users_guide/users_guide.xml inplace/bin/mkUserGuidePart docs/users_guide/what_glasgow_exts_does.gen.xml "rm" -rf docs/users_guide/users_guide/ "" --stringparam base.dir docs/users_guide/users_guide/ --stringparam use.id.as.filename 1 --stringparam html.stylesheet fptools.css --nonet --stringparam toc.section.depth 3 --stringparam section.autolabel 1 --stringparam section.label.includes.component.label 1 http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsldocs/users… /bin/sh: 1: : Permission denied make[2]: *** [docs/users_guide/users_guide/index.html] Error 127 make[1]: *** [html_docs/users_guide] Error 2 It seems like make is just calling an empty program name. What could I be missing? (Btw, validate goes through. Does validate not build the user's guide?) Thanks, Pedro

3 3

Segmentation fault/access violation in generated code
by Bas van Dijk 24 Jun '12

24 Jun '12

Hello, I'm trying to solve #5254 (http://hackage.haskell.org/trac/ghc/ticket/5254) The issue can be isolated to the following short program which only uses bindings-libusb (http://hackage.haskell.org/packages/archive/bindings-libusb/1.4.4.1/doc/htm…) -------------------------------------------------- module Main where import Foreign import qualified Foreign.Concurrent as FC import Control.Concurrent import Bindings.Libusb.InitializationDeinitialization main :: IO () main = do ctxPtr <- alloca $ \ctxPtrPtr -> do _ <- c'libusb_init ctxPtrPtr peek ctxPtrPtr fp <- newForeignPtr p'libusb_exit ctxPtr -- fp <- FC.newForeignPtr ctxPtr $ c'libusb_exit ctxPtr threadDelay 3000000 print $ fp == fp -------------------------------------------------- When I run this program on Windows I get the following error after 3 seconds: >example.exe True Segmentation fault/access violation in generated code The error disappears when I change the newForeignPtr line to the commented FC.newForeignPtr line. Any idea why this is happening? I don't know if it has anything to do with it but note that the libusb FFI functions are using the stdcall calling convention on Windows. I'm using GHC-7.4.2 but this error also occurs in previous versions. To reproduce this just download libusb (I recommend http://libusbx.org/) and when cabal installing bindings-libusb tell it the path to the include and library files, as in: cabal install bindings-libusb --extra-include-dirs="...\libusb\include\libusb-1.0" --extra-lib-dirs="...\libusb\MinGW32\dll" and make sure the libusb-1.0.dll is in your working directory when running the example program. Regards, Bas

2 3

Windows 64bit GHC port: First alpha release
by Ian Lynagh 19 Jun '12

19 Jun '12

Dear GHC users, Windows 64bit GHC port: First alpha release ------------------------------------------- The Industrial Haskell Group has recently funded work by Well-Typed to make a Windows 64bit port of GHC. The port will officially be released as part of the upcoming GHC 7.6.1 release, but in the mean-time we are pleased to announce that an alpha release is available. You can download the installer for the alpha release from http://www.haskell.org/ghc/dist/win64_alpha1/ If you encounter any problems with the alpha, please report them as GHC bugs in the normal way: http://hackage.haskell.org/trac/ghc/wiki/ReportABug If any significant issues are found, then the platform page at http://hackage.haskell.org/trac/ghc/wiki/WindowsGhc will also be updated. About the IHG ------------- The Industrial Haskell Group (IHG) is an organisation to support the needs of commercial users of the Haskell programming language. The IHG funds work to improve the Haskell ecosystem for industrial Haskell users. http://industry.haskell.org/ About Well-Typed ---------------- Well-Typed LLP is a Haskell services company, providing Haskell consultancy services and writing bespoke Haskell applications. http://www.well-typed.com/

1 0

JustHub 'Sherkin' Release
by Chris Dornan 14 Jun '12

14 Jun '12

I am pleased to announce the Sherkin release of the JustHub distribution of Haskell for Enterprise Linux and the release of the Hub source code on which the distribution is based to Hackage and GitHub. The JustHub distribution is distinctive in providing a comprehensive back-catalogue of GHC tool chains (back to 6.10.4) and major Haskell Platform releases (currently back to 2011.2.0.1) as well as the timely appearance of leading edge GHC releases (such as GHC 7.4.2) in addition to the Haskell Platform de jour (2012.2.0.0), all of which can be deployed simultaneously on the same system. Previous releases of the distribution have been confined to Red Hat Enterprise Linux versions 5 and 6 (and of course CentOS and Scientific Linux); this release expands this coverage to Fedora Linux 16 and 17, which can deployed along side or integrated into Fedora Linux's excellent native Haskell distribution. The JustHub distribution is based on the Hub system for sandbox development that allows each work tree to work in its own sandboxed environment with a specific tool chain and a private user-package database. All of the standard Haskell tools inter-operate cleanly and transparently with the sandboxes and operate in the normal way outside of them. Sandboxed environments (hubs) can be shared between work trees as well as being (re)named, annotated, replicated, swapped, archived, locked and removed. Proper package deletion with the option of garbage collecting orphaned code and documentation is also supported. If anyone would like to incorporate the hub system into a Haskell distribution or port it to a non-Posix system then they are very welcome to contact me (though be warned: time is tight just now). Note that while the distro has had plenty of serious usage (funnily enough it is popular with build-bot admins) it has also been recently extended and revised the software remains in beta testing for now. For news, documentation, articles, download and installation instructions, links to the repositories and trackers etc., see http://justhub.org. Chris Dornan

1 0