October 2013 - ghc-devs

Re: small improvement to roles mechanism
by Joachim Breitner 12 Oct '13

12 Oct '13

Hi, Am Freitag, den 11.10.2013, 22:19 -0400 schrieb Richard Eisenberg: > 2. Like #1, but disallow Coercible. This way, the abstraction problem > is no worse than it was before. (Apologies to Joachim if he minds this > suggestion.) I don’t mind it; after all I was reluctant to put Coercible in 7.8 in the first place. OTOH, Coercible is like GND: A feature that is more type-safe with Roles than without, but it could live on its own. So if we do disable role-checking in 7.8, we could still leave Coercible in as a tech preview, with a clear statement in the docs saying “this is currently an unsafe feature (like unsafeCoerce)”. I would be nice if adventurous people can play with it. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

1 0

Re: GHC HEAD vs Hackage, panic-free edition
by Herbert Valerio Riedel 12 Oct '13

12 Oct '13

Hello Bryan, On 2013-10-11 at 20:27:08 +0200, Bryan O'Sullivan wrote: [...] > For packages that are listed in blue, the versions that are breaking are > the latest available. I've CCed the authors of said packages on this email. > Folks, please fix your stuff! btw, is there somewhere some wiki-page/gist/whatever where howto/cookbook-like information is being collected on how to make packages compatible with the new environment (possibly maximizing the compatibility version range)? >From jwlato at gmail.com Mon Oct 7 06:53:36 2013 From: jwlato at gmail.com (John Lato) Date: Mon, 7 Oct 2013 01:53:36 -0500 Subject: Proposal: GHC.Generics marked UNSAFE for SafeHaskell In-Reply-To: <CALjd_v6YDiWwx-C29HHziS-nLmnvLoAgU4HwSKsq0dwc=XV_qA(a)mail.gmail.com> References: <CACYs5AbGakPTh7jdka9q8+Vw896d=KwWHEVyKddRRaiuEVdWTA(a)mail.gmail.com> <5251E425.8060900(a)earth.li> <CACYs5Ab7vjF6-8-yK9EXMdj1ONPbV=T5_G9u_MZ+R+uZ-t8cvg(a)mail.gmail.com> <CAJ727Gi+d0m2_8XnV5w9RdPkr_4MQj6avze17ekqM2Ehg4FkTg(a)mail.gmail.com> <CAHYVw0z+Dn7Y+1En2FsAHfG79DsZsRNd1G9Z-o5K-i7TtV4Lwg(a)mail.gmail.com> <CAHYVw0zoeWyjPNNkTL-ZoORXnFRrbGGSE5sKjWJeyQ=SRSY7OA(a)mail.gmail.com> <CAJ727GiCe3Sf0k8iXS6QOzBZh2Wp3cczYMDUXaTaMydMv_1z3Q(a)mail.gmail.com> <CAJ727Gi9EL0qDcZO=WezM8H=C-EbeHUKp2jUh=Fjn_5_8-x1rQ(a)mail.gmail.com> <CALjd_v6YDiWwx-C29HHziS-nLmnvLoAgU4HwSKsq0dwc=XV_qA(a)mail.gmail.com> Message-ID: <CAJ727Ggi1P0=mwCw1YALYkS61H06i_qhhSAcO=TJjS4Eq02Jmg(a)mail.gmail.com> X-List-Received-Date: Sat, 12 Oct 2013 07:41:33 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:33 -0000 Andres is right that it's not as evil as defining your own Typeable. The crux of the matter is that Generic essentially allows full access to the data type. Unfortunately it's easy to forget this... On Mon, Oct 7, 2013 at 1:43 AM, Andres L?h <andres at well-typed.com> wrote: > While I understand you all feel uncomfortable with this, I do not > think the problem demonstrated by John has anything to do with > Generic. > > I've made a fork here > > https://github.com/kosmikus/safe-bugtest > > that shows an (IMHO) similar problem using Show and Read instead of > Generic. (And something slightly different could certainly also > produced using Enum). > > If you're deriving Generic, then yes, you gain the functionality of > that class, which is to inspect the structure of the type, and then > yes, you can in principle construct any value of that type. So > deriving Generic for types that should be abstract is always going to > be risky. But this is no different than deriving any other class, only > that Generic gives you particularly fine-grained access to the > internals of a type. > > Also, at least in my opinion, it is entirely valid to define your own > Generic instances. It's more work, and while I haven't used it often > so far, I can imagine that there are good use cases. I don't think > it's anywhere near as evil as defining your own Typeable instances. > > Cheers, > Andres > > -- > Andres L?h, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com >

