June 2012 - Glasgow-haskell-users

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

28 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 23 Jun '12

23 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 13 Jun '12

13 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

Is stderr flushed automatically after exceptions are printed
by Johan Tibell 13 Jun '12

13 Jun '12

Hi, If a program throws an exception that will cause it to be terminated (i.e. the exception isn't caught), will the code that prints out the error message to stderr make sure to flush stderr before terminating the process? -- Johan

2 1

Kindness of strangers (or strangeness of Kinds)
by AntC 12 Jun '12

12 Jun '12

I'm confused about something with promoted Kinds (using an example with Kind- promoted Nats). This is in GHC 7.4.1. (Apologies if this is a known bug/limitation/already explained somewhere -- I know 7.4.1 is relatively experimental. I have searched the bug tracs and discussions I could find.) Starting with nats at type level, this works fine: {-# OPTIONS_GHC -XTypeFamilies -XFlexibleInstances -XUndecidableInstances -XScopedTypeVariables #-} data ZeT; data SuT n class NatToIntT n where natToIntT :: n -> Int instance NatToIntT ZeT where natToIntT _ = 0 instance (NatToIntT n) => NatToIntT (SuT n) where natToIntT _ = 1 + natToIntT (undefined :: n) I converted naively to promoted Kinds: {-# OPTIONS_GHC -XDataKinds -XPolyKinds -XKindSignatures #-} data MyNat = Z | S Nat class NatToIntN (n :: MyNat) where natToIntN :: (n :: MyNat) -> Int instance NatToIntN Z where natToIntN _ = 0 instance (NatToIntN n) => NatToIntN (S n) where natToIntN _ = 1 + natToInt (undefined :: n) But GHC rejects the class declaration (method's type): "Kind mis-match Expected kind `ArgKind', but `n' has kind `MyNat'" (Taking the Kind signature out of the method's type gives same message.) Eh? MyNat is what I want the argument's Kind to be. A PolyKinded version (cribbed from 'Giving Haskell a Promotion' on multi- kinded TypeRep) also works fine: data Proxy a = Proxy class NatToInt (n :: MyNat) where natToInt :: Proxy (n :: MyNat) -> Int instance NatToInt Z where natToInt _ = 0 instance (NatToInt n) => NatToInt (S n) where natToInt _ = 1 + natToInt (Proxy :: Proxy n) But this seems too Kind. I only ever want to supply Nats as arguments. What does the `ArgKind' message mean? (I've also seen messages with `AnyKind' -- what that?) There's a discussion in SPJ's Records proposal last year http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields#Sho… ethaveaproxyargument Is that related? Do I need explicit Type/Kind application for this to work? AntC

7 12

Re: [Haskell] ANNOUNCE: GHC version 7.4.2
by Brent Yorgey 11 Jun '12

11 Jun '12

Thanks for the release! One quick question -- the release notes say "A bug in dependency analysis of type declarations in the presence of type families (#5826) has been fixed." However, #5826 seems to be about something entirely different (something about the user guide). Does anyone know the actual ticket being referred to? I'd like to read it in more detail but haven't been able to find it. thanks, -Brent On Sun, Jun 10, 2012 at 08:20:18PM +0100, Paolo Capriotti wrote: > ============================================================= > The (Interactive) Glasgow Haskell Compiler -- version 7.4.2 > ============================================================= > > The GHC Team is pleased to announce a new patchlevel release of GHC. > This release contains a number of bugfixes relative to 7.4.1, so we > recommend upgrading. > > The release notes are here: > > http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/release-7-4-2.html > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > http://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating good code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces (C, whatever). GHC is distributed under a > BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page http://www.haskell.org/ghc/ > GHC developers' home page http://hackage.haskell.org/trac/ghc/ > Haskell home page http://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > http://hackage.haskell.org/trac/ghc/wiki/Contributors > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > http://hackage.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > http://hackage.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > http://www.haskell.org/mailman/listinfo/ > > Some GHC developers hang out on #haskell on IRC, too: > > http://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > http://www.haskell.org/ghc/reportabug > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

2 1