February 2013 - Glasgow-haskell-users

ANNOUNCE: GHC 7.6.2 Release Candidate 1
by Ian Lynagh 21 Mar '13

21 Mar '13

We are pleased to announce the first release candidate for GHC 7.6.2: http://www.haskell.org/ghc/dist/7.6.2-rc1/ This includes the source tarball, installers for Windows, and bindists for Windows, Linux, OS X and FreeBSD, on x86 and x86_64. We plan to make the 7.6.2 release early in 2013. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

8 12

RE: GHC 7.8 release?
by Simon Peyton-Jones 13 Mar '13

13 Mar '13

We seem to be circling ever closer to consensus here! Yay! Indeed! Good :-) However, I’m not getting the bit about API changing vs non-API changing. Firstly I don’t know which APIs are intended. The GHC API is essentially GHC itself, so it changes daily. Maybe you mean the base package? Or what? I suspect you mean that a “non-API-changing” release absolutely guarantees to compile any package that compiled with the previous version. If so, that is a very strong constraint indeed. We do observe it for patch releases for GHC (e g 7.6.2 should compile anything that 7.6.1 compiles). But I think it would be difficult to guarantee for anything beyond a patch release. Every single commit (and the commit rate is many/day) would have to be evaluated against this criterion. And if it failed the criterion, it would have to go on a API-breaking HEAD. In effect we’d have two HEADs. I can’t see us sustaining this. And I don’t yet really see why it’s necessary. If you don’t want an API-breaking change, stick with the patch releases. So, we have a channel for non-API-breaking changes already: the patch releases. So that means we already have all three channels! · Haskell Platform · Patch-level releases · New releases if that’s so, all we need is better signposting. And I’m all for that! Have I got this right? Simon From: Mark Lentczner [mailto:mark.lentczner@gmail.com] Sent: 09 February 2013 17:48 To: Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon Peyton-Jones; Mark Lentczner; andreas.voellmy(a)gmail.com; Carter Schonwald; kostirya(a)gmail.com; Edsko de Vries; ghc-devs(a)haskell.org; glasgow-haskell-users Subject: Re: GHC 7.8 release? We seem to be circling ever closer to consensus here! Yay! I think the distinction of non-API breaking and API breaking release is very important. Refining SPJ's trifecta: Haskell Platform comes out twice a year. It is based on very stable version of GHC, and intention is that people can just assume things on Hackage work with it. These are named for the year and sequence of the release: 2013.2, 2013.2.1, 2013.4,... Non-API breaking releases can come out as often as desired. However, the version that is current as of mid-Feb. and mid-Aug. will be the ones considered for HP inclusion. By non-API breaking we mean the whole API surface including all the libraries bundled with GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions of features that must be explicitly enabled are okay. Additions of new APIs into existing modules are discouraged: Much code often imports base modules wholesale, and name clashes could easily result. These should never bump the major revision number: 7.4.1, 7.4.2... API breaking releases happen by being released into a separate channel when ready for library owners to look at them. This channel should probably go through several stages: Ready for core package owners to work with, then HP package owners, then all package owners. I'd imagine this is a several month process. At the end of which, the release can go into the main channel. Such a merge shouldn't happen more than once a year... I think even once every two years is fine (!) To avoid confusion, I'd suggest that while in the separate channel, these release be named with odd number: 7.9, 7.11,..., and when moved to the main channel renamed to even: 7.10, 7.12... This idea of three channels needs to be much more clearly communicated. The warning on the download page is a failure: Googling "ghc" takes you to the home page of GHC which immediately trumpets the "Lastest News" of a release of GHC 7.6.2. Once a user has read that and decided to download, then "STOP!" box is a) going to be skipped as they scan for the download link, and b) if read and followed, causes the "WTF? Why is HP so back rev?" So we need to change the front page so that the three channels are clearly communicated and targeted at the right users. - Mark (BTW: The first few links on the GHC web site are out of date: The second nav link is to a survey that is 7 years old. The License page is 8 years out of date. The FAQ is over a year old.) On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh <ian(a)well-typed.com<mailto:ian@well-typed.com>> wrote: On Sat, Feb 09, 2013 at 12:06:12PM +0000, Simon Marlow wrote: > > As a straw man, let's suppose we want to do annual API releases in > September, with intermediate non-API releases in February. That's a non-API release 5 months after the API release. 6.10.2 was 5 months after 6.10.1 (.3 was 1 month later, .4 a further 2) 6.12.2 was 4 months after 6.12.1 (.3 was 2 months later) 7.0.2 was 3.5 months after 7.0.1 (.3 was 1 month later, .4 a further 3) 7.2.2 was 3 months after 7.2.1 7.4.2 was 4 months after 7.4.1 7.6.2 was 4.5 months after 7.6.2 so if we do non-API releases, then perhaps it would make sense to stop doing minor releases (unless a release turns out to just be broken). Thanks Ian