1 0

Re: Unicode quotes
by Gabor Greif 12 Oct '13

12 Oct '13

> On 9/4/13, Kazu Yamamoto <kazu(a)iij.ad.jp> wrote: >> Hello, >> >> GHCi of GHC 7.7 use Unicode quote marks instead of ASCII quote marks. >> Why do you guys decide this behavior change? I'm just curious. > > Maybe because kind promotion causes some types to be written with > a leading apostrophe? I do not really know it, but I've seen those > unicode characters being swallowed on my console until I set > LC_ALL to en_US. > > Cheers, > > Gabor > >> >> --Kazu >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >>

1 0

small improvement to roles mechanism
by Richard Eisenberg 10 Oct '13

10 Oct '13

In Bryan's recent test of GHC 7.8 against all of Hackage, there were three spurious errors caused by lack of role abstraction. Here are the class definitions where a nominal parameter is inferred, probably against the wishes of the author: from logict-0.2.3/Control.Monad.Logic.Class: > class (MonadPlus m) => MonadLogic m where > msplit :: m a -> m (Maybe (a, m a)) from monadLib-3.5.2/MonadLib: > class (Monad m) => ReaderM m i | m -> i where > ask :: m i from base/Control.Arrow: > class Arrow a => ArrowApply a where > app :: a (a b c, b) c In each of these, the last parameter of the class is given a nominal role because it appears as the parameter of a type variable. However, in each case, it appears as the parameter of a *class* type variable. This means that, if we somehow knew that the class author wanted the class to be usable with GND, we could simply check every instance declaration for that class to make sure that the relevant concrete instantiation has the right role. For example, when the user writes, for example > instance ArrowApply Foo where � we check that Foo's first parameter has a representational role. If it doesn't, then the instance is rejected. An alternative, somewhat heavier idea would be to represent roles as class constraints. We could have > class NextParamNominal (c :: k) > class NextParamRepresentational (c :: k) GHC could "generate" instances for every datatype definition. For example: > type role Map nominal representational > data Map k v = � would induce > instance NextParamNominal Map > instance NextParamRepresentational (Map k) Users would not be able to write these instances -- they would have to be generated by GHC. (Alternatively, there could be no instances, just a little magic in the constraint solver. Somewhat like Coercible.) Then, the classes above would just have to add a superclass, like this: > class (Arrow a, NextParamRepresentational a) => ArrowApply a where > app :: a (a b c, b) c The role inference mechanism would be made aware of role constraints and use this one to derive that ArrowApply is OK for GND. This "heavier" approach has a similar upshot to the first idea of just checking at instance declarations, but it is more customizable and transparent to users (I think). I'm not sure I'm advocating for this change (or volunteering to implement before the release candidate), but I wanted to document the idea and get any feedback that is out there. This would fix the breakage we've seen without totally changing the kind system. Thanks, Richard PS: Due credit is to migmit for suggesting the type-class idea on glasgow-haskell-users. >From johan.tibell at gmail.com Tue Oct 1 04:50:48 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 30 Sep 2013 21:50:48 -0700 Subject: Is evacuate for StgMutArrPtrs and StgArrPtrs expensive to GC? Message-ID: <CAK-tuPYGON7euX-=OQizyuMk5aq_tPM8X4CfhecFu7Jh86Ba0w(a)mail.gmail.com> X-List-Received-Date: Sat, 12 Oct 2013 07:41:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:27 -0000 Hi, When I benchmark Data.HashMap.insert from unordered-containers (inserting the keys [0..10000]) the runtime is dominated by GC: $ cat Test.hs module Main where import Control.DeepSeq import Control.Exception import Control.Monad import qualified Data.HashMap.Strict as HM import Data.List (foldl') main = do let ks = [0..10000] :: [Int] evaluate (rnf ks) forM_ ([0..1000] :: [Int]) $ \ x -> do evaluate $ HM.null $ foldl' (\ m k -> HM.insert k x m) HM.empty ks $ perf record -g ./Test +RTS -s 6,187,678,112 bytes allocated in the heap 3,309,887,128 bytes copied during GC 1,299,200 bytes maximum residency (1002 sample(s)) 118,816 bytes maximum slop 5 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 11089 colls, 0 par 1.31s 1.30s 0.0001s 0.0005s Gen 1 1002 colls, 0 par 0.49s 0.51s 0.0005s 0.0022s INIT time 0.00s ( 0.00s elapsed) MUT time 1.02s ( 1.03s elapsed) GC time 1.80s ( 1.80s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 2.82s ( 2.84s elapsed) %GC time 63.7% (63.5% elapsed) Alloc rate 6,042,264,963 bytes per MUT second Productivity 36.3% of total user, 36.1% of total elapsed $ perf report 41.46% Test Test [.] evacuate 15.47% Test Test [.] scavenge_block 11.04% Test Test [.] s3cN_info 8.74% Test Test [.] s3aZ_info 3.59% Test Test [.] 0x7ff5 2.83% Test Test [.] scavenge_mut_arr_ptrs 2.69% Test libc-2.15.so [.] 0x147fd9 2.51% Test Test [.] allocate 2.00% Test Test [.] s3oo_info 0.91% Test Test [.] todo_block_full 0.87% Test Test [.] hs_popcnt64 0.80% Test Test [.] s3en_info 0.62% Test Test [.] s3el_info Is GC:ing StgMutArrPtrs and StgArrPtrs, which I create a lot of, more expensive than GC:ing normal heap objects (i.e. for standard data types)? -- Johan >From johan.tibell at gmail.com Tue Oct 1 05:43:01 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 30 Sep 2013 22:43:01 -0700 Subject: Is evacuate for StgMutArrPtrs and StgArrPtrs expensive to GC? In-Reply-To: <CAK-tuPYGON7euX-=OQizyuMk5aq_tPM8X4CfhecFu7Jh86Ba0w(a)mail.gmail.com> References: <CAK-tuPYGON7euX-=OQizyuMk5aq_tPM8X4CfhecFu7Jh86Ba0w(a)mail.gmail.com> Message-ID: <CAK-tuPYw60eGAW6C6hog3ot8faKZ1f8jfW2vofNhC9UqVYQ6CA(a)mail.gmail.com> X-List-Received-Date: Sat, 12 Oct 2013 07:41:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:27 -0000 The code for 'allocate' in rts/sm/Storage.c doesn't seem that expensive. An extra branch compared to inline allocation and allocation is done in the next nursery block (risking fragmentation?). -- Johan On Mon, Sep 30, 2013 at 9:50 PM, Johan Tibell <johan.tibell at gmail.com> wrote: > Hi, > > When I benchmark Data.HashMap.insert from unordered-containers > (inserting the keys [0..10000]) the runtime is dominated by GC: > > $ cat Test.hs > module Main where > > import Control.DeepSeq > import Control.Exception > import Control.Monad > import qualified Data.HashMap.Strict as HM > import Data.List (foldl') > > main = do > let ks = [0..10000] :: [Int] > evaluate (rnf ks) > forM_ ([0..1000] :: [Int]) $ \ x -> do > evaluate $ HM.null $ foldl' (\ m k -> HM.insert k x m) HM.empty ks > > $ perf record -g ./Test +RTS -s > 6,187,678,112 bytes allocated in the heap > 3,309,887,128 bytes copied during GC > 1,299,200 bytes maximum residency (1002 sample(s)) > 118,816 bytes maximum slop > 5 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max pause > Gen 0 11089 colls, 0 par 1.31s 1.30s 0.0001s 0.0005s > Gen 1 1002 colls, 0 par 0.49s 0.51s 0.0005s 0.0022s > > INIT time 0.00s ( 0.00s elapsed) > MUT time 1.02s ( 1.03s elapsed) > GC time 1.80s ( 1.80s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 2.82s ( 2.84s elapsed) > > %GC time 63.7% (63.5% elapsed) > > Alloc rate 6,042,264,963 bytes per MUT second > > Productivity 36.3% of total user, 36.1% of total elapsed > > $ perf report > 41.46% Test Test [.] evacuate > 15.47% Test Test [.] scavenge_block > 11.04% Test Test [.] s3cN_info > 8.74% Test Test [.] s3aZ_info > 3.59% Test Test [.] 0x7ff5 > 2.83% Test Test [.] scavenge_mut_arr_ptrs > 2.69% Test libc-2.15.so [.] 0x147fd9 > 2.51% Test Test [.] allocate > 2.00% Test Test [.] s3oo_info > 0.91% Test Test [.] todo_block_full > 0.87% Test Test [.] hs_popcnt64 > 0.80% Test Test [.] s3en_info > 0.62% Test Test [.] s3el_info > > Is GC:ing StgMutArrPtrs and StgArrPtrs, which I create a lot of, more > expensive than GC:ing normal heap objects (i.e. for standard data > types)? > > -- Johan >From simonpj at microsoft.com Tue Oct 1 08:10:29 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue, 1 Oct 2013 08:10:29 +0000 Subject: FW: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell In-Reply-To: <CA+=y3OoAVfXXkCXez+8TNYWwg51bLKNqnSsipQ5DAmEhVaegFg(a)mail.gmail.com> References: <CAD6SzRKj7yJSr91eAi=J0O7AHiTdAFbX+qqjVP=y6xu+grv1+g(a)mail.gmail.com> <CA+=y3OoAVfXXkCXez+8TNYWwg51bLKNqnSsipQ5DAmEhVaegFg(a)mail.gmail.com> Message-ID: <59543203684B2244980D7E4057D5FBC1485F5C18(a)DB3EX14MBXC306.europe.corp.microsoft.com> X-List-Received-Date: Sat, 12 Oct 2013 07:41:27 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:41:27 -0000 Dear GHC devs See below (in red). I do not know the details of this, but it sounds like a pretty serious problem, and it used to work. Is whatever-it-is confirmed fixed in 7.8? Do we have a test that'll trip if it breaks again? (I'm guessing that the latter might be hard.) Thanks Simon -----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Paul Liu Sent: 30 September 2013 07:18 To: Conal Elliott Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib is IMHO the lack of a light-weight, cross-platform, and full-featured font rendering solution. I believe many other libraries (including Diagram) are having the same problem. On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott <conal at conal.net<mailto:conal at conal.net>> wrote: > I'm polling to see whether there are will and expertise to reboot graphics > and GUIs work in Haskell. I miss working on functional graphics and GUIs in > Haskell, as I've been blocked for several years (eight?) due to the absence > of low-level foundation libraries having the following properties: > > * cross-platform, > * easily buildable, > * GHCi-friendly, and > * OpenGL-compatible. > > The last several times I tried Gtk2hs, I was unable to compile it on my Mac. > Years ago when I was able to compile, the GUIs looked and interacted like a > Linux app, which made them awkward and upleasant to use. wxHaskell (whose > API and visual appearance I prefered) has for years been incompatible with > GHCi, in that the second time I open a top-level window, the host process > (GHCi) dies abruptly. Since my GUI & graphics programs are often one-liners, > and I tend to experiment a lot, using a full compilation greatly thwarts my > flow. For many years, I've thought that the situation would eventually > improve, since I'm far from the only person who wants GUIs or graphics from > Haskell. > > About three years ago, I built a modern replacement of my old Pan and > Vertigo systems (optimized high-level functional graphics in 2D and 3D), > generating screamingly fast GPU rendering code. I'd love to share it with > the community, but I'm unable to use it even myself. > > Two questions: > > * Am I mistaken about the current status? I.e., is there a solution for > Haskell GUI & graphics programming that satisfies the properties I'm looking > for (cross-platform, easily buildable, GHCi-friendly, and > OpenGL-compatible)? > * Are there people willing and able to fix this situation? My own > contributions would be to test and to share high-level composable and > efficient GUI and graphics libraries on top of a working foundation. > > Looking forward to replies. Thanks, > > -- Conal > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org<mailto:Haskell-Cafe at haskell.org> > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Regards, Paul Liu _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org<mailto:Haskell-Cafe at haskell.org> http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

HEAD vs Hackage status report
by Bryan O'Sullivan 10 Oct '13

10 Oct '13

I spent a little time the other day building all of Hackage with GHC HEAD. Here's a quick writeup of what I found. Total packages: 5564 Succeeded with 7.6.3: 3234 Succeeded with HEAD: 2061 Succeeded with 7.6.3 *but failed with HEAD: 1186* (A few dozen packages built with HEAD, but not with 7.6.3, which is why the numbers don't add up.) I think the condensed version of the story is that we're actually in good shape, the above numbers notwithstanding. There are only a few categories of build regression, which I detail below. Except for one genuine bug, the rest (at least those I've seen so far) are upgrade details that could be written about in release notes or a blog post. There currently exists just one panic-related bug, which prevents all 23 packages in the Snap web framework from building: ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130923 for x86_64-unknown-linux): dmdTransformDictSelSig: split failed<http://ghc.haskell.org/trac/ghc/ticket/8329> Of the 1186 packages that build with 7.6.3 but not HEAD: 311 fail due to cabal being unable to solve dependency constraints. As usual, most (195) have excessively tight constraints on base. 37 packages fail due to GeneralizedNewtypeDeriving and the new role infrastructure, due to the following failures in packages upon which they depend. 12 language-c-0.4.2 the last parameter of ‛Error’ is at role Nominal 11 logfloat-0.12.1 the last parameter of ‛IArray’ is at role Nominal 5 diagrams-lib-0.7.1.1 the last parameter of ‛Transformable’ is at role Nominal 4 smallcheck-1.0.4 the last parameter of ‛MonadLogic’ is at role Nominal 2 monadiccp-0.7.6 the last parameter of ‛ReaderM’ is at role Nominal 2 histogram-fill-0.8.1.0 the last parameter of ‛BinEq’ is at role Nominal 1 acme-schoenfinkel-0.1.1 the last parameter of ‛ArrowApply’ is at role Nominal There's quite a bit of transitive primop-related breakage. 364 template-haskell-2.8.0.0 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 48 primitive-0.4.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 6 primitive-0.5.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ Most of the breakage could be fixed by loosening the dependencies on the template-haskell and primitive packages, and here are the rest. 63 uulib-0.9.15 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 20 utf8-light-0.4.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 19 safeint-0.5.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 16 permutation-0.4.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 9 floatshow-0.2.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 9 bytestring-show-0.3.5.5 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 8 STMonadTrans-0.3.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 7 hashtables-1.1.0.2 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 2 word24-1.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 2 arithmoi-0.4.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 1 word8-0.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 1 IORefCAS-0.2.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ Roughly 45 packages are broken by changes to Typeable.

