- ghc-devs - Haskell.org

Wither Haskell Platform 2013.4.0.0
by Mark Lentczner 13 Oct '13

13 Oct '13

Friends — Deep apologies for being so out of touch the last two months(*). In theory, we should be rev'ing up to produce Haskell Platform 2013.4.0.0, but I'd like to explore our options at this time: *1) Proceed as normal:* Such a release would use GHC 7.6.3, as did HP 2013.2.0.0, since that is still the current GHC release. Hence all the core library versions would remain the same, and by my rough eyeballing it, half the platform libraries would remain the same. The only big change might be OpenGL/GLUT libs, which has bumped a major version... though I don't know if that API change is too great or not. Given the time frame, we are unlikely to have any additional packages. This stance brings up the issue that 7.6.3, out of the box, won't work with Xcode 5, and hence the upcoming release of OS X Mavericks (10.9). *2) Delay a month:* This would give us time to consider new packages, which would make the release somewhat more valuable. However, a December release is hard due to holidays, so likelihood would be late December, or January release. *3) Ask GHC Central to produce 7.6.4:* This would incorporate the changes needed work with Xcode 5. This would clearly involve a month delay as in #2. *4) Skip it:* We could just decide that 2013.4.0.0 doesn't offer enough value to run the process now, and simply focus our efforts this cycle on improving the infrastructure that builds HP. Thoughts? I'm particularly interested to hear from HP library maintainers to know if there was/is something important to get out in an HP ASAP. I'd also like to better understand what our Xcode5 options are, and if/how/when we could see the latest cabal in the platform. Again, sorry that this small HP timing crisis is mostly my fault, — Mark (*) At least my excuse is that I was writing music with Haskell for those two months!

4 4

Re: small improvement to roles mechanism
by Bryan O'Sullivan 12 Oct '13

12 Oct '13

On Fri, Oct 11, 2013 at 7:17 PM, Mark Lentczner <mark.lentczner(a)gmail.com>wrote: > Do I read Bryan's post correctly, that 20% of packages on hackage fail to > compile with GHC 7.8? > There are currently 5615 packages on Hackage. Of those, 3443 built successfully with 7.6.3 on my test machine yesterday, so let's call that the baseline. And of the 3443 that compile with 7.6.3, 1262 (37%) *fail* to compile with HEAD. You can find the complete list of regressing packages here: http://lpaste.net/94214

1 0

RE: small improvement to roles mechanism
by Simon Peyton-Jones 12 Oct '13

12 Oct '13

It's in the nature of type systems that as well as excluding bad programs they also exclude some good programs. So if we tighten up the type system (and GND allows seg-faults at the moment) that is certain to exclude some good programs. Would you like a flag to say "allow me to use GeneralisedNewtypeDeriving even if it is dangerous to do so"? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Johan Tibell Sent: 12 October 2013 00:15 To: Richard Eisenberg Cc: Stephanie Weirich; ghc-devs(a)haskell.org Devs Subject: Re: small improvement to roles mechanism Let me start by saying that I'm happy we're trying to fix the GND problem. Thanks for working on that. That being said: is this ready for mainstream consumption? We're forcing this on everyone without any language pragma or flags to opt-in/out. That is bad if we're not sure we're doing the right thing in some cases or if we're causing spurious failures. At ICFP I got the impression that very few people will be affected, but Bryan's result suggests there are more people than I thought. On Thu, Oct 10, 2013 at 8:26 PM, Richard Eisenberg <eir(a)cis.upenn.edu<mailto:eir@cis.upenn.edu>> wrote: 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. _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

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 11 Oct '13

11 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 11 Oct '13

11 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 10 Oct '13

10 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