26 103

Race-condition in alternative 'System.Timeout.timeout' implementation
by Herbert Valerio Riedel 27 Feb '13

27 Feb '13

Hello *, I've been experimenting with an alternative implementation of 'System.Timeout.timeout'[1] which avoids the overhead of spawning a new thread for each invocation. Part of my motivation is to see if I can implement a faster version of threadWaitReadTimeout :: Int -> Fd -> IO Bool threadWaitReadTimeout to = liftM (maybe False (const True)) . timeout to . threadWaitRead and thus exploit GHC's event notification system instead of having to reimplement a timeout-manager myself (like popular HTTP server libraries such as Snap or Warp do currently). The following Haskell program shows a proof-of-concept implementation derived directly from 'System.Timeout.timeout' together with a Criterion benchmark comparing the performance between the original and the alternative 'timeout' function wrapping a 'readMVar' call. On a i7-3770 with GHC-7.6.2/Linux/64bit ran with "+RTS -A4m -N4", the benchmark shows a 15x improvement for the new implementation (below 1 uS) compared to the original implementation (~13 uS): ,---- | benchmarking id | mean: 22.60933 ns, lb 22.50331 ns, ub 22.73515 ns, ci 0.950 | std dev: 591.0383 ps, lb 509.6189 ps, ub 663.2670 ps, ci 0.950 | found 17 outliers among 100 samples (17.0%) | 17 (17.0%) high mild | variance introduced by outliers: 19.992% | variance is moderately inflated by outliers | | benchmarking timeout_1ms | mean: 13.79584 us, lb 13.62939 us, ub 13.92814 us, ci 0.950 | std dev: 756.3080 ns, lb 524.7628 ns, ub 1.068547 us, ci 0.950 | found 14 outliers among 100 samples (14.0%) | 4 (4.0%) low severe | 5 (5.0%) high mild | 5 (5.0%) high severe | variance introduced by outliers: 52.484% | variance is severely inflated by outliers | | benchmarking timeout2_1ms | mean: 879.8152 ns, lb 874.5223 ns, ub 885.9759 ns, ci 0.950 | std dev: 29.31963 ns, lb 25.65941 ns, ub 32.98116 ns, ci 0.950 | found 9 outliers among 100 samples (9.0%) | 9 (9.0%) high mild | variance introduced by outliers: 28.734% | variance is moderately inflated by outliers | ... `---- Alas there's a race-condition hidden somewhere I'm struggling with; When the timeout is set low enough, the internal 'Timeout2' exceptions leaks outside the 'timeout2' wrapper: ,---- | ... | benchmarking timeout2_10us | newtimeout: <<timeout2>> `---- I've tried rewriting the code but couldn't figure out a way to keep the exception from escaping 'timeout2'. Does the race-condition actually lie in the 'timeout2' implementation -- and if so, is it possible to rewrite 'timeout2' to solve it? [1]: http://hackage.haskell.org/packages/archive/base/latest/doc/html/System-Tim… cheers, hvr

5 7

Re: Race-condition in alternative 'System.Timeout.timeout' implementation
by Akio Takano 25 Feb '13

25 Feb '13