7 8

Testsuite fails at the first fence on Windows
by Simon Peyton-Jones 10 Oct '13

10 Oct '13

Dear GHC-dev friends Does anyone feel able help me with this (below)? I'm a bit clueless, and I really think we should have a working Windows build going! It would be so great to have someone who could give the Windows build some love. But meanwhile, just extricating me from my helpless puddle would be terrific. Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Simon Peyton-Jones Sent: 02 October 2013 20:40 To: Kyra Alex Cc: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: RE: Make spins with THREADS>1 on Win 7 Summary: progress on Windows builds, but a show-stopper below that I'm sure some ghc-dev can help with. Ah, I've forgotten to mention that the environment variable MSYSTEM must be set to MINGW before starting the shell Oh, this is much better. * The download from msys2 already includes o python o git o perl o make o autoconf o ssh which saves a bunch of secondary installation goop. * Once I set MSYSYSTEM=MINGW, things went much much better. GHC built to completion. * make -j works fine! * A bizarre 10-second delay when starting a shell has gone away So I am very happy. Two things I'm stuck on. In testsuite I get this: testsuite (master)$ make make -C ./tests all make[1]: Entering directory '/cygdrive/c/code/HEAD/testsuite/tests' python2 ../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts '" -e ghc_debugged=False -e ghc_with_native_codegen=1 -e ghc_with_vanilla=1 -e ghc_with_dynamic=0 -e ghc_with_profiling=0 -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e ghc_with_interpreter=1 -e ghc_unregisterised=0 -e ghc_dynamic_by_default=False -e ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e in_tree_compiler=True -e clean_only=False --rootdir=. --config=../config/ghc -e 'config.confdir="../config"' -e 'config.compiler="C:/code/HEAD/inplace/bin/ghc-stage2.exe"' -e 'config.ghc_pkg="C:/code/HEAD/inplace/bin/ghc-pkg.exe"' -e 'config.hp2ps="C:/code/HEAD/inplace/bin/hp2ps.exe"' -e 'config.hpc="C:/code/HEAD/inplace/bin/hpc.exe"' -e 'config.gs="gs"' -e 'config.platform="i386-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="i386"' -e 'config.wordsize="32"' -e 'default_testopts.cleanup=""' -e 'config.timeout=int() or config.timeout' -e 'config.timeout_prog="../timeout/install-inplace/bin/timeout.exe"' -e 'config.exeext=".exe"' -e 'config.top="C:/code/HEAD/testsuite"' --rootdir=../../libraries/Win32/tests --rootdir=../../libraries/array/tests --rootdir=../../libraries/base/tests --rootdir=../../libraries/binary/tests --rootdir=../../libraries/bytestring/tests --rootdir=../../libraries/containers/tests --rootdir=../../libraries/directory/tests --rootdir=../../libraries/filepath/tests --rootdir=../../libraries/ghc-prim/tests --rootdir=../../libraries/haskeline/tests --rootdir=../../libraries/hpc/tests --rootdir=../../libraries/old-time/tests --rootdir=../../libraries/pretty/tests --rootdir=../../libraries/process/tests --rootdir=../../libraries/random/tests --rootdir=../../libraries/template-haskell/tests --rootdir=../../libraries/vector/tests Traceback (most recent call last): File "../driver/runtests.py", line 146, in <module> import ctypes File "/usr/lib/python2.7/ctypes/__init__.py", line 451, in <module> pythonapi = PyDLL("libpython%d.%d.dll" % _sys.version_info[:2]) File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__ self._handle = _dlopen(self._name, mode) OSError: No such file or directory ../mk/test.mk:238: recipe for target 'test' failed And indeed there is no "ctypes.py", although there is a directory ctypes in c:/fp/Python27/Lib/ctypes, which contains __init__.py __init__.pyc _endian.py _endian.pyc macholib test util.py wintypes.py But runtests.py says "import ctypes" and that's what is failing. I don't know how it worked before. Can anyone help? I'm so close! Less importantly, but annoyingly, every run of perl, even perl -versoin, gives this: perl --version perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "ENG" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). This is perl 5, version 18, subversion 1 (v5.18.1) built for msys-thread-multi-64int It's non-fatal, but annoying. Thanks Simon From: Kyra Alex [mailto:meurglys3@gmail.com] Sent: 02 October 2013 07:45 To: Simon Peyton-Jones Cc: Edsko de Vries; ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Make spins with THREADS>1 on Win 7 Ah, I've forgotten to mention that the environment variable MSYSTEM must be set to MINGW before starting the shell as is in mingw_shell.bat: set MSYSTEM=MINGW. msys2_shell.bat set it to MSYS thus making it answer "msys". On Wed, Oct 2, 2013 at 1:59 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: http://sourceforge.net/projects/msys2/ is *much* better than stock msys. I've successfully built ghc HEAD quite recently (a month ago or so) using it. Interesting! There appears to be about zero documentation, but I unpacked the tar ball (which has pre-built binaries), put it in c:/msys32, added c:/mys32/bin to my PATH, and tried. Starts well, but two problems. * I get lots of this (non-fatally): perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = "ENG" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). * But then I get this error which brings things to a halt: checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 7.7.20131001 checking for ghc... /cygdrive/c/fp/HP-2013.2.0.0/bin/ghc checking version of ghc... 7.6.3 GHC path canonicalised to: /cygdrive/c/fp/HP-2013.2.0.0/bin/ghc checking build system type... Invalid configuration `i686-pc-msys': system `msys' not recognized configure: error: /bin/sh ./config.sub i686-pc-msys failed Does anyone have ideas for fixing this? Kyra, how did you get past these? Simon From: Kyra Alex [mailto:meurglys3@gmail.com<mailto:meurglys3@gmail.com>] Sent: 01 October 2013 19:05 To: Simon Peyton-Jones Cc: Edsko de Vries; ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Make spins with THREADS>1 on Win 7 http://sourceforge.net/projects/msys2/ is *much* better than stock msys. I've successfully built ghc HEAD quite recently (a month ago or so) using it. On Tue, Oct 1, 2013 at 7:24 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Yes; it appears that in the current MSYS release, 'make -jn' goes into an infinite loop. This is very depressing. I do not know a fix. If you google around and find a fix, do tell us. Currently I have to use THREADS=1 all the time Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org<mailto:ghc-devs-bounces@haskell.org>] On Behalf Of Edsko | de Vries | Sent: 01 October 2013 16:21 | To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> | Subject: Make spins with THREADS>1 on Win 7 | | Hi all, | | Trying to get a build going on Win 7. On both the 32-bit and the | 64-bit version running 'sh validate' stalls at | | "inplace/bin/mkdirhier" utils/touchy/dist/build/tmp//. | | At this point nothing happens, other than that I seem to have 100% CPU | usage; 'ps' only shows two make processes, but no further | subprocesses. Not sure what's going on here. Running 'sh validate | --no-clean' after killing both make processes at this point stalls at | the same point; running it with THREADS=1 seems to resolve the issue. | | Anybody any idea what might be going on? | | Edsko | _______________________________________________ | ghc-devs mailing list | ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> | http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