I accidentally replied to Herbert privately. I'm forwarding the message to the list. - Takano Akio ---------- Forwarded message ---------- From: Akio Takano <tkn.akio(a)gmail.com> Date: Mon, Feb 25, 2013 at 6:15 PM Subject: Re: Race-condition in alternative 'System.Timeout.timeout' implementation To: Herbert Valerio Riedel <hvr(a)gnu.org> Hi, I think the problem is that E.unregisterTimeout doesn't guarantee that no timeout will be delivered after it returns. This allows an execution sequence like: 0. Thread A calls timeout2 1. Thread A registers a callback to the event manager 2. Thread A unregisters the callback 3. Thread A exits from the handleJust 4. The callback is triggered, killing thread A If I understand correctly this can be worked around with an extra mutex in timeout2. I'll attach my implementation. It's called timeout3 and is a bit slower than timeout2, but I haven't seen a leaking exception with it. On Mon, Feb 25, 2013 at 7:31 AM, Herbert Valerio Riedel <hvr(a)gnu.org> wrote: > Hello *, > > I've been experimenting with an alternative implementation of > 'System.Timeout.timeout'[1] which avoids the overhead of spawning a new > thread for each invocation. > > Part of my motivation is to see if I can implement a faster version of > > threadWaitReadTimeout :: Int -> Fd -> IO Bool > threadWaitReadTimeout to = liftM (maybe False (const True)) > . timeout to . threadWaitRead > > and thus exploit GHC's event notification system instead of having to > reimplement a timeout-manager myself (like popular HTTP server libraries > such as Snap or Warp do currently). > > > The following Haskell program shows a proof-of-concept implementation > derived directly from 'System.Timeout.timeout' together with a Criterion > benchmark comparing the performance between the original and the > alternative 'timeout' function wrapping a 'readMVar' call. > > > > On a i7-3770 with GHC-7.6.2/Linux/64bit ran with "+RTS -A4m -N4", the > benchmark shows a 15x improvement for the new implementation (below 1 > uS) compared to the original implementation (~13 uS): > > ,---- > | benchmarking id > | mean: 22.60933 ns, lb 22.50331 ns, ub 22.73515 ns, ci 0.950 > | std dev: 591.0383 ps, lb 509.6189 ps, ub 663.2670 ps, ci 0.950 > | found 17 outliers among 100 samples (17.0%) > | 17 (17.0%) high mild > | variance introduced by outliers: 19.992% > | variance is moderately inflated by outliers > | > | benchmarking timeout_1ms > | mean: 13.79584 us, lb 13.62939 us, ub 13.92814 us, ci 0.950 > | std dev: 756.3080 ns, lb 524.7628 ns, ub 1.068547 us, ci 0.950 > | found 14 outliers among 100 samples (14.0%) > | 4 (4.0%) low severe > | 5 (5.0%) high mild > | 5 (5.0%) high severe > | variance introduced by outliers: 52.484% > | variance is severely inflated by outliers > | > | benchmarking timeout2_1ms > | mean: 879.8152 ns, lb 874.5223 ns, ub 885.9759 ns, ci 0.950 > | std dev: 29.31963 ns, lb 25.65941 ns, ub 32.98116 ns, ci 0.950 > | found 9 outliers among 100 samples (9.0%) > | 9 (9.0%) high mild > | variance introduced by outliers: 28.734% > | variance is moderately inflated by outliers > | ... > `---- > > Alas there's a race-condition hidden somewhere I'm struggling with; When > the timeout is set low enough, the internal 'Timeout2' exceptions leaks > outside the 'timeout2' wrapper: > > ,---- > | ... > | benchmarking timeout2_10us > | newtimeout: <<timeout2>> > `---- > > I've tried rewriting the code but couldn't figure out a way to keep the > exception from escaping 'timeout2'. Does the race-condition actually lie > in the 'timeout2' implementation -- and if so, is it possible to rewrite > 'timeout2' to solve it? > > > [1]: http://hackage.haskell.org/packages/archive/base/latest/doc/html/System-Tim… > > cheers, > hvr > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

1 0

online docs for GHC head seem to be stale
by Carter Schonwald 24 Feb '13

24 Feb '13

Hey All, I've been looking around in the documentation online for the current ghc head, and it looks to lack any information on the new SIMD ops. then i noticed the time stamp: http://www.haskell.org/ghc/dist/current/docs/html/libraries/ so those docs are from December? Whats needed to be done to bring those to be more up to date?

1 0

Quasi quoting and global names (for haskell-src-exts-qq)
by L Corbijn 18 Feb '13

18 Feb '13

Hello, In the haskell-src-exts quasi quoter there is some code to convert all names in `dataToQa` to global names. The reasoning is according to the source: -- | The generic functions in 'Language.Haskell.TH.Quote' don't use global -- names for syntax constructors. This has the unfortunate effect of breaking -- quotation when the haskell-src-exts syntax module is imported qualified. -- The solution is to set the flavour of all names to 'NameG'. qualify :: Name -> Name -- Need special cases for constructors used in string literals. Assume nearly -- all else is a datatype defined in Syntax module of haskell-src-exts. qualify n | ":" <- nameBase n = '(:) {- snip: quite some excluded constructors -} | otherwise = Name (mkOccName (nameBase n)) flavour {- snip: some code for the flavour -} For the full source code see [1]. When fixing the pattern quasi quoter this qualification caused a long error (when using the quasi quoter). So in a simple attempt to fix it I replaced `qualify` with `id` and it all worked. Now assuming that the qualification code was needed for some past version of GHC I would like to make the implementation dependent on the version of GHC. The only problem is that I haven't found the right version of GHC where this behaviour changed. Does somebody know at what version it was needed? Greetings, Lars Corbijn [1] http://hackage.haskell.org/package/haskell-src-exts-qq-0.6.1

2 1

Building the GHC library without building GHC
by C Rodrigues 15 Feb '13

15 Feb '13

Hi, I was going to do some hacking on Haddock. Haddock depends on the GHC API from the development version of GHC, however, stage2 crashes on my system when I try to build the newest GHC from the repository. Since I don't actually need to compile with the new GHC, I'm hoping there's a workaround. Is there a way to build only the GHC library so that I can get back to Haddock?

2 1

How to compile ghc 7.6.2 with llvm?
by Magicloud Magiclouds 12 Feb '13

12 Feb '13

Hi, I am using Linuxmint Nadia with clang and llvm-3.0 installed. Then I `mv build.mk.sample build.mk`, set "BuildFlavour = perf-llvm", add "GhcWithLlvmCodeGen = YES". Finally `./configure --with-gcc=/usr/bin/llvm-gcc`. Configure output attached. After make, I tried `inplace/bin/ghc-stage2 –info`, it is still using native code generator. What should I do? config.log<https://docs.google.com/file/d/0BzTVWOyY2ZO4SXRqdnUzdE5WREk/edit> -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

3 6

I cannot compile ghc-7.6.2
by Magicloud Magiclouds 12 Feb '13

12 Feb '13

Hi, Linuxmint Nadia, ghc-7.6.1 was built and running OK. Just downloaded ghc-7.6.2, without changing anything and environment, and boot and configure returned OK, I got these. What happened? 20130210Sun183147magicloud(a)ctu-9986008283~/s/ghc-7.6.2 $ make + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old touch -r mk/config.mk.old mk/config.mk + test -f mk/project.mk.old + cp -p mk/project.mk mk/project.mk.old touch -r mk/project.mk.old mk/project.mk + test -f compiler/ghc.cabal.old + cp -p compiler/ghc.cabal compiler/ghc.cabal.old touch -r compiler/ghc.cabal.old compiler/ghc.cabal ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No such file or directory libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/ package-data.mk: No such file or directory libraries/binary/ghc.mk:3: libraries/binary/dist-boot/package-data.mk: No such file or directory libraries/bin-package-db/ghc.mk:3: libraries/bin-package-db/dist-boot/ package-data.mk: No such file or directory libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/package-data.mk: No such file or directory compiler/ghc.mk:450: compiler/stage1/package-data.mk: No such file or directory utils/hsc2hs/ghc.mk:14: utils/hsc2hs/dist/package-data.mk: No such file or directory ghc/ghc.mk:106: ghc/stage1/package-data.mk: No such file or directory mkdir inplace mkdir inplace/bin "rm" -f utils/ghc-pkg/Version.hs mkdir inplace/lib echo "module Version where" >> utils/ghc-pkg/Version.hs "rm" -f inplace/bin/mkdirhier echo "version, targetOS, targetARCH :: String" >> utils/ghc-pkg/Version.hs echo "version = \"7.6.2\"" >> utils/ghc-pkg/Version.hs echo '#!/bin/sh' >> inplace/bin/mkdirhier echo "targetOS = \"linux\"" >> utils/ghc-pkg/Version.hs cat utils/mkdirhier/mkdirhier.sh >> inplace/bin/mkdirhier echo "targetARCH = \"x86_64\"" >> utils/ghc-pkg/Version.hs chmod +x inplace/bin/mkdirhier "inplace/bin/mkdirhier" utils/ghc-cabal/dist/build/tmp//. "inplace/bin/mkdirhier" bootstrapping/. "inplace/bin/mkdirhier" inplace/bin//. "inplace/bin/mkdirhier" compiler/stage1/build//. "inplace/bin/mkdirhier" utils/ghc-pkg/dist/build/tmp//. "inplace/bin/mkdirhier" inplace/lib/package.conf.d/. "/usr/local/bin/ghc" -H32m -O --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \ -no-user-package-db \ -Wall \ -DCABAL_VERSION=1,16,0 \ -odir bootstrapping \ -hidir bootstrapping \ -ilibraries/Cabal/Cabal \ -ilibraries/filepath \ -ilibraries/hpc \ "rm" -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... done. libraries/Cabal/Cabal/Distribution/ParseUtils.hs:88:18: Could not find module `Data.Map' It is a member of the hidden package `containers-0.5.0.0'. Use -v to see a list of the files searched for. make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2 -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