2 2

GHC 7.8 Release Status & Schedule
by Austin Seipp 09 Oct '13

09 Oct '13

Friends, After talking with Simon yesterday, we have some idea of how the release will go. As I'm sure you're aware, the release is winding down rather quickly, and it will be a fantastic one hopefully :) Now that all the features have landed, we're going into bugfixing mode. The schedule is, roughly: - Nov 1st: Cut branch, and I plan on making a 7.8 RC1 available the same day, for several platforms. - Release will be ~3 weeks out from there, approximately Nov 25th. This gives us a month of solid bugfixing. During the 3 weeks with the 7.8 branch open, I'm a bit hesitant to land massive changes, so that our branches don't diverge too far. OTOH, a few things can probably land in this timeframe with minimal disturbances (such as the Applicative-Monad change.) If you want to land something in that time frame, please just ask me. On the whole, things actually feel pretty good - although there a few nasty bugs to sort out, the uptake in community involvement has simply been fantastic (definitely related to the number bugs we've found,) and I think we're on track to sort the remaining stuff out. A great thanks to all of the new people helping out! And if you want to help even more, please check out the tickets remaining for 7.8.1: http://ghc.haskell.org/trac/ghc/query?status=!closed&milestone=7.8.1&order=… If you think you can take on a bug, please assign it to yourself so we know what's going on. Note: if the bug isn't *high* or *highest*, it's unlikely to get looked at, at least by me! It won't be rejected if you submit a patch, but I'm simply not going to be able to get to it I'm afraid. So please grab something, and go for it! I am also reminded that the GHC October Status report will be due shortly - I'll take some time to write it up, and follow through here on the list (and glasgow-haskell-users) so interested parties can read up on what is happening. -- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 3