2 2

RE: GHC 7.8 release?
by Simon Peyton-Jones 10 Feb '13

10 Feb '13

It’s fairly simple in my mind. There are two “channels” (if I understand Mark’s terminology right): · Haskell Platform: o A stable development environment, lots of libraries known to work o Newcomers, and people who value stability, should use the Haskell Platform o HP comes with a particular version of GHC, probably not the hottest new one, but that doesn’t matter. It works. · GHC home page downloads: o More features but not so stable o Libraries not guaranteed to work o Worth releasing, though, as a forcing function to fix bugs, and as a checkpoint for people to test, so that by the time the HP adopts a particular version it is reasonably solid. So we already have the two channels Mark asks for, don’t we? One is called the Haskell Platform and one is called the GHC home page. That leaves a PR issue: we really don’t want newcomers or Joe Users wanting the “new shiny”. They want the Haskell Platform, and as Mark says those users should not pay the slightest attention until it appears in the Haskell Platform. So perhaps we principally need a way to point people away from GHC and towards HP? eg We could prominently say at every download point “Stop! Are you sure you want this? You might be better off with the Haskell Platform! Here’s why...”. Have I understood aright? If so, how could we achieve the right social dynamics? Our goal is to let people who value stability get stability, while the hot-shots race along in a different channel and pay the price of flat tires etc. PS: absolutely right to use 7.6.2 for the next HP. Don’t even think about 7.8. Simon From: Mark Lentczner [mailto:mark.lentczner@gmail.com] Sent: 07 February 2013 17:43 To: Simon Peyton-Jones Cc: andreas.voellmy(a)gmail.com; Carter Schonwald; GHC users; Simon Marlow; parallel-haskell; kostirya(a)gmail.com; Edsko de Vries; ghc-devs(a)haskell.org Subject: Re: GHC 7.8 release? I'd say the window for 7.8 in the platform is about closed. If 7.8 were to be release in the next two weeks that would be just about the least amount of time I'd want to see for libraries in the platform to get all stable with the GHC version. And we'd also be counting on the GHC team to be quickly responding to bugs so that there could be a point release of 7.8 mid-April. Historically, none of that seems likely. So my current trajectory is to base HP 2013.2.0.0 on GHC 7.6.2. Since 7.8 will seems like it will be released before May, we will be faced again with the bad public relations issue: Everyone will want the new shiny and be confused as to why the platform is such a laggard. We'll see four reactions: * New comers who are starting out and figure they should use the latest... Many will try to use 7.8, half the libraries on hackage won't work, things will be wonky, and they'll have a poor experience. * People doing production / project work will stay on 7.6 and ignore 7.8 for a few months. * The small group of people exploring the frontiers will know how to get things set up and be happy. * Eventually library authors will get around to making sure their stuff will work with it. I wish GHC would radically change it's release process. Things like 7.8 shouldn't be release as "7.8". That sounds major and stable. The web site will have 7.8 at the top. The warning to use the platform will fall flat because it makes the platform look out of date. Really, "7.8" should be in a different release channel, not on the front page. It should bake in that channel for six months - where only the third group of people will use it, until it is getting close to merge into main, at which point the fourth group will start to use it, so that the day it hits main, all the libraries just work. Ideally, the first two groups of people will not pay the slightest attention to it until it is further baked. While we achievements of the GHC team are great, less than half of those 7.8 features seem interesting from the viewpoint of the aims of the platform. I don't think adding syntactic or type-level features are really all that important for Haskell at this juncture. And while I do like to see improvements in generated code and run-time performance, I think even those are less important than making crucial ecosystem improvements to things like package management, cross-compilation, and libraries. - Mark

15 25