ghc.haskell.org updated to Trac 1.0.1
by Herbert Valerio Riedel 09 Oct '13

09 Oct '13

Hello *, The Trac instances at ghc.haskell.org have been upgraded to the current stable Trac 1.0.1 release in order to alleviate some technical issues with the aging Trac 0.12.x line. Ideally, you shouldn't notice any regressions; however, as a side-effect Trac 1.0.x has a slightly different look which takes a bit getting used to. I've tried to tweak the navigation sidebar to match the new design and integrate better with Trac's variable-height notification <div/>s. Should you notice anything that has been broken by the upgrade, please let me know! For those interested in what's new in Trac 1.0, here's a subjective selection of Trac 1.0 highlights: - Improved the handling of ticket edit conflicts, by showing simultaneous edits and conflicting changes, and making it easier to merge the changes - Ticket comments can now be displayed threaded - Simplified reverting of a wiki page to an older version - Added a user preference and a option to display relative/absolute datetime - Added //Comments only// filter in the Ticket Change History preferences, to hide field changes from the history and even exclude entries without a comment For more details see http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/1.0#DetailedUserVisibleC… Cheers, hvr

2 2

RE: [GHC] #7685: :script command does not resolve ~
by Simon Peyton-Jones 09 Oct '13

09 Oct '13

Should there be some documentation in the user manual? (Apols if there already.) Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 09 October 2013 09:36 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #7685: :script command does not resolve ~ | | #7685: :script command does not resolve ~ | -------------------------------------+---------------------------------- | -- | Reporter: nomeata | Owner: | Type: bug | Status: patch | Priority: normal | Milestone: 7.8.1 | Component: GHCi | Version: 7.6.2 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple | Type of failure: None/Unknown | Difficulty: Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | -------------------------------------+---------------------------------- | -- | | Comment (by Joachim Breitner <mail@…>): | | In [changeset:"ddc79b229d58c1bed8ae19b955b491436e015e96/ghc"]: | {{{ | #!CommitTicketReference repository="ghc" | revision="ddc79b229d58c1bed8ae19b955b491436e015e96" | GHCi: Expand ~ in :script command | | Fixes: #7685 | }}} | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7685#comment:4> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

2 1

status of ghc HEAD perf on mac
by Carter Schonwald 08 Oct '13

08 Oct '13

hey all, I just did a perf build of HEAD on my mac (with kazu's no haddocks flag) I did a fast run of the test suite: are all these failures known/being addressed? if you see one that isn't currently accounted for, PLEASE email me back so I can create a ticket for it. Unexpected results from: TEST="cgrun071 T5313 linker_unload cgrun057 static001 T1969 T3064 T4801 objc-hi objcpp-hi TH_spliceE5_prof" OVERALL SUMMARY for test run started at Tue Oct 8 15:37:22 2013 EDT 0:34:11 spent to go through 3799 total tests, which gave rise to 18281 test cases, of which 14821 were skipped 28 had missing libraries 3384 expected passes 34 expected failures 3 caused framework failures 2 unexpected passes 9 unexpected failures Unexpected passes: codeGen/should_run cgrun071 (normal) driver T5313 (normal) Unexpected failures: codeGen/should_run cgrun057 [bad stderr] (profasm) driver static001 [bad stderr] (normal) driver/objc objc-hi [exit code non-0] (normal) driver/objc objcpp-hi [exit code non-0] (normal) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T4801 [stat too good] (normal) rts linker_unload [bad exit code] (normal) th TH_spliceE5_prof [bad exit code] (normal)

2 1