From ben at smart-cactus.org Sun Mar 1 21:35:47 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Sun, 01 Mar 2015 16:35:47 -0500 Subject: Allowing rules to depend upon SimplCont Message-ID: <87oaoch03w.fsf@gmail.com> In Bug #9661, Comment #12 Simon Peyton-Jones wrote [1], > Annoyingly, the `CoreSyn.RuleFun` API for built-in rules does not give > access to the context of an application (the `SimplCont`), but it > would not be hard to make it do so. > > So if that is the right rewrite, then it'd be another useful project > for someone. I started taking a look at this over the weekend, hoping for a weekend-ish project. Unfortunately it's not as easy as it initially looked. The current state of my work can be found here [2]. The core of the change (as I understand it) is to add a `SimplCont` argument to `RuleFun` [3] although things are in actuality a bit more complicated While it was easy to pipe through the `SimplCont` in the simplifier itself (as it was already keeping track of the `SimplCont` context), `ruleCheck` in `Rules.hs` does not know anything about the simplifier or `SimplCont`. Currently `ruleCheck` is quite simple: It traverses the program examining function applications, looking for rules which apply to the applied function and match a user-specified predicate. It then produces a human-readable message in the event that the rule would not fire. Unfortunately, to evaluate whether the rule will fire we actually need to try calling the `RuleFun`, which now requires having a `SimplCont`. As far as I can tell there are three ways to address this, 1. Pass a dummy `SimplCont` (probably a `Stop`) to the `RuleFun`. This is by far the easiest option but will result in discrepancies between the rule check and the rules actually fired by simplifier. 2. Replicate the simplifier's logic to produce a `SimplCont` in the rule check. This seems like it will result in a great deal of unnecessary (and non-trivial) code duplication. 3. Fold the rule check into the simplifier. It seems like this folds what is currently quite simple code into the already rather complex simplifier. I'm not entirely sure which of these is the least-evil option. Thoughts? Cheers, - Ben P.S. There is also the matter of cyclic module imports. To address these I've split up `SimplUtils.hs` into `SimplCont.hs` and `SimplInline.hs`. Given these two have no cross-dependencies this seems like a reasonable split even independent of the `RuleFun` rework. `Rules.hs` can then import `SimplCont.hs` (although it needs an hs-boot file to satisfy references in `LoadIface.hs`, `HscTypes.hs`, `MkId.hs`). I'll probably reevaluate the need for hs-boot files later. If anyone sees a better restructuring let me know. [1] https://ghc.haskell.org/trac/ghc/ticket/9661#comment:12 [2] https://github.com/ghc/ghc/compare/ghc-7.10...bgamari:wip/rule-context [3] https://github.com/ghc/ghc/commit/a978a4766ebf692820c3b491522b2dd6c642005f [4] https://github.com/bgamari/ghc/blob/c71fb84b8c9ec9c1e279df8c75ceb8a537801aa1/compiler/specialise/Rules.hs#L1125 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Mon Mar 2 10:16:46 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 2 Mar 2015 10:16:46 +0000 Subject: Allowing rules to depend upon SimplCont In-Reply-To: <87oaoch03w.fsf@gmail.com> References: <87oaoch03w.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEBB788@DB3PRD3001MB020.064d.mgd.msft.net> Ben Is there a wiki page that describes this project? - goals, and motivation - design of the change - any implementation notes I've lost context and #9661 is too long to suck up. A wiki page can carefully explain the story, without all the to-and-fro. | 1. Pass a dummy `SimplCont` (probably a `Stop`) to the `RuleFun`. | This | is by far the easiest option but will result in discrepancies | between the rule check and the rules actually fired by simplifier. I'm honestly not sure if anyone actually uses ruleCheck. I'd punt on it for now, and use (1). Document the imperfection in the user manual, cross-referencing the wiki page. | I've split up `SimplUtils.hs` into `SimplCont.hs` and | `SimplInline.hs`. Given these two have no cross-dependencies this | seems like a reasonable split even independent of the `RuleFun` | rework. I'm not sure that all the residue of SimplUtils concerns inlining, does it? Maybe leave the residue as SimplUtils. I would strive hard to avoid another hs-boot file if poss. Simon | -----Original Message----- | From: Ben Gamari [mailto:ben at smart-cactus.org] | Sent: 01 March 2015 21:36 | To: Simon Peyton Jones | Cc: GHC developers | Subject: Allowing rules to depend upon SimplCont | | | In Bug #9661, Comment #12 Simon Peyton-Jones wrote [1], | | > Annoyingly, the `CoreSyn.RuleFun` API for built-in rules does not | give | > access to the context of an application (the `SimplCont`), but it | > would not be hard to make it do so. | > | > So if that is the right rewrite, then it'd be another useful project | > for someone. | | I started taking a look at this over the weekend, hoping for a | weekend-ish project. Unfortunately it's not as easy as it initially | looked. The current state of my work can be found here [2]. The core | of the change (as I understand it) is to add a `SimplCont` argument to | `RuleFun` [3] although things are in actuality a bit more complicated | | While it was easy to pipe through the `SimplCont` in the simplifier | itself (as it was already keeping track of the `SimplCont` context), | `ruleCheck` in `Rules.hs` does not know anything about the simplifier | or `SimplCont`. | | Currently `ruleCheck` is quite simple: It traverses the program | examining function applications, looking for rules which apply to the | applied function and match a user-specified predicate. It then | produces a human-readable message in the event that the rule would not | fire. Unfortunately, to evaluate whether the rule will fire we | actually need to try calling the `RuleFun`, which now requires having | a `SimplCont`. | | As far as I can tell there are three ways to address this, | | 1. Pass a dummy `SimplCont` (probably a `Stop`) to the `RuleFun`. | This | is by far the easiest option but will result in discrepancies | between the rule check and the rules actually fired by simplifier. | | 2. Replicate the simplifier's logic to produce a `SimplCont` in the | rule check. This seems like it will result in a great deal of | unnecessary (and non-trivial) code duplication. | | 3. Fold the rule check into the simplifier. It seems like this folds | what is currently quite simple code into the already rather | complex | simplifier. | | I'm not entirely sure which of these is the least-evil option. | Thoughts? | | Cheers, | | - Ben | | | P.S. There is also the matter of cyclic module imports. To address | these | I've split up `SimplUtils.hs` into `SimplCont.hs` and | `SimplInline.hs`. Given these two have no cross-dependencies this | seems like a reasonable split even independent of the `RuleFun` | rework. | | `Rules.hs` can then import `SimplCont.hs` (although it | needs an hs-boot file to satisfy references in `LoadIface.hs`, | `HscTypes.hs`, `MkId.hs`). I'll probably reevaluate the need for | hs-boot files later. | | If anyone sees a better restructuring let me know. | | | | [1] https://ghc.haskell.org/trac/ghc/ticket/9661#comment:12 | [2] https://github.com/ghc/ghc/compare/ghc-7.10...bgamari:wip/rule- | context | [3] | https://github.com/ghc/ghc/commit/a978a4766ebf692820c3b491522b2dd6c642 | 005f | [4] | https://github.com/bgamari/ghc/blob/c71fb84b8c9ec9c1e279df8c75ceb8a537 | 801aa1/compiler/specialise/Rules.hs#L1125 From ben at smart-cactus.org Mon Mar 2 14:13:23 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 02 Mar 2015 09:13:23 -0500 Subject: Allowing rules to depend upon SimplCont In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEBB788@DB3PRD3001MB020.064d.mgd.msft.net> References: <87oaoch03w.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF7BEBB788@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87k2yzh4ho.fsf@gmail.com> Simon Peyton Jones writes: > Ben > > Is there a wiki page that describes this project? > - goals, and motivation > - design of the change > - any implementation notes > Not that I'm aware of. I can perhaps fix this. > I've lost context and #9661 is too long to suck up. A wiki page can > carefully explain the story, without all the to-and-fro. > #9661 arose out of the unboxed boolean work implemented by Jan (#6135) which should allow us to produce much better code for some types of case analyses by avoiding branches. Unfortunately, it appears that the `litEq` rule is rewriting the `==#` into a case expression. Take the example, f :: Int -> IO () f (I# n) = case isLucky n of True -> print "Bingo!" False -> return () isLucky :: Int# -> Bool isLucky n = n ==# 33 `orI#` n ==# 42 `orI#` n ==# 57 Note that `isLucky` takes care to express its test as unboxed boolean operations. This is supposed to be our way of telling the compiler that we'd really like it to emit something like the following pseudo-machine code, R1 = load $n R2 = eq R1, 33 R3 = eq R1, 42 R5 = eq R1, 57 R4 = or R2, R3 R4 = or R4, R5 jumpnz R4, print_bingo return Unfortunately the `litEq` rule is rewriting the `==#` applications into case expressions which the simplifier then merges, f (I# n) = case n of 33 -> print "Bingo!" 42 -> print "Bingo!" 57 -> print "Bingo!" _ -> return () Which then gets turned in to a sea of branches (see for instance the example in #10124). The goal of this project is to allow `litEq` to sense the context of the term it is considering so that it will avoid interfering with terms like `isLucky n` in case analyses. > | 1. Pass a dummy `SimplCont` (probably a `Stop`) to the `RuleFun`. > | This > | is by far the easiest option but will result in discrepancies > | between the rule check and the rules actually fired by simplifier. > > I'm honestly not sure if anyone actually uses ruleCheck. I'd punt on > it for now, and use (1). Document the imperfection in the user > manual, cross-referencing the wiki page. > Alright, this sounds reasonable. > | I've split up `SimplUtils.hs` into `SimplCont.hs` and > | `SimplInline.hs`. Given these two have no cross-dependencies this > | seems like a reasonable split even independent of the `RuleFun` > | rework. > > I'm not sure that all the residue of SimplUtils concerns inlining, > does it? Maybe leave the residue as SimplUtils. > > I would strive hard to avoid another hs-boot file if poss. > Alright, I will revisit this once the meat of the project is in a better state. Thanks, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Mon Mar 2 14:23:31 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 2 Mar 2015 14:23:31 +0000 Subject: Allowing rules to depend upon SimplCont In-Reply-To: <87k2yzh4ho.fsf@gmail.com> References: <87oaoch03w.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF7BEBB788@DB3PRD3001MB020.064d.mgd.msft.net> <87k2yzh4ho.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEBC038@DB3PRD3001MB020.064d.mgd.msft.net> | > Is there a wiki page that describes this project? | > - goals, and motivation | > - design of the change | > - any implementation notes | > | Not that I'm aware of. I can perhaps fix this. Yes please! It is SO helpful. Simon From ben at smart-cactus.org Mon Mar 2 15:03:57 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 02 Mar 2015 10:03:57 -0500 Subject: Allowing rules to depend upon SimplCont In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEBC038@DB3PRD3001MB020.064d.mgd.msft.net> References: <87oaoch03w.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF7BEBB788@DB3PRD3001MB020.064d.mgd.msft.net> <87k2yzh4ho.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF7BEBC038@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87h9u3h25e.fsf@gmail.com> Simon Peyton Jones writes: > | > Is there a wiki page that describes this project? > | > - goals, and motivation > | > - design of the change > | > - any implementation notes > | > > | Not that I'm aware of. I can perhaps fix this. > > Yes please! It is SO helpful. > How does this [1] look? Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/RuleContexts -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From simonpj at microsoft.com Mon Mar 2 16:16:00 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 2 Mar 2015 16:16:00 +0000 Subject: Pattern matching and GADTs Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEBC2AF@DB3PRD3001MB020.064d.mgd.msft.net> GHC developers You may be interested in this paper, submitted to ICFP GADTs meet their match: pattern-matching warnings that account for GADTs, guards, and laziness, with Georgios Karachalias, Tom Schrijvers, and Dimitrios Vytiniotis. It describes a GADT-aware algorithm for detecting missing and redundant patterns. The implementation is not yet up to production quality, but it will be! If you feel able to give us any feedback about the paper itself, that would be incredibly useful. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.bracker at googlemail.com Mon Mar 2 16:38:20 2015 From: jan.bracker at googlemail.com (Jan Bracker) Date: Mon, 2 Mar 2015 16:38:20 +0000 Subject: Fwd: EvTerms and how they are used In-Reply-To: <54F091DF.1090907@well-typed.com> References: <54EDCF8E.1040903@well-typed.com> <54F091DF.1090907@well-typed.com> Message-ID: Hi Adam, again thank you for your extensive and patient answer! It's a bit hard to know exactly what is going on without the full code, > but I think what is happening is this: you have an unsolved constraint > `Polymonad Identity n_abpq Identity` and your plugin provides an > evidence term of type `Polymonad Identity Identity Identity`, but of > course this is ill-typed, because `n_abpq` is not `Identity`. Hence Core > Lint quite reasonably complains. > I would have thought the constraint solver would derive that 'obviously' `n_abpq` needs to be unified with `Identity` and substitutes. > I'm not sure exactly what you are trying to do, but I think the right > way to approach this problem is to simulate a functional dependency on > Polymonad (in fact, can you use an actual functional dependency)? That is exactly what I _don't_ want to do. I am trying to achieve a more general version of monads, called polymonads as it was introduced here [1]. > When confronted with the constraint `Polymonad Identity n_abpq Identity`, > do > not try to solve it directly, but instead notice that you must have > `n_abpq ~ Identity`. Your plugin can emit this as an additional derived > constraint, which will allow GHC's built-in solver to instantiate the > unification variable `n_abpq` and then solve the original constraint > using the existing instance. No manual evidence generation needed! > Yes, that makes perfect sense! I was so gridlocked, I did not see this as a possibility to solve the problem. Out of interest, can you say anything about your aims here? I'm keen to > find out about the range of applications of typechecker plugins. > I want to make Polymonads as proposed in [1] usable in Haskell. They generalize the bind operator to a more general signature `M a -> (a -> N b) -> P b`. Polymonads subsume the standard Monad as well as indexed or parameterized monad, without relying on functional dependencies, which can be limiting (there may be different requirement depending on the monad being implemented). Currently I am providing a type class for this: class Polymonad m n p where (>>=) :: m a -> (a -> n b) -> p b As the paper points out in section 4.2 (Ambiguity), type inference breaks down, because the constraint solver is not able to solve the ambiguity. Here a small example: -- Return operator for the IO polymonad instance Polymonad Identity Identity IO where -- ... -- Identity polymonad instance Polymonad Identity Identity Identity where -- ... return :: (Polymonad Identity Identity m) => a -> m a return x = Identity x >>= Identity test :: Identity Bool test = do x <- return True return x For this example GHC already gives the following ambiguity errors: Main.hs:134:3: No instance for (Polymonad m0 n0 Identity) arising from a do statement The type variables ?m0?, ?n0? are ambiguous Note: there is a potential instance available: instance Polymonad Identity Identity Identity -- Defined in ?Polymonad? In a stmt of a 'do' block: x <- return True In the expression: do { x <- return True; return x } In an equation for ?test?: test = do { x <- return True; return x } Main.hs:134:8: No instance for (Polymonad Identity Identity m0) arising from a use of ?return? The type variable ?m0? is ambiguous Note: there are several potential instances: instance Polymonad Identity Identity Identity -- Defined in ?Polymonad? instance Polymonad Identity Identity IO -- Defined at Main.hs:85:10 In a stmt of a 'do' block: x <- return True In the expression: do { x <- return True; return x } In an equation for ?test?: test = do { x <- return True; return x } Main.hs:135:3: No instance for (Polymonad Identity Identity n0) arising from a use of ?return? The type variable ?n0? is ambiguous Note: there are several potential instances: instance Polymonad Identity Identity Identity -- Defined in ?Polymonad? instance Polymonad Identity Identity IO -- Defined at Main.hs:85:10 In a stmt of a 'do' block: return x In the expression: do { x <- return True; return x } In an equation for ?test?: test = do { x <- return True; return x } Of course, in the given example we can fix the ambiguity by adding type annotations. But as soon as the examples become bigger that is not possible anymore. Using the approach of the paper [1] these constraints are solvable unambiguously. That's what I am working on. All the best, Jan [1]: http://arxiv.org/pdf/1406.2060v1.pdf On 26/02/15 10:07, Jan Bracker wrote: > > Hi Adam, > > > > thank you for your quick and detailed answer! I think I understand how > > to construct evidence for typeclass constraints now. But trying to apply > > this, I still have some problems. > > > > I have something along the following lines: > > > > class Polymonad m n p where > > -- Functions > > > > instance Polymonad Identity Identity Identity where > > -- Implementation > > > > -- Further instances and some small chunk of code involving them: > > > > The code implies the following constraint: > > Polymonad Identity n_abpq Identity > > > > As the ambiguity error I get says, when trying to compile this: There is > > only one matching instance (the one above, lets call > > it $fPolymonadIdentityIdentityIdentity). > > > > So my plugin tries to tell GHC to use that instance. As far as I > > understand it, since the parameters > > of $fPolymonadIdentityIdentityIdentity are no type variables and there > > is no superclass it should be as easy as saying: > > EvDFunApp $fPolymonadIdentityIdentityIdentity [] [] > > > > But when I run this with -dcore-lint I get the following error message: > > > > *** Core Lint errors : in result of Desugar (after optimization) *** > > : Warning: > > In the expression: >> > > @ Identity > > @ Any > > @ Identity > > $fPolymonadIdentityIdentityIdentity > > @ () > > @ () > > (idOp @ Bool True) > > (>>= > > @ Identity > > @ Identity > > @ Any > > $fPolymonadIdentityIdentityIdentity > > @ Char > > @ () > > (return > > @ Char @ Identity > > $fPolymonadIdentityIdentityIdentity (C# 'a')) > > (\ _ [Occ=Dead] -> > > return @ () @ Identity > > $fPolymonadIdentityIdentityIdentity ())) > > Argument value doesn't match argument type: > > Fun type: > > Polymonad Identity Any Identity => > > forall a_abdV[sk] b_abdW[sk]. > > Identity a_abdV[sk] -> Any b_abdW[sk] -> Identity b_abdW[sk] > > Arg type: Polymonad Identity Identity Identity > > Arg: $fPolymonadIdentityIdentityIdentity > > > > What am I missing? Why doesn't the argument type "Polymonad Identity > > Identity Identity" match the first argument of the function type > > "Polymonad Identity Any Identity => forall a_abdV[sk] b_abdW[sk]. > > Identity a_abdV[sk] -> Any b_abdW[sk] -> Identity b_abdW[sk]". Why is > > the type variable translated to "Any"? > > > > Best, > > Jan > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Mon Mar 2 19:50:40 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 2 Mar 2015 20:50:40 +0100 Subject: Heads up: top level `make test` now runs the full testsuite Message-ID: Typing `make test` in the ghc root directory now runs the full testsuite, just like it already did in the `testsuite/tests` directory. If you want to run the fast testsuite, use the new targets `make fasttest` or `make fast`. The `validate` script still runs the same tests as before (depending on the argument, `--slow`, `--fast` or normal). References: https://ghc.haskell.org/trac/ghc/wiki/Building/StandardTargets#Topleveltargets https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests -Thomas Miedema From simonpj at microsoft.com Mon Mar 2 21:34:32 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 2 Mar 2015 21:34:32 +0000 Subject: Hoopl and Arrows In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEBCE8C@DB3PRD3001MB020.064d.mgd.msft.net> Thomas Hoopl works on control flow graphs, whereas Core is lambda calculus. I really don?t think Hoopl is going to be any good for optimising Core. Ask the ghc-devs mailing list too. Someone there has been writing about arrows recently (take a look at the archive). Simon From: Thomas Bereknyei [mailto:tomberek at gmail.com] Sent: 02 March 2015 17:07 To: nr at cs.tufts.edu; Simon Peyton Jones Subject: Hoopl and Arrows I've been interested in Arrows and their optimization recently. I've run into problems during basic tooling so I built a quasiquoter for proc notation (still working on rec and let statements, but the rest of it works) that converts from haskell-src-exts into a desugarred TH format. My original goal was to implement "Casual Commutative Arrows" [1] but to make it more user friendly and to include arrows with effects. I came across Hoopl and at first glance I would think it can help with Arrow optimization, especially with the tuple shuffling from desuggared proc-do notation. In spite of the slogan of "Hoopl: Dataflow Optimization made Simple" and the git repo's testing folder, I'm not 100% clear on Hoopl usage. I would be interested in anything that can get me started or even a thought or two whether it would be worth looking into for Arrows. Simon, regarding [2], my quasiquoter can be rewritten to take `bind`, `bind_`, `fixA`, and `ifThenElseA` from scope rather than being built in. Would that help with #7828? I am not very familiar with GHC internals at the moment, and I am confused about the complexity of dsArrows.hs in contrast with my own parser. It seems I have a good start on it in the Parser module at [3], WARNING: untested and rough draft code, though suggestions and pointers are welcome. I was thinking of sending some of my code to haskell-src-meta because they can't yet translate their version of Exp into TH's ExpQ. -Tom [1] (https://hackage.haskell.org/package/CCA) [2] (https://ghc.haskell.org/trac/ghc/ticket/7828#comment:54) [3] (https://www.fpcomplete.com/user/tomberek/rulestesting) -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Mon Mar 2 21:35:21 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 2 Mar 2015 13:35:21 -0800 Subject: Fwd: EvTerms and how they are used In-Reply-To: References: <54EDCF8E.1040903@well-typed.com> <54F091DF.1090907@well-typed.com> Message-ID: Hello, I've seen instances of this problem show up over and over again, and I think that there is a more principled solution, based on the idea of `improvement`. The idea is to allow programmers to specify custom improvements. Functional dependencies are one way to do this, but there is no reason why this should be the only way. The details of this idea are explained in this paper: "Simplifying and Improving Qualified Types" ( http://web.cecs.pdx.edu/~mpj/pubs/RR-1040.pdf). In concrete Haskell syntax, this might work like this: 1. Add a new declaration: improve CS using EQs Here the `CS` are a collection of constraints, and the `EQs` are a collection of equations. 2. Modify the constraint solver, so that when it sees `CS` in the inert set, it will emit the `EQs` as derived constraints. This is all. So now you can write things like this: improve PolyMonad a b Identity using (a ~ Identity, b ~ Identity) This tells GHC that it is OK to assume that if the final result is `Identity`, then the first two arguments will also be in the identity monad. This is a fairly conservative extension, in that it is only used to instantiate variables, and it never needs to produce new equality proofs. This is pretty much exactly how FDs work in the current implementation of GHC. For example, the declaration: class C a b | a -> b where ... with GHC's current implementation, is exactly equivalent to: class C a b where ... improve (C a b, C a c) using (b ~ c) Aside: GHC actually checks that all instances are consistent with the FD declarations, so GHC *could* use them to actually generate new evidence, but it does not do so at the moment. Anyway, implementing something like this should not be too hard, and it seems that it could be used not just for the PolyMonads work, but also for other cases where one wants to write specific improvements. -Iavor PS: with GHC's current approach to resolving instances, you could also avoid some of the ambiguities for the `Identity` instance by writing it like this: instance (a ~ Identity, b ~ Idnetity) => PolyMonad a b Identity where ... On Mon, Mar 2, 2015 at 8:38 AM, Jan Bracker wrote: > Hi Adam, > > again thank you for your extensive and patient answer! > > It's a bit hard to know exactly what is going on without the full code, >> but I think what is happening is this: you have an unsolved constraint >> `Polymonad Identity n_abpq Identity` and your plugin provides an >> evidence term of type `Polymonad Identity Identity Identity`, but of >> course this is ill-typed, because `n_abpq` is not `Identity`. Hence Core >> Lint quite reasonably complains. >> > > I would have thought the constraint solver would derive that 'obviously' > `n_abpq` needs to be unified with `Identity` and substitutes. > > >> I'm not sure exactly what you are trying to do, but I think the right >> way to approach this problem is to simulate a functional dependency on >> Polymonad (in fact, can you use an actual functional dependency)? > > > That is exactly what I _don't_ want to do. I am trying to achieve a more > general version of monads, called polymonads as it was introduced here [1]. > > >> When confronted with the constraint `Polymonad Identity n_abpq Identity`, >> do >> not try to solve it directly, but instead notice that you must have >> `n_abpq ~ Identity`. Your plugin can emit this as an additional derived >> constraint, which will allow GHC's built-in solver to instantiate the >> unification variable `n_abpq` and then solve the original constraint >> using the existing instance. No manual evidence generation needed! >> > > Yes, that makes perfect sense! I was so gridlocked, I did not see this as a > possibility to solve the problem. > > Out of interest, can you say anything about your aims here? I'm keen to >> find out about the range of applications of typechecker plugins. >> > > I want to make Polymonads as proposed in [1] usable in Haskell. They > generalize > the bind operator to a more general signature `M a -> (a -> N b) -> P b`. > Polymonads > subsume the standard Monad as well as indexed or parameterized monad, > without > relying on functional dependencies, which can be limiting (there may be > different > requirement depending on the monad being implemented). > Currently I am providing a type class for this: > > class Polymonad m n p where > (>>=) :: m a -> (a -> n b) -> p b > > As the paper points out in section 4.2 (Ambiguity), type inference breaks > down, > because the constraint solver is not able to solve the ambiguity. Here a > small example: > > -- Return operator for the IO polymonad > instance Polymonad Identity Identity IO where > -- ... > > -- Identity polymonad > instance Polymonad Identity Identity Identity where > -- ... > > return :: (Polymonad Identity Identity m) => a -> m a > return x = Identity x >>= Identity > > test :: Identity Bool > test = do > x <- return True > return x > > For this example GHC already gives the following ambiguity errors: > > Main.hs:134:3: > No instance for (Polymonad m0 n0 Identity) > arising from a do statement > The type variables ?m0?, ?n0? are ambiguous > Note: there is a potential instance available: > instance Polymonad Identity Identity Identity > -- Defined in ?Polymonad? > In a stmt of a 'do' block: x <- return True > In the expression: > do { x <- return True; > return x } > In an equation for ?test?: > test > = do { x <- return True; > return x } > > Main.hs:134:8: > No instance for (Polymonad Identity Identity m0) > arising from a use of ?return? > The type variable ?m0? is ambiguous > Note: there are several potential instances: > instance Polymonad Identity Identity Identity > -- Defined in ?Polymonad? > instance Polymonad Identity Identity IO -- Defined at Main.hs:85:10 > In a stmt of a 'do' block: x <- return True > In the expression: > do { x <- return True; > return x } > In an equation for ?test?: > test > = do { x <- return True; > return x } > > Main.hs:135:3: > No instance for (Polymonad Identity Identity n0) > arising from a use of ?return? > The type variable ?n0? is ambiguous > Note: there are several potential instances: > instance Polymonad Identity Identity Identity > -- Defined in ?Polymonad? > instance Polymonad Identity Identity IO -- Defined at Main.hs:85:10 > In a stmt of a 'do' block: return x > In the expression: > do { x <- return True; > return x } > In an equation for ?test?: > test > = do { x <- return True; > return x } > > Of course, in the given example we can fix the ambiguity by adding type > annotations. > But as soon as the examples become bigger that is not possible anymore. > > Using the approach of the paper [1] these constraints are solvable > unambiguously. > That's what I am working on. > > All the best, > Jan > > [1]: http://arxiv.org/pdf/1406.2060v1.pdf > > On 26/02/15 10:07, Jan Bracker wrote: >> > Hi Adam, >> > >> > thank you for your quick and detailed answer! I think I understand how >> > to construct evidence for typeclass constraints now. But trying to apply >> > this, I still have some problems. >> > >> > I have something along the following lines: >> > >> > class Polymonad m n p where >> > -- Functions >> > >> > instance Polymonad Identity Identity Identity where >> > -- Implementation >> > >> > -- Further instances and some small chunk of code involving them: >> > >> > The code implies the following constraint: >> > Polymonad Identity n_abpq Identity >> > >> > As the ambiguity error I get says, when trying to compile this: There is >> > only one matching instance (the one above, lets call >> > it $fPolymonadIdentityIdentityIdentity). >> > >> > So my plugin tries to tell GHC to use that instance. As far as I >> > understand it, since the parameters >> > of $fPolymonadIdentityIdentityIdentity are no type variables and there >> > is no superclass it should be as easy as saying: >> > EvDFunApp $fPolymonadIdentityIdentityIdentity [] [] >> > >> > But when I run this with -dcore-lint I get the following error message: >> > >> > *** Core Lint errors : in result of Desugar (after optimization) *** >> > : Warning: >> > In the expression: >> >> > @ Identity >> > @ Any >> > @ Identity >> > $fPolymonadIdentityIdentityIdentity >> > @ () >> > @ () >> > (idOp @ Bool True) >> > (>>= >> > @ Identity >> > @ Identity >> > @ Any >> > $fPolymonadIdentityIdentityIdentity >> > @ Char >> > @ () >> > (return >> > @ Char @ Identity >> > $fPolymonadIdentityIdentityIdentity (C# 'a')) >> > (\ _ [Occ=Dead] -> >> > return @ () @ Identity >> > $fPolymonadIdentityIdentityIdentity ())) >> > Argument value doesn't match argument type: >> > Fun type: >> > Polymonad Identity Any Identity => >> > forall a_abdV[sk] b_abdW[sk]. >> > Identity a_abdV[sk] -> Any b_abdW[sk] -> Identity b_abdW[sk] >> > Arg type: Polymonad Identity Identity Identity >> > Arg: $fPolymonadIdentityIdentityIdentity >> > >> > What am I missing? Why doesn't the argument type "Polymonad Identity >> > Identity Identity" match the first argument of the function type >> > "Polymonad Identity Any Identity => forall a_abdV[sk] b_abdW[sk]. >> > Identity a_abdV[sk] -> Any b_abdW[sk] -> Identity b_abdW[sk]". Why is >> > the type variable translated to "Any"? >> > >> > Best, >> > Jan >> >> -- >> Adam Gundry, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgbailey at gmail.com Mon Mar 2 22:43:15 2015 From: jgbailey at gmail.com (Justin Bailey) Date: Mon, 2 Mar 2015 14:43:15 -0800 Subject: Hoopl and Arrows In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEBCE8C@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEBCE8C@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Thomas, I did some stuff with Hoopl a few years ago as part of my Master's thesis ("Using Dataflow Optimization Techniques with a Monadic Intermediate Language"). In Chapter 3 ("The Hoopl Library"), I wrote up an overview of Hoopl and work through a new example (new at the time, at least). You can download my thesis from http://mil.codeslower.com. The example code from that chapter is available at https://github.com/m4dc4p/mil/blob/master/thesis/DeadCodeC.lhs. No guarantees that it still compiles, but I'm glad to try and help needed :) On Mon, Mar 2, 2015 at 1:34 PM, Simon Peyton Jones wrote: > Thomas > > > > Hoopl works on control flow graphs, whereas Core is lambda calculus. I > really don?t think Hoopl is going to be any good for optimising Core. > > > > Ask the ghc-devs mailing list too. Someone there has been writing about > arrows recently (take a look at the archive). > > > > Simon > > > > From: Thomas Bereknyei [mailto:tomberek at gmail.com] > Sent: 02 March 2015 17:07 > To: nr at cs.tufts.edu; Simon Peyton Jones > Subject: Hoopl and Arrows > > > > I've been interested in Arrows and their optimization recently. I've run > into problems during basic tooling so I built a quasiquoter for proc > notation (still working on rec and let statements, but the rest of it works) > that converts from haskell-src-exts into a desugarred TH format. My original > goal was to implement "Casual Commutative Arrows" [1] but to make it more > user friendly and to include arrows with effects. I came across Hoopl and at > first glance I would think it can help with Arrow optimization, especially > with the tuple shuffling from desuggared proc-do notation. In spite of the > slogan of "Hoopl: Dataflow Optimization made Simple" and the git repo's > testing folder, I'm not 100% clear on Hoopl usage. I would be interested in > anything that can get me started or even a thought or two whether it would > be worth looking into for Arrows. > > Simon, regarding [2], my quasiquoter can be rewritten to take `bind`, > `bind_`, `fixA`, and `ifThenElseA` from scope rather than being built in. > Would that help with #7828? I am not very familiar with GHC internals at > the moment, and I am confused about the complexity of dsArrows.hs in > contrast with my own parser. It seems I have a good start on it in the > Parser module at [3], WARNING: untested and rough draft code, though > suggestions and pointers are welcome. I was thinking of sending some of my > code to haskell-src-meta because they can't yet translate their version of > Exp into TH's ExpQ. > > -Tom > > > [1] (https://hackage.haskell.org/package/CCA) > [2] (https://ghc.haskell.org/trac/ghc/ticket/7828#comment:54) > [3] (https://www.fpcomplete.com/user/tomberek/rulestesting) > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From jan.stolarek at p.lodz.pl Tue Mar 3 07:09:09 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 3 Mar 2015 08:09:09 +0100 Subject: Heads up: top level `make test` now runs the full testsuite In-Reply-To: References: Message-ID: <201503030809.09808.jan.stolarek@p.lodz.pl> > Typing `make test` in the ghc root directory now runs the full > testsuite Does this mean that full testsuite run has no broken tests? I vaguely recall that some time ago a couple of tests were broken. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From thomasmiedema at gmail.com Tue Mar 3 07:20:12 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 3 Mar 2015 08:20:12 +0100 Subject: Heads up: top level `make test` now runs the full testsuite In-Reply-To: <201503030809.09808.jan.stolarek@p.lodz.pl> References: <201503030809.09808.jan.stolarek@p.lodz.pl> Message-ID: > Does this mean that full testsuite run has no broken tests? I vaguely recall that some time ago a > couple of tests were broken. No, some tests are still broken. From nikita at karetnikov.org Tue Mar 3 11:32:05 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Tue, 03 Mar 2015 14:32:05 +0300 Subject: PSA: building HEAD with Nix/NixOS Message-ID: <87vbii9v0q.fsf@karetnikov.org> I've just added instructions showing how easy it is to build GHC HEAD and its dependencies with Nix/NixOS: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#NixNixOS I hope someone finds them useful. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From ndmitchell at gmail.com Tue Mar 3 13:51:32 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue, 3 Mar 2015 13:51:32 +0000 Subject: GHC 7.8.4 for Windows 32bit Message-ID: Hi, GHC 7.8.4 was released a little while ago, but there still isn't a Windows 32bit version available. With my "MinGHC maintainer" hat on we're getting quite a lot of requests for a 32bit 7.8.4 version. With my "using Haskell commercially" hat on the lack of a 32bit build is causing delays to infrastructure upgrades. Any timeline for a 32bit Windows build? Anything you're stuck on? Going forward, it seems the 32bit Windows version remains popular, so if all releases and release candidates came with such a version it would be great. I note there wasn't (and still might not be) a 7.10 RC, and as a result I've only tested my packages on Linux. Thanks, Neil From austin at well-typed.com Tue Mar 3 14:05:11 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 3 Mar 2015 08:05:11 -0600 Subject: GHC 7.8.4 for Windows 32bit In-Reply-To: References: Message-ID: Sorry about that; at the time I was having trouble with my build bots and I've continuously had trouble remoting into the Win32 machines I have... The 64bit build bots worked fine, but the 32 ones consistently had flaky internet connectivity, to the point I couldn't bootstrap GHC itself. I tried yesterday again, and seem to have fallen pray to something else (which makes it so I cannot RDP in at all right now, it seems). I've actually assembled a new PC here (that I have not yet installed Windows on) however, so hopefully I can shortly get binaries up. On Tue, Mar 3, 2015 at 7:51 AM, Neil Mitchell wrote: > Hi, > > GHC 7.8.4 was released a little while ago, but there still isn't a > Windows 32bit version available. With my "MinGHC maintainer" hat on > we're getting quite a lot of requests for a 32bit 7.8.4 version. With > my "using Haskell commercially" hat on the lack of a 32bit build is > causing delays to infrastructure upgrades. Any timeline for a 32bit > Windows build? Anything you're stuck on? > > Going forward, it seems the 32bit Windows version remains popular, so > if all releases and release candidates came with such a version it > would be great. I note there wasn't (and still might not be) a 7.10 > RC, and as a result I've only tested my packages on Linux. > > Thanks, Neil -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ggreif at gmail.com Tue Mar 3 14:13:08 2015 From: ggreif at gmail.com (Gabor Greif) Date: Tue, 3 Mar 2015 15:13:08 +0100 Subject: Pattern matching and GADTs In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEBC2AF@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEBC2AF@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: This might be off-topic for your paper, but possibly relevant for GADT-based programming: In the below snippet ----------------------------------------------------------------- {-# LANGUAGE GADTs, PatternGuards #-} data Bar a where Listy :: Bar [Int] {- foo :: a -> Bar a -> Int foo [0] Listy = 1 gadtTest.hs:8:5: Couldn't match expected type `a' with actual type `[a0]' `a' is a rigid type variable bound by the type signature for: foo :: a -> Bar a -> Int at /home/ggreif/gadtTest.hs:7:8 Relevant bindings include foo :: a -> Bar a -> Int (bound at /home/ggreif/gadtTest.hs:8:1) In the pattern: [0] In an equation for `foo': foo [0] Listy = 1 -} foo' :: Bar a -> a -> Int foo' Listy [a] = a foo'' :: a -> Bar a -> Int foo'' l Listy | [a] <- l = a ----------------------------------------------------------------- the "wrong" order of pattern matches (i.e. foo) causes an error, the flipped order works (i.e. foo') and pattern guards remedy the situation (e.g. foo''). Since the type signatures are isomorphic this is a bit disturbing. Why is it like this? My guess is that patterns are matched left-to-right and refinements become available "too late". Or is the reason buried in the OutsideIn algorithm (and function arrow associativity: a -> (Bar a -> Int)) ? Would it be a big deal to forward-propagate type information in from GADT pattern matches? Thanks and cheers, Gabor On 3/2/15, Simon Peyton Jones wrote: > GHC developers > You may be interested in this paper, submitted to ICFP > GADTs meet their match: pattern-matching warnings that account for GADTs, > guards, and > laziness, > with Georgios Karachalias, Tom Schrijvers, and Dimitrios Vytiniotis. > It describes a GADT-aware algorithm for detecting missing and redundant > patterns. > The implementation is not yet up to production quality, but it will be! > If you feel able to give us any feedback about the paper itself, that would > be incredibly useful. Thanks > Simon > > From simonpj at microsoft.com Tue Mar 3 14:23:43 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 3 Mar 2015 14:23:43 +0000 Subject: Pattern matching and GADTs In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7BEBC2AF@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEBDD75@DB3PRD3001MB020.064d.mgd.msft.net> | data Bar a where | Listy :: Bar [Int] | | {- | foo :: a -> Bar a -> Int | foo [0] Listy = 1 Well you'd get a seg-fault from the call (foo True (undefined :: Bar [Int])). So we really MUST match the (Bar a) arg before the 'a' arg. And Haskell only offers one way to do that, which is to put it first. You don't have to change the argument order. Write foo xs Listy | [0] <- xs = 1 Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gabor | Greif | Sent: 03 March 2015 14:13 | To: ghc-devs at haskell.org | Subject: Re: Pattern matching and GADTs | | This might be off-topic for your paper, but possibly relevant for GADT- | based programming: | | In the below snippet | ----------------------------------------------------------------- | {-# LANGUAGE GADTs, PatternGuards #-} | | data Bar a where | Listy :: Bar [Int] | | {- | foo :: a -> Bar a -> Int | foo [0] Listy = 1 | | gadtTest.hs:8:5: | Couldn't match expected type `a' with actual type `[a0]' | `a' is a rigid type variable bound by | the type signature for: foo :: a -> Bar a -> Int | at /home/ggreif/gadtTest.hs:7:8 | Relevant bindings include | foo :: a -> Bar a -> Int (bound at /home/ggreif/gadtTest.hs:8:1) | In the pattern: [0] | In an equation for `foo': foo [0] Listy = 1 -} | | foo' :: Bar a -> a -> Int | foo' Listy [a] = a | | foo'' :: a -> Bar a -> Int | foo'' l Listy | [a] <- l = a | ----------------------------------------------------------------- | | the "wrong" order of pattern matches (i.e. foo) causes an error, the | flipped order works (i.e. foo') and pattern guards remedy the situation | (e.g. foo''). | | Since the type signatures are isomorphic this is a bit disturbing. Why | is it like this? | My guess is that patterns are matched left-to-right and refinements | become available "too late". Or is the reason buried in the OutsideIn | algorithm (and function arrow associativity: a -> (Bar a -> Int)) ? | | Would it be a big deal to forward-propagate type information in from | GADT pattern matches? | | Thanks and cheers, | | Gabor | | On 3/2/15, Simon Peyton Jones wrote: | > GHC developers | > You may be interested in this paper, submitted to ICFP GADTs meet | > their match: pattern-matching warnings that account for GADTs, | guards, | > and | > laziness ing>, with Georgios Karachalias, Tom Schrijvers, and Dimitrios | > Vytiniotis. | > It describes a GADT-aware algorithm for detecting missing and | > redundant patterns. | > The implementation is not yet up to production quality, but it will | be! | > If you feel able to give us any feedback about the paper itself, that | > would be incredibly useful. Thanks Simon | > | > | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From jwlato at gmail.com Tue Mar 3 21:07:38 2015 From: jwlato at gmail.com (John Lato) Date: Tue, 03 Mar 2015 21:07:38 +0000 Subject: Hoopl and Arrows Message-ID: Thomas, I'd be very careful mixing effectful arrows with the CCA framework. Effectful arrows are not necessarily commutative, so the CCA transformations may be invalid. I did something very similar a couple years ago, by creating an arrow instance that generated TH expressions. IME the ghc optimizer handled it extremely well, and no extra optimizations were necessary. John L. On 14:43, Mon, Mar 2, 2015 Justin Bailey wrote: > Thomas, > > I did some stuff with Hoopl a few years ago as part of my Master's > thesis ("Using Dataflow Optimization Techniques with a Monadic > Intermediate Language"). In Chapter 3 ("The Hoopl Library"), I wrote > up an overview of Hoopl and work through a new example (new at the > time, at least). > > You can download my thesis from http://mil.codeslower.com. The example > code from that chapter is available at > https://github.com/m4dc4p/mil/blob/master/thesis/DeadCodeC.lhs. No > guarantees that it still compiles, but I'm glad to try and help needed > :) > > > On Mon, Mar 2, 2015 at 1:34 PM, Simon Peyton Jones > wrote: > > Thomas > > > > > > > > Hoopl works on control flow graphs, whereas Core is lambda calculus. I > > really don?t think Hoopl is going to be any good for optimising Core. > > > > > > > > Ask the ghc-devs mailing list too. Someone there has been writing about > > arrows recently (take a look at the archive). > > > > > > > > Simon > > > > > > > > From: Thomas Bereknyei [mailto:tomberek at gmail.com] > > Sent: 02 March 2015 17:07 > > To: nr at cs.tufts.edu; Simon Peyton Jones > > Subject: Hoopl and Arrows > > > > > > > > I've been interested in Arrows and their optimization recently. I've run > > into problems during basic tooling so I built a quasiquoter for proc > > notation (still working on rec and let statements, but the rest of it > works) > > that converts from haskell-src-exts into a desugarred TH format. My > original > > goal was to implement "Casual Commutative Arrows" [1] but to make it > more > > user friendly and to include arrows with effects. I came across Hoopl > and at > > first glance I would think it can help with Arrow optimization, > especially > > with the tuple shuffling from desuggared proc-do notation. In spite of > the > > slogan of "Hoopl: Dataflow Optimization made Simple" and the git repo's > > testing folder, I'm not 100% clear on Hoopl usage. I would be interested > in > > anything that can get me started or even a thought or two whether it > would > > be worth looking into for Arrows. > > > > Simon, regarding [2], my quasiquoter can be rewritten to take `bind`, > > `bind_`, `fixA`, and `ifThenElseA` from scope rather than being built in. > > Would that help with #7828? I am not very familiar with GHC internals at > > the moment, and I am confused about the complexity of dsArrows.hs in > > contrast with my own parser. It seems I have a good start on it in the > > Parser module at [3], WARNING: untested and rough draft code, though > > suggestions and pointers are welcome. I was thinking of sending some of > my > > code to haskell-src-meta because they can't yet translate their version > of > > Exp into TH's ExpQ. > > > > -Tom > > > > > > [1] (https://hackage.haskell.org/package/CCA) > > [2] (https://ghc.haskell.org/trac/ghc/ticket/7828#comment:54) > > [3] (https://www.fpcomplete.com/user/tomberek/rulestesting) > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Mar 3 22:30:25 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 3 Mar 2015 22:30:25 +0000 Subject: Windows build broken Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEBE787@DB3PRD3001MB020.064d.mgd.msft.net> AAARGH! Windows build is broken again. Please can someone fix? In file included from rts\RtsMain.c:12:0: rts\PosixSource.h:31:0: error: "__USE_MINGW_ANSI_STDIO" redefined c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/_mingw.h:280:0: note: this is the location of the previous definition rts/ghc.mk:243: recipe for target 'rts/dist/build/RtsMain.o' failed make[1]: *** [rts/dist/build/RtsMain.o] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Mar 3 23:14:41 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 3 Mar 2015 17:14:41 -0600 Subject: Windows build broken In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEBE787@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEBE787@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: This must be fallout from the VEH handler change I pushed earlier - 5200bdeb26c5ec98739b14b10fc8907296bceeb9. I'll try to fix/revert shortly. On Tue, Mar 3, 2015 at 4:30 PM, Simon Peyton Jones wrote: > AAARGH! Windows build is broken again. > > Please can someone fix? > > > > In file included from rts\RtsMain.c:12:0: > > > > rts\PosixSource.h:31:0: error: "__USE_MINGW_ANSI_STDIO" redefined > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/_mingw.h:280:0: > note: this is the location of the previous definition > > rts/ghc.mk:243: recipe for target 'rts/dist/build/RtsMain.o' failed > > make[1]: *** [rts/dist/build/RtsMain.o] Error 1 > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From lonetiger at gmail.com Tue Mar 3 23:17:22 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Tue, 3 Mar 2015 23:17:22 +0000 Subject: =?utf-8?Q?Re:_Windows_build_broken?= In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7BEBE787@DB3PRD3001MB020.064d.mgd.msft.net>, Message-ID: <54f64233.a952c20a.2164.4d30@mx.google.com> Hi, Yes, sorry about that, I?m trying to reproduce it locally but no luck so far.. (waiting for a clean checkout to finish now) But the fix is probably to swap the definition of Excn.h and PosixSource.h in RtsMain.c or moving Excn.h to the bottom of the include list. Something in Excn.h must be using _mingw.h which will define the macro if not defined. Adding PosixSource to the top would make sure it is defined before anything else. Regards, Tamar From: Austin Seipp Sent: ?Wednesday?, ?March? ?4?, ?2015 ?00?:?14 To: Simon Peyton Jones Cc: ghc-devs at haskell.org This must be fallout from the VEH handler change I pushed earlier - 5200bdeb26c5ec98739b14b10fc8907296bceeb9. I'll try to fix/revert shortly. On Tue, Mar 3, 2015 at 4:30 PM, Simon Peyton Jones wrote: > AAARGH! Windows build is broken again. > > Please can someone fix? > > > > In file included from rts\RtsMain.c:12:0: > > > > rts\PosixSource.h:31:0: error: "__USE_MINGW_ANSI_STDIO" redefined > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/_mingw.h:280:0: > note: this is the location of the previous definition > > rts/ghc.mk:243: recipe for target 'rts/dist/build/RtsMain.o' failed > > make[1]: *** [rts/dist/build/RtsMain.o] Error 1 > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Wed Mar 4 00:46:49 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Wed, 4 Mar 2015 00:46:49 +0000 Subject: =?utf-8?Q?Re:_Windows_build_broken?= In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7BEBE787@DB3PRD3001MB020.064d.mgd.msft.net>, Message-ID: <54f656ae.295bb40a.7dc8.6c84@mx.google.com> Hi Simon, Austin https://phabricator.haskell.org/D698 should fix the build. validate runs cleanly through. My apologies again, my last few builds were using ./validate --no-clean by my are-validating.mk was missing so it wasn?t compiling with -Werror. Regards, Tamar From: Austin Seipp Sent: ?Wednesday?, ?March? ?4?, ?2015 ?00?:?14 To: Simon Peyton Jones Cc: ghc-devs at haskell.org This must be fallout from the VEH handler change I pushed earlier - 5200bdeb26c5ec98739b14b10fc8907296bceeb9. I'll try to fix/revert shortly. On Tue, Mar 3, 2015 at 4:30 PM, Simon Peyton Jones wrote: > AAARGH! Windows build is broken again. > > Please can someone fix? > > > > In file included from rts\RtsMain.c:12:0: > > > > rts\PosixSource.h:31:0: error: "__USE_MINGW_ANSI_STDIO" redefined > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/_mingw.h:280:0: > note: this is the location of the previous definition > > rts/ghc.mk:243: recipe for target 'rts/dist/build/RtsMain.o' failed > > make[1]: *** [rts/dist/build/RtsMain.o] Error 1 > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Wed Mar 4 02:55:11 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 3 Mar 2015 20:55:11 -0600 Subject: GHC Weekly News - 2015/03/03 Message-ID: (This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150303) Hi *, It's that time again! Today GHC HQ met on a Tuesday to avoid some scheduling conflicts, and that means it's time to send some news to people. Just a quick reminder from last week: we're hoping to make our third GHC 7.10.1 release candidate on '''Friday, March 13th''', with the final release on '''Friday, March 27th'''. Today, GHC HQ met up and mostly discussed the current status of GHC 7.10 and its bugs, which you can find on the Status page: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 But we've also had a little more list activity this week than we did before: - Simon PJ showed up to tell everyone he'd be a bit busy due to upcoming ICFP deadlines! However, since it's passed as of last Friday, it looks like the coming weeks will be more normal. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008420.html - Michael Snoyman started a thread about a serious bug that has eluded attention during the 7.10 RC period: `cabal haddock --hoogle` does not work! https://mail.haskell.org/pipermail/ghc-devs/2015-February/008412.html - Jan Bracker is working on using the new type-checking plugins infrastructure, and had a question about the usage of what the typechecker calls `EvTerms`. Adam swooped in to respond. https://mail.haskell.org/pipermail/ghc-devs/2015-February/008414.html - Ben Gamari has been working on #9661, but while trying to do so hit a very painful set of conditions due to the import dependency graph of the compiler, making his fix much more difficult. Simon responds with his thoughts. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008432.html - After returning from an ICFP-writing-induced hiatus, Simon alerted us to a new paper of his describing his new, GADT-aware pattern matching checker. As usual, he'd love comments! The implementation will hopefully land in HEAD soon. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008437.html - Nikita Karetnikov was kind enough to alert the list that he's gotten a nice, Nix/NixOS based solution to building GHC, which he's documented on the wiki. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008445.html Some noteworthy commits that went into `ghc.git` in the past week include: - Commit aead01902e1c41e85b758dbafd15e60d08956374 - the `-fwarn-unused-binds` warning was split into 3 warnings, fixing #17 (one of our oldest open tickets). - Commit 5be8ed4da1963ed2d45a65fb61d761c977707cce - restores `integer-gmp` compatibility with GMP 4.x. This will be part of GHC 7.10. - Commit 31d4f2e9c89e22a91f98b4a4aa0f80af6b07b60f - `make test` in the top-level directory now works as expected. - Commit 5200bdeb26c5ec98739b14b10fc8907296bceeb9 - Replace Windows SEH handlers with VEH handlers, working uniformly across x86 and x86_64. Closed tickets the past week include: #9586, #10122, #10026, #8896, #10090, #10123, #10128, #10025, #10024, #10125, #9994, #9962, #10103, #10112, #10122, #9901, #10130, #10129, #9044, #8342, #8780, #10003, #17, #2530, #8274, and #10107. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From karel.gardas at centrum.cz Wed Mar 4 08:19:15 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 04 Mar 2015 09:19:15 +0100 Subject: freebsd-amd64-head (FreeBSD/amd64 HEAD (Gabor Pali)), build 556, Success In-Reply-To: <54f680c6.0308c20a.4ed1.69e9@mx.google.com> References: <54f680c6.0308c20a.4ed1.69e9@mx.google.com> Message-ID: <54F6C003.9010803@centrum.cz> Hi, due to recent switch to full testsuite run, our buildbots now provides a lot of output due to much more failing testcases. The case with FreeBSD buildbots even got so far, that server can't handle amount of data and leaks some binary trash to the log. I would really be curious if this is a leak of runtime memory and so it shows serious bug somewhere in GHC rts or what is it exactly... If you are curious investigate output attached to the last night freebsd buildots status emails. Thanks, Karel PS: I'm assuming the builder infrastructure as run by Gabor on his server is still written in Haskell and compiled by GHC... On 03/ 4/15 04:49 AM, Builder wrote: > freebsd-amd64-head (FreeBSD/amd64 HEAD (Gabor Pali)), build 556 > > Build succeeded > Details: http://haskell.inf.elte.hu/builders/freebsd-amd64-head/556.html > > git clone | Success > create mk/build.mk | Success > get subrepos | Success > repo versions | Success > touching clean-check files | Success > setting version date | Success > booting | Success > configuring | Success > creating check-remove-before | Success > compiling | Success > creating check-remove-after | Success > compiling testremove | Success > simulating clean | Success > checking clean | Success > making bindist | Success > making srcdist | Success > uploading bindist | Success > uploading srcdist | Success > uploading tarball source | Success > testing bindist | Success > testing | Success > testsuite summary | Success > > Build succeeded > Details: http://haskell.inf.elte.hu/builders/freebsd-amd64-head/556.html > > > > > _______________________________________________ > ghc-builds mailing list > ghc-builds at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-builds From simonpj at microsoft.com Wed Mar 4 09:21:17 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 4 Mar 2015 09:21:17 +0000 Subject: Windows build broken In-Reply-To: <54f656ae.295bb40a.7dc8.6c84@mx.google.com> References: <618BE556AADD624C9C918AA5D5911BEF7BEBE787@DB3PRD3001MB020.064d.mgd.msft.net>, <54f656ae.295bb40a.7dc8.6c84@mx.google.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEBECDD@DB3PRD3001MB020.064d.mgd.msft.net> Thanks for a prompt fix! From: Tamar Christina [mailto:lonetiger at gmail.com] Sent: 04 March 2015 00:47 To: Austin Seipp; Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: Windows build broken Hi Simon, Austin https://phabricator.haskell.org/D698 should fix the build. validate runs cleanly through. My apologies again, my last few builds were using ./validate --no-clean by my are-validating.mk was missing so it wasn?t compiling with -Werror. Regards, Tamar From: Austin Seipp Sent: ?Wednesday?, ?March? ?4?, ?2015 ?00?:?14 To: Simon Peyton Jones Cc: ghc-devs at haskell.org This must be fallout from the VEH handler change I pushed earlier - 5200bdeb26c5ec98739b14b10fc8907296bceeb9. I'll try to fix/revert shortly. On Tue, Mar 3, 2015 at 4:30 PM, Simon Peyton Jones > wrote: > AAARGH! Windows build is broken again. > > Please can someone fix? > > > > In file included from rts\RtsMain.c:12:0: > > > > rts\PosixSource.h:31:0: error: "__USE_MINGW_ANSI_STDIO" redefined > > c:\code\head\inplace\mingw\bin\../lib/gcc/mingw32/4.5.2/../../../../include/_mingw.h:280:0: > note: this is the location of the previous definition > > rts/ghc.mk:243: recipe for target 'rts/dist/build/RtsMain.o' failed > > make[1]: *** [rts/dist/build/RtsMain.o] Error 1 > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Wed Mar 4 10:47:05 2015 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Wed, 4 Mar 2015 11:47:05 +0100 Subject: freebsd-amd64-head (FreeBSD/amd64 HEAD (Gabor Pali)), build 556, Success In-Reply-To: <54F6C003.9010803@centrum.cz> References: <54f680c6.0308c20a.4ed1.69e9@mx.google.com> <54F6C003.9010803@centrum.cz> Message-ID: Hi Karel, 2015-03-04 9:19 GMT+01:00 Karel Gardas : > due to recent switch to full testsuite run, our buildbots now provides a lot > of output due to much more failing testcases. Oops, that is indeed the case, thanks for calling my attention to this. I guess I shall only update the LLVM toolchain on the builders and everything will go back to the normal. > The case with FreeBSD > buildbots even got so far, that server can't handle amount of data and leaks > some binary trash to the log. It may be because the server was built with GHC 7.6.3. Perhaps moving to some more recent version, such as 7.8.3, could solve the problem. It may also happen that is simply OS-specific, or the bug is in the server's code directly. What I can do for now is to rebuild the server with 7.8.3 and have the clients running with the old LLVM to get the same amount of data. > PS: I'm assuming the builder infrastructure as run by Gabor on his server is > still written in Haskell and compiled by GHC... Yes, that is right. Cheers, Gabor From simonpj at microsoft.com Wed Mar 4 12:04:47 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 4 Mar 2015 12:04:47 +0000 Subject: LLVM failures Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEBF101@DB3PRD3001MB020.064d.mgd.msft.net> These two LLVM tests are still failing consistently for me (on Linux). I think Austin said this should not happen, and he would fix, but I can't find the thread. Anyway, what should I do? Simon : You are using an old version of LLVM that isn't supported anymore! We will try though... /usr/bin/opt: /tmp/ghc60014_1/ghc60014_2.ll:7:6: error: expected type !0 = !{!"top", i8* null} Unexpected failures: llvm/should_compile T5681 [exit code non-0] (optllvm) llvm/should_compile T7571 [exit code non-0] (optllvm) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Mar 4 15:58:59 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 04 Mar 2015 16:58:59 +0100 Subject: LLVM failures In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEBF101@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEBF101@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1425484739.1937.4.camel@joachim-breitner.de> Dear Simon, Am Mittwoch, den 04.03.2015, 12:04 +0000 schrieb Simon Peyton Jones: > These two LLVM tests are still failing consistently for me (on Linux). > I think Austin said this should not happen, and he would fix, but I > can?t find the thread. Anyway, what should I do? it looks like you?ll need to install llvm-3.6. What distribution are you using, and what release of that in particular? (Usually, the output of "lsb_release -a" is the easiest way to find that out.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Wed Mar 4 16:03:56 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 4 Mar 2015 16:03:56 +0000 Subject: LLVM failures In-Reply-To: <1425484739.1937.4.camel@joachim-breitner.de> References: <618BE556AADD624C9C918AA5D5911BEF7BEBF101@DB3PRD3001MB020.064d.mgd.msft.net> <1425484739.1937.4.camel@joachim-breitner.de> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEBF881@DB3PRD3001MB020.064d.mgd.msft.net> bash$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 12.04.5 LTS Release: 12.04 Codename: precise | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Joachim Breitner | Sent: 04 March 2015 15:59 | To: ghc-devs at haskell.org | Subject: Re: LLVM failures | | Dear Simon, | | Am Mittwoch, den 04.03.2015, 12:04 +0000 schrieb Simon Peyton Jones: | > These two LLVM tests are still failing consistently for me (on | Linux). | > I think Austin said this should not happen, and he would fix, but I | > can?t find the thread. Anyway, what should I do? | | it looks like you?ll need to install llvm-3.6. | | What distribution are you using, and what release of that in | particular? | (Usually, the output of "lsb_release -a" is the easiest way to find | that | out.) | | | Greetings, | Joachim | | -- | Joachim ?nomeata? Breitner | mail at joachim-breitner.de ? http://www.joachim-breitner.de/ | Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F | Debian Developer: nomeata at debian.org From mail at joachim-breitner.de Wed Mar 4 16:42:24 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 04 Mar 2015 17:42:24 +0100 Subject: LLVM failures In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEBF881@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEBF101@DB3PRD3001MB020.064d.mgd.msft.net> <1425484739.1937.4.camel@joachim-breitner.de> <618BE556AADD624C9C918AA5D5911BEF7BEBF881@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1425487344.1937.9.camel@joachim-breitner.de> Dear Simon, Am Mittwoch, den 04.03.2015, 16:03 +0000 schrieb Simon Peyton Jones: > bash$ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 12.04.5 LTS > Release: 12.04 > Codename: precise in that case I suggest the following source for llvm-3.6, which is the same that we use on Travis (all commands to be run as root): First enable this repository to get a libstdc++ backport $ add-apt-repository -y ppa:ubuntu-toolchain-r/test Then add the llvm backports repository $ echo 'deb http://llvm.org/apt/precise/ llvm-toolchain-precise-3.6 main' >> /etc/apt/sources.list $ wget -O - http://llvm.org/apt/llvm-snapshot.gpg.key | sudo apt-key add - Then you can install the llvm package: $ apt-get update $ apt-get install llvm-3.6 Finally, you need to make sure that GHC?s configure finds these binaries, e.g. by extending your PATH. You probably know better where to put this in your configuration: export PATH=/usr/lib/llvm-3.6/bin:$PATH Greetings, Joachim -- Joachim Breitner e-Mail: mail at joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata at joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From george.colpitts at gmail.com Wed Mar 4 18:13:24 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 4 Mar 2015 14:13:24 -0400 Subject: LLVM failures In-Reply-To: <1425484739.1937.4.camel@joachim-breitner.de> References: <618BE556AADD624C9C918AA5D5911BEF7BEBF101@DB3PRD3001MB020.064d.mgd.msft.net> <1425484739.1937.4.camel@joachim-breitner.de> Message-ID: A side question, my understanding is that llvm-3.5 is the "official" llvm for ghc 7.10. Does anybody know if llvm-3.6 works with ghc 7.10? Regards George On Wed, Mar 4, 2015 at 11:58 AM, Joachim Breitner wrote: > Dear Simon, > > Am Mittwoch, den 04.03.2015, 12:04 +0000 schrieb Simon Peyton Jones: > > These two LLVM tests are still failing consistently for me (on Linux). > > I think Austin said this should not happen, and he would fix, but I > > can?t find the thread. Anyway, what should I do? > > it looks like you?ll need to install llvm-3.6. > > What distribution are you using, and what release of that in particular? > (Usually, the output of "lsb_release -a" is the easiest way to find that > out.) > > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Wed Mar 4 20:21:55 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 04 Mar 2015 15:21:55 -0500 Subject: LLVM failures In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7BEBF101@DB3PRD3001MB020.064d.mgd.msft.net> <1425484739.1937.4.camel@joachim-breitner.de> Message-ID: <878ufcfr8c.fsf@gmail.com> George Colpitts writes: > A side question, my understanding is that llvm-3.5 is the "official" llvm > for ghc 7.10. Does anybody know if llvm-3.6 works with ghc 7.10? > I'm afraid that we won't have support for LLVM 3.6 until GHC 7.12 due to non-backwards compatible syntax changes in LLVM's intermediate language. With GHC 7.12 we will have precisely one supported LLVM version which we will optionally ship with the GHC release. Depending upon timing this will be either LLVM 3.6 or 3.7. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mp2e at archlinux.us Thu Mar 5 03:40:30 2015 From: mp2e at archlinux.us (member MP2E) Date: Wed, 4 Mar 2015 19:40:30 -0800 Subject: Fwd: PSA: building HEAD with Nix/NixOS In-Reply-To: References: <87vbii9v0q.fsf@karetnikov.org> Message-ID: Looks great, thank you! One question however, in one of the lines you have this command: 'nix-build '' -A haskell-ng.compiler.ghcHEAD --run-env -I /home/user' Is nix-build supposed to be nix-shell? Usage afterwards seems to indicate that it is, but I'm not 100% sure. On Tue, Mar 3, 2015 at 3:32 AM, Nikita Karetnikov wrote: > I've just added instructions showing how easy it is to build GHC HEAD > and its dependencies with Nix/NixOS: > > > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#NixNixOS > > I hope someone finds them useful. > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pali.gabor at gmail.com Thu Mar 5 07:02:51 2015 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Thu, 5 Mar 2015 08:02:51 +0100 Subject: freebsd-amd64-head (FreeBSD/amd64 HEAD (Gabor Pali)), build 556, Success In-Reply-To: References: <54f680c6.0308c20a.4ed1.69e9@mx.google.com> <54F6C003.9010803@centrum.cz> Message-ID: 2015-03-04 11:47 GMT+01:00 P?li G?bor J?nos : > 2015-03-04 9:19 GMT+01:00 Karel Gardas : >> that server can't handle amount of data and leaks some binary trash to >> the log. > > What I can do for now is to rebuild the server with 7.8.3 and have the > clients running with the old LLVM to get the same amount of data. That was done yesterday (along with a restart), but apparently the problem still persists. I have also checked the posted file ("step.testsuite summary.output.txt") and it is placed to the web site without any glitches, so perhaps the bug is somewhere in the mailer. The attached files are translated to base64, which is probably implemented by Ian's original base64-string package [1] and that is what goes wrong. I will study the code further. [1] http://hackage.haskell.org/package/base64-string From mail at joachim-breitner.de Thu Mar 5 19:34:51 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 05 Mar 2015 20:34:51 +0100 Subject: Hoopl advice: How to extend the graph? Message-ID: <1425584091.13902.7.camel@joachim-breitner.de> Dear devs, I haven?t worked with our Cmm representation before, so I have a beginner question: What function I should reach for when I want to look at each block (or each Last node) in an CmmGraph, possibly modifying it and possibly adding auxillary nodes on the way? It seems that one could use dataflowPassFwd for it, but * I could not find any use of it, and * I do not need to run an analysis along, I just want to rewrite the blocks, so I am not sure if this is the right thing. Any pointers? Thanks, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jan.stolarek at p.lodz.pl Thu Mar 5 22:05:26 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 5 Mar 2015 23:05:26 +0100 Subject: Hoopl advice: How to extend the graph? In-Reply-To: <1425584091.13902.7.camel@joachim-breitner.de> References: <1425584091.13902.7.camel@joachim-breitner.de> Message-ID: <201503052305.26876.jan.stolarek@p.lodz.pl> > What function I should reach for when I want to look at each block (or > each Last node) in an CmmGraph, possibly modifying it and possibly > adding auxillary nodes on the way? Take a look at Compiler.Hoopl.Block in hoopl library - it has some useful functions for working on blocks. blockSplitTail might be what you're looking for if you want to look at the last block. If you want to look at each block in a graph you most likely need postorderDfs from CmmUtils. I suggest studying one of existing Cmm passes to see how to traverse a Cmm graph and operate on it. CmmContFlowOpt seems to be a good candidate - good comments, fairly short, uses many functions that you should learn if you want to work with Cmm. > It seems that one could use dataflowPassFwd for it, but > * I could not find any use of it, and > * I do not need to run an analysis along, I just want to rewrite > the blocks, > so I am not sure if this is the right thing. You most likely don't want to use Hoopl's machinery for doing analyses and optimisation passes. From what I know Hoopl is very slow compared to hand-written graph traversals and transformations - Edward's CmmRewriteAssignments is a good example here [1]. Does that help? Janek [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Hoopl/Examples --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From mail at joachim-breitner.de Thu Mar 5 22:24:41 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 05 Mar 2015 23:24:41 +0100 Subject: Hoopl advice: How to extend the graph? In-Reply-To: <201503052305.26876.jan.stolarek@p.lodz.pl> References: <1425584091.13902.7.camel@joachim-breitner.de> <201503052305.26876.jan.stolarek@p.lodz.pl> Message-ID: <1425594281.13902.23.camel@joachim-breitner.de> Hi, Am Donnerstag, den 05.03.2015, 23:05 +0100 schrieb Jan Stolarek: > > What function I should reach for when I want to look at each block (or > > each Last node) in an CmmGraph, possibly modifying it and possibly > > adding auxillary nodes on the way? > > Take a look at Compiler.Hoopl.Block in hoopl library - it has some useful functions for working on > blocks. blockSplitTail might be what you're looking for if you want to look at the last block. > If > you want to look at each block in a graph you most likely need postorderDfs from CmmUtils. I > suggest studying one of existing Cmm passes to see how to traverse a Cmm graph and operate on it. > CmmContFlowOpt seems to be a good candidate - good comments, fairly short, uses many functions > that you should learn if you want to work with Cmm. I had a look around, of course. CmmContFlowOpt is not quite a good example, as it does not generate new blocks (quite obvious from the fact that there is no UniqSM around to generate the new labels). Looking at CmmUtils, I guess I could just use ofBlockList entry . concatMap myPerBlockOperation . toBlockList I was expecting something a bit higher level, but maybe it?s that simple :-) Thanks! Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jan.stolarek at p.lodz.pl Fri Mar 6 06:46:20 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 6 Mar 2015 07:46:20 +0100 Subject: Hoopl advice: How to extend the graph? In-Reply-To: <1425594281.13902.23.camel@joachim-breitner.de> References: <1425584091.13902.7.camel@joachim-breitner.de> <201503052305.26876.jan.stolarek@p.lodz.pl> <1425594281.13902.23.camel@joachim-breitner.de> Message-ID: <201503060746.20911.jan.stolarek@p.lodz.pl> > I had a look around, of course. CmmContFlowOpt is not quite a good > example, as it does not generate new blocks (quite obvious from the fact > that there is no UniqSM around to generate the new labels). It generates new blocks from exisiting ones so I thought that qualifies. But if not then CmmProcPoints gives an example of generating new labels. (You probably noticed that already.) > Looking at CmmUtils, I guess I could just use > ofBlockList entry . concatMap myPerBlockOperation . toBlockList Hard to say without actually seeing rest of the code. Use what works and once the patch is on Phab we can work on improving it :-) Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From mail at joachim-breitner.de Fri Mar 6 08:34:12 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 06 Mar 2015 09:34:12 +0100 Subject: Hoopl advice: How to extend the graph? In-Reply-To: <201503060746.20911.jan.stolarek@p.lodz.pl> References: <1425584091.13902.7.camel@joachim-breitner.de> <201503052305.26876.jan.stolarek@p.lodz.pl> <1425594281.13902.23.camel@joachim-breitner.de> <201503060746.20911.jan.stolarek@p.lodz.pl> Message-ID: <1425630852.1335.1.camel@joachim-breitner.de> Hi, Am Freitag, den 06.03.2015, 07:46 +0100 schrieb Jan Stolarek: > > Looking at CmmUtils, I guess I could just use > > ofBlockList entry . concatMap myPerBlockOperation . toBlockList > Hard to say without actually seeing rest of the code. Use what works and once the patch is on Phab > we can work on improving it :-) will do ? thanks! Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Fri Mar 6 08:37:46 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Mar 2015 08:37:46 +0000 Subject: [Diffusion] [Build Failed] rGHCb833bc2767d7: User manual section to document the principles of kind inference In-Reply-To: <20150305230056.9666.60040@phabricator.haskell.org> References: <20150305230056.9666.60040@phabricator.haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BED8022@DBXPRD3001MB024.064d.mgd.msft.net> Guys I'm seeing this validate failures on TH_Roles2 -Dependent packages: [array-0.5.0.1, base-4.8.0.0, deepseq-1.4.0.0, +Dependent packages: [array-0.5.0.1, base-4.8.0.0, deepseq-1.4.1.0, And similarly safePkg01 -package dependencies: array-0.5.0.1 base-4.8.0.0 bytestring-0.10.5.0* deepseq-1.4.0.0 ghc-prim-0.3.1.0 integer-gmp-0.5.1.0 +package dependencies: array-0.5.0.1 base-4.8.0.0 bytestring-0.10.6.0* deepseq-1.4.1.0 ghc-prim-0.3.1.0 integer-gmp-1.0. Could someone fix? Do we want tests that depend on version numbers in this fragile way. They are almost bound to fail repeatedly over time. Simon | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 05 March 2015 23:03 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCb833bc2767d7: User manual section | to document the principles of kind inference | | Harbormaster failed to build B3285: rGHCb833bc2767d7: User manual section | to document the principles of kind inference! | | USERS | simonpj (Author) | GHC - Documentation (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCb833bc2767d7 | | REPLY HANDLER ACTIONS | Reply to comment. | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Documentation From austin at well-typed.com Fri Mar 6 18:11:31 2015 From: austin at well-typed.com (Austin Seipp) Date: Fri, 6 Mar 2015 12:11:31 -0600 Subject: [Diffusion] [Build Failed] rGHCb833bc2767d7: User manual section to document the principles of kind inference In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BED8022@DBXPRD3001MB024.064d.mgd.msft.net> References: <20150305230056.9666.60040@phabricator.haskell.org> <618BE556AADD624C9C918AA5D5911BEF7BED8022@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: I pushed a fix, but I agree this is annoying. Perhaps the testsuite 'scrubber' should try to handle things like this too (does anyone want to write a patch?) On Fri, Mar 6, 2015 at 2:37 AM, Simon Peyton Jones wrote: > Guys > > I'm seeing this validate failures on TH_Roles2 > > -Dependent packages: [array-0.5.0.1, base-4.8.0.0, deepseq-1.4.0.0, > +Dependent packages: [array-0.5.0.1, base-4.8.0.0, deepseq-1.4.1.0, > > And similarly safePkg01 > -package dependencies: array-0.5.0.1 base-4.8.0.0 bytestring-0.10.5.0* deepseq-1.4.0.0 ghc-prim-0.3.1.0 integer-gmp-0.5.1.0 > +package dependencies: array-0.5.0.1 base-4.8.0.0 bytestring-0.10.6.0* deepseq-1.4.1.0 ghc-prim-0.3.1.0 integer-gmp-1.0. > > Could someone fix? > > Do we want tests that depend on version numbers in this fragile way. They are almost bound to fail repeatedly over time. > > Simon > > | -----Original Message----- > | From: noreply at phabricator.haskell.org > | [mailto:noreply at phabricator.haskell.org] > | Sent: 05 March 2015 23:03 > | To: Simon Peyton Jones > | Subject: [Diffusion] [Build Failed] rGHCb833bc2767d7: User manual section > | to document the principles of kind inference > | > | Harbormaster failed to build B3285: rGHCb833bc2767d7: User manual section > | to document the principles of kind inference! > | > | USERS > | simonpj (Author) > | GHC - Documentation (Auditor) > | > | COMMIT > | https://phabricator.haskell.org/rGHCb833bc2767d7 > | > | REPLY HANDLER ACTIONS > | Reply to comment. > | > | EMAIL PREFERENCES > | https://phabricator.haskell.org/settings/panel/emailpreferences/ > | > | To: simonpj, GHC - Documentation > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From karel.gardas at centrum.cz Sat Mar 7 10:49:53 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat, 07 Mar 2015 11:49:53 +0100 Subject: How to better parallelize GHC build. Message-ID: <54FAD7D1.1050101@centrum.cz> Folks, first of all, I remember someone already mentioned issue with decreased parallelism of the GHC build recently somewhere but I cann't find it now. Sorry, for that since otherwise I would use this thread if it was on this mailing list. Anyway, while working on SPARC NCG I'm using T2000 which provides 32 threads/8 core UltraSPARC T1 CPU. The property of this machine is that it's really slow on single-threaded work. To squeeze some perf from it man really needs to push 32 threads of work on it. Now, it really hurts my nerves to see it's lazy building/running just one or two ghc processes. To verify the fact I've created simple script to collect number of ghc processes over time and putting this to graph. The result is in the attached picture. The graph is result of running: gmake -j64 anyway, the average number of running ghc processes is 4.4 and the median value is 2. IMHO such low number not only hurts build times on something like CMT SPARC machine, but also on let say a cluster of ARM machines using NFS and also on common engineering workstations which provide these days (IMHO!) around 8-16 cores (and double the threads number). My naive idea(s) for fixing this issue is (I'm assuming no Haskell file imports unused imports here, but perhaps this may be also investigated): 1) provide explicit dependencies which guides make to build in more optimal way 2) hack GHC's make depend to kind of compute explicit dependencies from (1) in an optimal way automatically 3) someone already mentioned using shake for building ghc. I don't know shake but perhaps this is the right direction? 4) hack GHC to compile needed hi file directly in its memory if hi file is not (yet!) available (issue how to get compiling options right here). Also I don't know hi file semantics yet so bear with me on this. Is there anything else which may be done to fix that issue? Is someone already working on some of those? (I mean those reasonable from the list)? Thanks! Karel -------------- next part -------------- A non-text attachment was scrubbed... Name: ghc-build.jpg Type: image/jpeg Size: 58003 bytes Desc: not available URL: From hvriedel at gmail.com Sat Mar 7 11:09:01 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 07 Mar 2015 12:09:01 +0100 Subject: How to better parallelize GHC build. In-Reply-To: <54FAD7D1.1050101@centrum.cz> (Karel Gardas's message of "Sat, 07 Mar 2015 11:49:53 +0100") References: <54FAD7D1.1050101@centrum.cz> Message-ID: <87bnk52hf6.fsf@gmail.com> On 2015-03-07 at 11:49:53 +0100, Karel Gardas wrote: [...] > Is there anything else which may be done to fix that issue? Is someone > already working on some of those? (I mean those reasonable from the > list)? are you aware of https://ghc.haskell.org/trac/ghc/wiki/Building/Shake and https://github.com/snowleopard/shaking-up-ghc ? Cheers, hvr From karel.gardas at centrum.cz Sat Mar 7 11:24:11 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat, 07 Mar 2015 12:24:11 +0100 Subject: How to better parallelize GHC build. In-Reply-To: <87bnk52hf6.fsf@gmail.com> References: <54FAD7D1.1050101@centrum.cz> <87bnk52hf6.fsf@gmail.com> Message-ID: <54FADFDB.1090409@centrum.cz> On 03/ 7/15 12:09 PM, Herbert Valerio Riedel wrote: > On 2015-03-07 at 11:49:53 +0100, Karel Gardas wrote: > > [...] > >> Is there anything else which may be done to fix that issue? Is someone >> already working on some of those? (I mean those reasonable from the >> list)? > > are you aware of > > https://ghc.haskell.org/trac/ghc/wiki/Building/Shake > > and > > https://github.com/snowleopard/shaking-up-ghc > ? I am. Is this agreed way among the GHC developers? I was not sure so I mentioned shake just lightly... Thanks, Karel From ezyang at mit.edu Sat Mar 7 19:29:50 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 07 Mar 2015 11:29:50 -0800 Subject: Spurious harbormaster failures Message-ID: <1425756494-sup-7381@sabre> Here is a recent Harbormaster build, where the validate succeeded, but after the storage failed. https://phabricator.haskell.org/harbormaster/build/3329/ Edward From austin at well-typed.com Sat Mar 7 19:34:11 2015 From: austin at well-typed.com (Austin Seipp) Date: Sat, 7 Mar 2015 13:34:11 -0600 Subject: Spurious harbormaster failures In-Reply-To: <1425756494-sup-7381@sabre> References: <1425756494-sup-7381@sabre> Message-ID: There was actually a misconfiguration of the disk storage that I fixed morning that caused this, I think; some other commits etc failed - I've since restarted the builds and they've worked. I've fixed this (hopefully for good this time), so we'll wait and see. On Sat, Mar 7, 2015 at 1:29 PM, Edward Z. Yang wrote: > Here is a recent Harbormaster build, where the validate > succeeded, but after the storage failed. > > https://phabricator.haskell.org/harbormaster/build/3329/ > > Edward > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From ndmitchell at gmail.com Sun Mar 8 13:58:48 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun, 8 Mar 2015 13:58:48 +0000 Subject: How to better parallelize GHC build. In-Reply-To: <54FADFDB.1090409@centrum.cz> References: <54FAD7D1.1050101@centrum.cz> <87bnk52hf6.fsf@gmail.com> <54FADFDB.1090409@centrum.cz> Message-ID: Hi Karel, > I am. Is this agreed way among the GHC developers? I was not sure so I > mentioned shake just lightly... It's certainly agreed to give it a go, and implementation work is ongoing. If it works better than the existing system then I suspect we'll switch. I certainly hope to get full parallelism, although I don't have as many core as you do to test! Thanks, Neil From hvriedel at gmail.com Mon Mar 9 08:05:12 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 09 Mar 2015 09:05:12 +0100 Subject: HEADS-UP: new Git hook linters for whitespace & commit msgs Message-ID: <87vbiad29z.fsf@gmail.com> Hello GHC devs, I finally got to finish reworked Git hook validations[1] which are active effective immediately for the ghc.git repo: - A new whitespace linter that enforces 3 separate in variants for files with the suffixes .hs .hsc .lhs .cabal .c .h .lhs-boot .hs-boot .x .y the 3 invariants (i.e. if the particular invariant held before the commit, it ought to hold afterwards as well): 1. no TABs 2. no trailing whitespaces (NEW) 3. no missing final EOL (NEW) - A new commit msg linter The rationale is explained in http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html TLDR: The structural conventions enforced by the new linter avoid messing up the output of Git tooling; Editors with support for commit-msg syntax-coloring like Vim or Emacs also follow these conventions. This linter has soft (-> warnings) and hard limits (-> error/rejection) The most important hard limits are: - subject line (i.e. 1st line) 80-char max length (& 8-chars min len) - 2nd line must be empty (if it exists) - body lines (i.e. 3rd+ lines) 100-char max length For more details about additional checks see actual code in [1]; the linter tries to give verbose error/warning messages and pointing exactly to the offending lines. Comments/suggestions/debate/pull-requests/etc welcome! PS: the new validators can easily be tested locally on a Git tree (although I've only tested this on Linux): usage: validate-whitespace [+] and you can pass symbolic refs such as 'HEAD' for the , e.g. validate-whitespace ~/Work/ghc-tree/.git HEAD Cheers, hvr [1]: https://github.com/haskell-infra/git-haskell-org-hooks/tree/master/src From karel.gardas at centrum.cz Mon Mar 9 10:42:34 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 09 Mar 2015 11:42:34 +0100 Subject: How to better parallelize GHC build In-Reply-To: <39238FF58F4F9F40B1CA150783A6F0BF0B00E3F4@EXMBDB01.campus.ncl.ac.uk> References: <39238FF58F4F9F40B1CA150783A6F0BF0B00E3F4@EXMBDB01.campus.ncl.ac.uk> Message-ID: <54FD791A.9020506@centrum.cz> Hi Andrey, great to hear that you will find some time for Shaking ghc in the near future and even that you aim to commit first version around April. This is just in a month and half time. Great! I'll see what it will brings us, certainly will test it's paralellization capability and will report. BTW: I've already tested that, but it looks like it counts with ghc-stage1 compiler being already built so I guess this is just a first step with the idea to shake some ghc library... Thanks! Karel On 03/ 7/15 11:56 PM, Andrey Mokhov wrote: > Hi Karel, > > One of the main goals of the Shaking up GHC project is getting all the dependencies right, which should allow for more parallelism. (Another, and perhaps even more important goal is to make the build system comprehensible/easier to maintain.) > > The project is currently interrupted as I had to return to my university job for a period of time, but the aim is to push the first working version to the GHC tree around April. > > Regards, > Andrey > >>> [...] >>> >>>> Is there anything else which may be done to fix that issue? Is someone >>>> already working on some of those? (I mean those reasonable from the >>>> list)? >>> >>> are you aware of >>> >>> https://ghc.haskell.org/trac/ghc/wiki/Building/Shake >>> >>> and >>> >>> https://github.com/snowleopard/shaking-up-ghc >>> ? >> >> I am. Is this agreed way among the GHC developers? I was not sure so I >> mentioned shake just lightly... >> >> Thanks, >> Karel >> > > From karel.gardas at centrum.cz Mon Mar 9 10:48:55 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 09 Mar 2015 11:48:55 +0100 Subject: How to better parallelize GHC build. In-Reply-To: References: <54FAD7D1.1050101@centrum.cz> <87bnk52hf6.fsf@gmail.com> <54FADFDB.1090409@centrum.cz> Message-ID: <54FD7A97.2030308@centrum.cz> Hi Neil, On 03/ 8/15 02:58 PM, Neil Mitchell wrote: > Hi Karel, > >> I am. Is this agreed way among the GHC developers? I was not sure so I >> mentioned shake just lightly... > > It's certainly agreed to give it a go, and implementation work is > ongoing. If it works better than the existing system then I suspect > we'll switch. I certainly hope to get full parallelism, although I > don't have as many core as you do to test! I've investigated for short time stage1 dependencies and what make does with them and so far had not found any issue which may be fixed by hand added dependency into the makefile build system. For example one of the biggest issue in stage1 is excessive dependency on DynFlags at least. Anyway, I'll see what shake/ghc brings to the table -- perhaps I've not looked that well and there is a way to solve that... Anyway, idea of separate compilation of interface files still comes to my head as a nice experiment to do. Thanks, Karel From ggreif at gmail.com Mon Mar 9 11:09:24 2015 From: ggreif at gmail.com (Gabor Greif) Date: Mon, 9 Mar 2015 12:09:24 +0100 Subject: Pattern matching and GADTs In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEBDD75@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEBC2AF@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF7BEBDD75@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On 3/3/15, Simon Peyton Jones wrote: > > | data Bar a where > | Listy :: Bar [Int] > | > | {- > | foo :: a -> Bar a -> Int > | foo [0] Listy = 1 > > Well you'd get a seg-fault from the call (foo True (undefined :: Bar > [Int])). So we really MUST match the (Bar a) arg before the 'a' arg. And Oh, okay, I see! But you surely mean (foo True (undefined :: Bar Bool)) > Haskell only offers one way to do that, which is to put it first. > > You don't have to change the argument order. Write > > foo xs Listy | [0] <- xs = 1 Yeah, this is what I gave as foo'' in my examples. What about making an irrefutable pattern match? {{{ foo :: a -> Bar a -> Int foo ~[a] Listy = a }}} While I guess this won't SEGV, it may error with a pattern match failure. Besides, the type-checker won't let us: Couldn't match expected type `a' with actual type `[a0]' `a' is a rigid type variable bound by the type signature for: foo :: a -> Bar a -> Int So the pattern guard solution looks like our best option to fix the ordering issue. Thanks, Gabor > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gabor > | Greif > | Sent: 03 March 2015 14:13 > | To: ghc-devs at haskell.org > | Subject: Re: Pattern matching and GADTs > | > | This might be off-topic for your paper, but possibly relevant for GADT- > | based programming: > | > | In the below snippet > | ----------------------------------------------------------------- > | {-# LANGUAGE GADTs, PatternGuards #-} > | > | data Bar a where > | Listy :: Bar [Int] > | > | {- > | foo :: a -> Bar a -> Int > | foo [0] Listy = 1 > | > | gadtTest.hs:8:5: > | Couldn't match expected type `a' with actual type `[a0]' > | `a' is a rigid type variable bound by > | the type signature for: foo :: a -> Bar a -> Int > | at /home/ggreif/gadtTest.hs:7:8 > | Relevant bindings include > | foo :: a -> Bar a -> Int (bound at /home/ggreif/gadtTest.hs:8:1) > | In the pattern: [0] > | In an equation for `foo': foo [0] Listy = 1 -} > | > | foo' :: Bar a -> a -> Int > | foo' Listy [a] = a > | > | foo'' :: a -> Bar a -> Int > | foo'' l Listy | [a] <- l = a > | ----------------------------------------------------------------- > | > | the "wrong" order of pattern matches (i.e. foo) causes an error, the > | flipped order works (i.e. foo') and pattern guards remedy the situation > | (e.g. foo''). > | > | Since the type signatures are isomorphic this is a bit disturbing. Why > | is it like this? > | My guess is that patterns are matched left-to-right and refinements > | become available "too late". Or is the reason buried in the OutsideIn > | algorithm (and function arrow associativity: a -> (Bar a -> Int)) ? > | > | Would it be a big deal to forward-propagate type information in from > | GADT pattern matches? > | > | Thanks and cheers, > | > | Gabor > | > | On 3/2/15, Simon Peyton Jones wrote: > | > GHC developers > | > You may be interested in this paper, submitted to ICFP GADTs meet > | > their match: pattern-matching warnings that account for GADTs, > | guards, > | > and > | > laziness | match > | > ing>, with Georgios Karachalias, Tom Schrijvers, and Dimitrios > | > Vytiniotis. > | > It describes a GADT-aware algorithm for detecting missing and > | > redundant patterns. > | > The implementation is not yet up to production quality, but it will > | be! > | > If you feel able to give us any feedback about the paper itself, that > | > would be incredibly useful. Thanks Simon > | > > | > > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From simonpj at microsoft.com Mon Mar 9 13:11:01 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 9 Mar 2015 13:11:01 +0000 Subject: HEADS-UP: new Git hook linters for whitespace & commit msgs In-Reply-To: <87vbiad29z.fsf@gmail.com> References: <87vbiad29z.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEF2F76@DB3PRD3001MB020.064d.mgd.msft.net> Great. Are these invariants documented on the GHC developers wiki? This email will soon be lost, but the wiki lives. Thanks Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Herbert | Valerio Riedel | Sent: 09 March 2015 08:05 | To: ghc-devs | Subject: HEADS-UP: new Git hook linters for whitespace & commit msgs | | Hello GHC devs, | | I finally got to finish reworked Git hook validations[1] which are | active effective immediately for the ghc.git repo: | | - A new whitespace linter that enforces 3 separate in variants for files | with the suffixes | | .hs .hsc .lhs .cabal .c .h .lhs-boot .hs-boot .x .y | | the 3 invariants (i.e. if the particular invariant held before the | commit, it ought to hold afterwards as well): | | 1. no TABs | 2. no trailing whitespaces (NEW) | 3. no missing final EOL (NEW) | | | - A new commit msg linter | | The rationale is explained in | http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html | | TLDR: The structural conventions enforced by the new linter avoid | messing up the output of Git tooling; Editors with support for | commit-msg syntax-coloring like Vim or Emacs also follow these | conventions. | | This linter has soft (-> warnings) and hard limits (-> | error/rejection) | | The most important hard limits are: | | - subject line (i.e. 1st line) 80-char max length (& 8-chars min len) | - 2nd line must be empty (if it exists) | - body lines (i.e. 3rd+ lines) 100-char max length | | For more details about additional checks see actual code in [1]; the | linter tries to give verbose error/warning messages and pointing | exactly to the offending lines. | | | Comments/suggestions/debate/pull-requests/etc welcome! | | | PS: the new validators can easily be tested locally on a Git tree | (although I've only tested this on Linux): | | usage: validate-whitespace [+] | | and you can pass symbolic refs such as 'HEAD' for the , | e.g. | | validate-whitespace ~/Work/ghc-tree/.git HEAD | | | Cheers, | hvr | | [1]: https://github.com/haskell-infra/git-haskell-org- | hooks/tree/master/src | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Mar 9 13:11:03 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 9 Mar 2015 13:11:03 +0000 Subject: How to better parallelize GHC build. In-Reply-To: <54FAD7D1.1050101@centrum.cz> References: <54FAD7D1.1050101@centrum.cz> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEF2FC9@DB3PRD3001MB020.064d.mgd.msft.net> As Neil says, I'm hoping that the new Shake-based build system will make a big difference. It's not certain that we'll switch to it, but I very much hope that we will. Fortunately we can work it side-by-side with the old system, so I hope it'll just be a question of switching over because it is manifestly better. Andrey can give a status report. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Karel | Gardas | Sent: 07 March 2015 10:50 | To: ghc-devs | Subject: How to better parallelize GHC build. | | | Folks, | | first of all, I remember someone already mentioned issue with decreased | parallelism of the GHC build recently somewhere but I cann't find it | now. Sorry, for that since otherwise I would use this thread if it was | on this mailing list. | | Anyway, while working on SPARC NCG I'm using T2000 which provides 32 | threads/8 core UltraSPARC T1 CPU. The property of this machine is that | it's really slow on single-threaded work. To squeeze some perf from it | man really needs to push 32 threads of work on it. Now, it really hurts | my nerves to see it's lazy building/running just one or two ghc | processes. To verify the fact I've created simple script to collect | number of ghc processes over time and putting this to graph. The result | is in the attached picture. The graph is result of running: | | gmake -j64 | | anyway, the average number of running ghc processes is 4.4 and the | median value is 2. IMHO such low number not only hurts build times on | something like CMT SPARC machine, but also on let say a cluster of ARM | machines using NFS and also on common engineering workstations which | provide these days (IMHO!) around 8-16 cores (and double the threads | number). | | My naive idea(s) for fixing this issue is (I'm assuming no Haskell file | imports unused imports here, but perhaps this may be also investigated): | | 1) provide explicit dependencies which guides make to build in more | optimal way | | 2) hack GHC's make depend to kind of compute explicit dependencies from | (1) in an optimal way automatically | | 3) someone already mentioned using shake for building ghc. I don't know | shake but perhaps this is the right direction? | | 4) hack GHC to compile needed hi file directly in its memory if hi file | is not (yet!) available (issue how to get compiling options right here). | Also I don't know hi file semantics yet so bear with me on this. | | | Is there anything else which may be done to fix that issue? Is someone | already working on some of those? (I mean those reasonable from the | list)? | | Thanks! | Karel From simonpj at microsoft.com Mon Mar 9 13:24:57 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 9 Mar 2015 13:24:57 +0000 Subject: Pattern matching and GADTs In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7BEBC2AF@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF7BEBDD75@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEF427E@DB3PRD3001MB020.064d.mgd.msft.net> | Yeah, this is what I gave as foo'' in my examples. What about making an | irrefutable pattern match? | | {{{ | foo :: a -> Bar a -> Int | foo ~[a] Listy = a | }}} Yes that's attractive, but you have do to strictness analysis to find out when the pattern is forced. E.g. foo ~[x] (True <- f x) Listy = x Is this ok? Well, if f is strict in 'x' it's not ok. But if 'f' is lazy, the it'd be fine. I don't want type correctness to depend on strictness analysis. Simon | While I guess this won't SEGV, it may error with a pattern match | failure. Besides, the type-checker won't let us: | | Couldn't match expected type `a' with actual type `[a0]' | `a' is a rigid type variable bound by | the type signature for: foo :: a -> Bar a -> Int | | So the pattern guard solution looks like our best option to fix the | ordering issue. | | Thanks, | | Gabor | | > | > Simon | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | > | Gabor Greif | > | Sent: 03 March 2015 14:13 | > | To: ghc-devs at haskell.org | > | Subject: Re: Pattern matching and GADTs | > | | > | This might be off-topic for your paper, but possibly relevant for | > | GADT- based programming: | > | | > | In the below snippet | > | ----------------------------------------------------------------- | > | {-# LANGUAGE GADTs, PatternGuards #-} | > | | > | data Bar a where | > | Listy :: Bar [Int] | > | | > | {- | > | foo :: a -> Bar a -> Int | > | foo [0] Listy = 1 | > | | > | gadtTest.hs:8:5: | > | Couldn't match expected type `a' with actual type `[a0]' | > | `a' is a rigid type variable bound by | > | the type signature for: foo :: a -> Bar a -> Int | > | at /home/ggreif/gadtTest.hs:7:8 | > | Relevant bindings include | > | foo :: a -> Bar a -> Int (bound at | /home/ggreif/gadtTest.hs:8:1) | > | In the pattern: [0] | > | In an equation for `foo': foo [0] Listy = 1 -} | > | | > | foo' :: Bar a -> a -> Int | > | foo' Listy [a] = a | > | | > | foo'' :: a -> Bar a -> Int | > | foo'' l Listy | [a] <- l = a | > | ----------------------------------------------------------------- | > | | > | the "wrong" order of pattern matches (i.e. foo) causes an error, | > | the flipped order works (i.e. foo') and pattern guards remedy the | > | situation (e.g. foo''). | > | | > | Since the type signatures are isomorphic this is a bit disturbing. | > | Why is it like this? | > | My guess is that patterns are matched left-to-right and | refinements | > | become available "too late". Or is the reason buried in the | > | OutsideIn algorithm (and function arrow associativity: a -> (Bar a | -> Int)) ? | > | | > | Would it be a big deal to forward-propagate type information in | > | from GADT pattern matches? | > | | > | Thanks and cheers, | > | | > | Gabor | > | | > | On 3/2/15, Simon Peyton Jones wrote: | > | > GHC developers | > | > You may be interested in this paper, submitted to ICFP GADTs | meet | > | > their match: pattern-matching warnings that account for GADTs, | > | guards, > and > | > | laziness | match | > | > ing>, with Georgios Karachalias, Tom Schrijvers, and Dimitrios | > | > | Vytiniotis. | > | > It describes a GADT-aware algorithm for detecting missing and > | > | redundant patterns. | > | > The implementation is not yet up to production quality, but it | > | will be! | > | > If you feel able to give us any feedback about the paper itself, | > | that > would be incredibly useful. Thanks Simon > > | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > From simonpj at microsoft.com Mon Mar 9 14:27:06 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 9 Mar 2015 14:27:06 +0000 Subject: Trac slow again Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEF46A5@DB3PRD3001MB020.064d.mgd.msft.net> Is it just me, or is GHC's Trac taking multiple seconds just to serve up a web page? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Mar 9 15:04:10 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 9 Mar 2015 16:04:10 +0100 Subject: Trac slow again In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEF46A5@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEF46A5@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <201503091604.11080.jan.stolarek@p.lodz.pl> > Is it just me, or is GHC's Trac taking multiple seconds just to serve up a > web page? Same problem here. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From ezyang at mit.edu Mon Mar 9 18:58:28 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 09 Mar 2015 11:58:28 -0700 Subject: HEADS-UP: new Git hook linters for whitespace & commit msgs In-Reply-To: <87vbiad29z.fsf@gmail.com> References: <87vbiad29z.fsf@gmail.com> Message-ID: <1425927372-sup-8068@sabre> Hello Herbert, I tried to push today and I noticed that there is an unfortunate interaction between Arcanist's commit rewriting and the Signed-off-by hook, which requires the Signed-off-by line to be on a new-line by itself. The problem is Arcanist, by default, rewrites a one line commit message to: This is my first line Summary: Signed-off-by: Edward <... at ...> which fails lint. This is pretty annoying; can we relax the lint check or get arc to stop messing this up? Edward Excerpts from Herbert Valerio Riedel's message of 2015-03-09 01:05:12 -0700: > Hello GHC devs, > > I finally got to finish reworked Git hook validations[1] which are > active effective immediately for the ghc.git repo: > > - A new whitespace linter that enforces 3 separate in variants for files > with the suffixes > > .hs .hsc .lhs .cabal .c .h .lhs-boot .hs-boot .x .y > > the 3 invariants (i.e. if the particular invariant held before the > commit, it ought to hold afterwards as well): > > 1. no TABs > 2. no trailing whitespaces (NEW) > 3. no missing final EOL (NEW) > > > - A new commit msg linter > > The rationale is explained in > http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html > > TLDR: The structural conventions enforced by the new linter avoid > messing up the output of Git tooling; Editors with support for > commit-msg syntax-coloring like Vim or Emacs also follow these > conventions. > > This linter has soft (-> warnings) and hard limits (-> > error/rejection) > > The most important hard limits are: > > - subject line (i.e. 1st line) 80-char max length (& 8-chars min len) > - 2nd line must be empty (if it exists) > - body lines (i.e. 3rd+ lines) 100-char max length > > For more details about additional checks see actual code in [1]; the > linter tries to give verbose error/warning messages and pointing > exactly to the offending lines. > > > Comments/suggestions/debate/pull-requests/etc welcome! > > > PS: the new validators can easily be tested locally on a Git tree > (although I've only tested this on Linux): > > usage: validate-whitespace [+] > > and you can pass symbolic refs such as 'HEAD' for the , > e.g. > > validate-whitespace ~/Work/ghc-tree/.git HEAD > > > Cheers, > hvr > > [1]: https://github.com/haskell-infra/git-haskell-org-hooks/tree/master/src From hvriedel at gmail.com Mon Mar 9 21:32:15 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 09 Mar 2015 22:32:15 +0100 Subject: HEADS-UP: new Git hook linters for whitespace & commit msgs In-Reply-To: <1425927372-sup-8068@sabre> (Edward Z. Yang's message of "Mon, 09 Mar 2015 11:58:28 -0700") References: <87vbiad29z.fsf@gmail.com> <1425927372-sup-8068@sabre> Message-ID: <87egoxdfhc.fsf@gmail.com> Hi Edward, On 2015-03-09 at 19:58:28 +0100, Edward Z. Yang wrote: > I tried to push today and I noticed that there is an unfortunate > interaction between Arcanist's commit rewriting and the Signed-off-by > hook, which requires the Signed-off-by line to be on a new-line by > itself. The problem is Arcanist, by default, rewrites a one line > commit message to: > > This is my first line > > Summary: Signed-off-by: Edward <... at ...> > > which fails lint. > > This is pretty annoying; can we relax the lint check or get arc to > stop messing this up? I'd *love* to get Arcanist to stop blatantly violating Git's commit msg conventions. For starters, it violates Git's property-trailer syntax convention which requires whitespace-free headings, like 'Reviewed-by:' rather than 'Reviewed By:', c.f. http://git-htmldocs.googlecode.com/git/git-interpret-trailers.html and https://git.wiki.kernel.org/index.php/CommitMessageConventions Otoh, the 'Summary:' "trailer" emitted by Arcanist is completely superfluous and conveys no useful information, but more importantly results in ugly Git commit messages because now the commit msg body always starts with that redundant 'Summary: '-prologue (which then can break the 'Signed-off-by:'-trailer like in your case, causing tooling not to recognize it anymore -- that's why I added that specific lint-check). Cheers, hvr From carter.schonwald at gmail.com Tue Mar 10 02:09:47 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 9 Mar 2015 22:09:47 -0400 Subject: [Haskell-cafe] ghc -O2 out of memory In-Reply-To: <006c01d05a40$e800fcd0$b802f670$@lijbrandt.nl> References: <000001d058ef$45451e10$cfcf5a30$@lijbrandt.nl> <006c01d05a40$e800fcd0$b802f670$@lijbrandt.nl> Message-ID: there SHOULD be a 32bit 7.8.4 build available somewhere for windows, and if not , thats a real problem! I'm gonna shift this thread to ghc-devs, because that *should* get addressed @ghc-devs, how can we help this user get ahold of a 32bit windows 7.8.4 build? (eg, why do we not have one available yet?) -Carter On Mon, Mar 9, 2015 at 4:13 AM, Kees Bleijenberg wrote: > Thanks for your answer. > > I also use ghc to create 32 bits dll?s. 7.8.4 is 64 bits GHC and can?t > create 32 bits dll?s (?). This means I have to install 7.8.3 and 7.8.4 on > the same Windows machine. Is this possible? > > > > Kees > > *Van:* Carter Schonwald [mailto:carter.schonwald at gmail.com] > *Verzonden:* zaterdag 7 maart 2015 20:02 > *Aan:* Kees Bleijenberg > *Onderwerp:* Re: [Haskell-cafe] ghc -O2 out of memory > > > > Upgrade to ghc 7.8.4, theres some known bugs in O2 optimization that > resulted in excessive memory usage that are fixed in 7.8.4 > > You'll still have painful compilation times with a 30kloc module , but > memory usage should be physically possible after the upgrade. > > On Mar 7, 2015 10:58 AM, "Kees Bleijenberg" > wrote: > > I?ve written a program that reads a Excel file, parses the contents and > generates a haskell module. Every cell in the xls has it?s own function in > the module. This worked fine. > > Now I have a bigger xls. The resulting module Xls.hs contains 30000 lines > haskell code (without comment). I created a testprogram test.hs that > calculates and prints one cell. > > I did ghc --make test.hs and everything works fine. The generated > execuatable is very slow. > > I did ghc --make ?O2 test.hs. The compilations takes 15 minutes and aborts > with ?ghc: out of memory?. I?am working on Win 7 64 bits , ghc version = > 7.8.3. > > > > What can I do to fix this? I do need ?O2. I found with smaller xls?s that > optimization speeds up the executable dramatically. > > Before I start experimenting, does it help to split up the xls .hs in > seperate files? I.e. the cells that refer to other cells and cells that > don?t refer to other cells. Or will I still get ?out of memory? because the > optimization is global? > > > > Kees > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2015.0.5751 / Virus Database: 4299/9258 - Release Date: 03/09/15 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Mar 10 18:23:37 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 10 Mar 2015 13:23:37 -0500 Subject: GHC Weekly News - 2013/03/10 Message-ID: (This post is available online at https://ghc.haskell.org/trac/ghc/blog/weekly20150310) Hi *, It's that time again! Today GHC HQ met on a Tuesday to avoid some scheduling conflicts, and that means it's time to send some news to people. Just a quick reminder from last week: we're hoping to make our third GHC 7.10.1 release candidate on '''Friday, March 13th''', with the final release on '''Friday, March 27th'''. - Today, GHC HQ mostly talked about 7.10 bugs; HEAD is steaming along as usual with no impediments, but we've got several critical bugs we plan on landing fixes for this week; see milestone:7.10.1 for more. But we've also had a little more list activity this week than we did before: - Joachim Breitner asks: how do I extend the blocks in a C-- graph? Jan popped in with advice, but it looks like Joachim found a rather simple solution himself. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008467.html - Karel Gardas wrote to the list about how to better parallelize the GHC build. For background, he's using a UltraSPARC T1-CPU/T2000 server with 32 hardware threads over 8 cores, where parallelism is a bigger win than raw single-threaded performance. But despite that, the performance is of the parallel GHC build is relatively abysmal - and Karel wants help brainstorming ideas to fix it. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008474.html - Herbert Valerio Riedel noted that there are new git hooks in place for all developers on `git.haskell.org`, which will reject new kinds of pushes. In particular, Herbert took the time to implement commit message validation, and whitespace validation. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008480.html Some noteworthy commits that went into `ghc.git` in the past week include: - Commit eb3661f2b9f8472f3714774126ebe1183484dd85 - Re-export `<$>` from Prelude (#10113) - Commit 479523f3c37894d63352f1718e06696f3ed63143 - Re-export `<$` from Prelude (#10113) - Commit b359c886cd7578ed083bcedcea05d315ecaeeb54 - Custom `Typeable` solver, that keeps track of kinds (#9858) - Commit 76b1e11943d794da61d342c072a783862a9e2a1a - Improve core linter so it catches `unsafeCoerce` problems (#9122) - Commit 7a2d65a4d93273c89fbb1d19e282d5933c67c7ca - Define proper `MINIMAL` pragma for `class Ix` (#10142) Closed tickets the past week include: #7854, #10118, #10119, #3321, #10132, #9987, #10126, #9707, #10142, #10147, #10113, #9524, #10058, #10100, #2991, #10140, and #9122. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From matej.borovec at yahoo.com Tue Mar 10 10:41:28 2015 From: matej.borovec at yahoo.com (Matej Borovec) Date: Tue, 10 Mar 2015 11:41:28 +0100 Subject: [Haskell-cafe] ghc -O2 out of memory In-Reply-To: References: <000001d058ef$45451e10$cfcf5a30$@lijbrandt.nl> <006c01d05a40$e800fcd0$b802f670$@lijbrandt.nl> Message-ID: <1E2E822FADE2405C80D3B72C472BE4ED@unknown> I have built GHC 7.8.4 on windows 32-bit a while back so feel free to use it until official build becomes available. https://www.dropbox.com/s/z77nry3l6kvos9f/ghc-7.8.4-win32.7z?dl=0 From: Carter Schonwald Sent: Tuesday, March 10, 2015 3:09 AM To: Kees Bleijenberg Cc: ghc-devs at haskell.org Subject: Re: [Haskell-cafe] ghc -O2 out of memory there SHOULD be a 32bit 7.8.4 build available somewhere for windows, and if not , thats a real problem! I'm gonna shift this thread to ghc-devs, because that *should* get addressed @ghc-devs, how can we help this user get ahold of a 32bit windows 7.8.4 build? (eg, why do we not have one available yet?) -Carter On Mon, Mar 9, 2015 at 4:13 AM, Kees Bleijenberg wrote: Thanks for your answer. I also use ghc to create 32 bits dll?s. 7.8.4 is 64 bits GHC and can?t create 32 bits dll?s (?). This means I have to install 7.8.3 and 7.8.4 on the same Windows machine. Is this possible? Kees Van: Carter Schonwald [mailto:carter.schonwald at gmail.com] Verzonden: zaterdag 7 maart 2015 20:02 Aan: Kees Bleijenberg Onderwerp: Re: [Haskell-cafe] ghc -O2 out of memory Upgrade to ghc 7.8.4, theres some known bugs in O2 optimization that resulted in excessive memory usage that are fixed in 7.8.4 You'll still have painful compilation times with a 30kloc module , but memory usage should be physically possible after the upgrade. On Mar 7, 2015 10:58 AM, "Kees Bleijenberg" wrote: I?ve written a program that reads a Excel file, parses the contents and generates a haskell module. Every cell in the xls has it?s own function in the module. This worked fine. Now I have a bigger xls. The resulting module Xls.hs contains 30000 lines haskell code (without comment). I created a testprogram test.hs that calculates and prints one cell. I did ghc --make test.hs and everything works fine. The generated execuatable is very slow. I did ghc --make ?O2 test.hs. The compilations takes 15 minutes and aborts with ?ghc: out of memory?. I?am working on Win 7 64 bits , ghc version = 7.8.3. What can I do to fix this? I do need ?O2. I found with smaller xls?s that optimization speeds up the executable dramatically. Before I start experimenting, does it help to split up the xls .hs in seperate files? I.e. the cells that refer to other cells and cells that don?t refer to other cells. Or will I still get ?out of memory? because the optimization is global? Kees _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe No virus found in this message. Checked by AVG - www.avg.com Version: 2015.0.5751 / Virus Database: 4299/9258 - Release Date: 03/09/15 -------------------------------------------------------------------------------- _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Tue Mar 10 21:35:56 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 10 Mar 2015 14:35:56 -0700 Subject: [Diffusion] [Build Failed] rGHCb833bc2767d7: User manual section to document the principles of kind inference In-Reply-To: References: <20150305230056.9666.60040@phabricator.haskell.org> <618BE556AADD624C9C918AA5D5911BEF7BED8022@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: <1426023254-sup-1141@sabre> I refactored a bunch of normaliseGhcPackage() functions that were littered about the testsuite into a normalise_version, see this CR: https://phabricator.haskell.org/D725 I don't know if people would find it more convenient, however, to just apply this sort of normalisation unconditionally. In that case, we'd need some list of package names to apply this to. Edward Excerpts from Austin Seipp's message of 2015-03-06 10:11:31 -0800: > I pushed a fix, but I agree this is annoying. Perhaps the testsuite > 'scrubber' should try to handle things like this too (does anyone want > to write a patch?) > > On Fri, Mar 6, 2015 at 2:37 AM, Simon Peyton Jones > wrote: > > Guys > > > > I'm seeing this validate failures on TH_Roles2 > > > > -Dependent packages: [array-0.5.0.1, base-4.8.0.0, deepseq-1.4.0.0, > > +Dependent packages: [array-0.5.0.1, base-4.8.0.0, deepseq-1.4.1.0, > > > > And similarly safePkg01 > > -package dependencies: array-0.5.0.1 base-4.8.0.0 bytestring-0.10.5.0* deepseq-1.4.0.0 ghc-prim-0.3.1.0 integer-gmp-0.5.1.0 > > +package dependencies: array-0.5.0.1 base-4.8.0.0 bytestring-0.10.6.0* deepseq-1.4.1.0 ghc-prim-0.3.1.0 integer-gmp-1.0. > > > > Could someone fix? > > > > Do we want tests that depend on version numbers in this fragile way. They are almost bound to fail repeatedly over time. > > > > Simon > > > > | -----Original Message----- > > | From: noreply at phabricator.haskell.org > > | [mailto:noreply at phabricator.haskell.org] > > | Sent: 05 March 2015 23:03 > > | To: Simon Peyton Jones > > | Subject: [Diffusion] [Build Failed] rGHCb833bc2767d7: User manual section > > | to document the principles of kind inference > > | > > | Harbormaster failed to build B3285: rGHCb833bc2767d7: User manual section > > | to document the principles of kind inference! > > | > > | USERS > > | simonpj (Author) > > | GHC - Documentation (Auditor) > > | > > | COMMIT > > | https://phabricator.haskell.org/rGHCb833bc2767d7 > > | > > | REPLY HANDLER ACTIONS > > | Reply to comment. > > | > > | EMAIL PREFERENCES > > | https://phabricator.haskell.org/settings/panel/emailpreferences/ > > | > > | To: simonpj, GHC - Documentation > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > From simonpj at microsoft.com Tue Mar 10 21:49:47 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 10 Mar 2015 21:49:47 +0000 Subject: [commit: ghc] ghc-7.10: fixup T10019 output yet again (9f19723) In-Reply-To: <20150310142809.017243A300@ghc.haskell.org> References: <20150310142809.017243A300@ghc.haskell.org> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEF7CF3@DB3PRD3001MB020.064d.mgd.msft.net> This test keeps wobbling because a unique id shows up in the pretty-printed Template Haskell output. Maybe it's a poorly designed test; or maybe there should be a way of suppressing these uniques. I'm not sure. It'd be great if someone wanted to take a look Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of | git at git.haskell.org | Sent: 10 March 2015 14:28 | To: ghc-commits at haskell.org | Subject: [commit: ghc] ghc-7.10: fixup T10019 output yet again (9f19723) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : ghc-7.10 | Link : | http://ghc.haskell.org/trac/ghc/changeset/9f19723668b5ef012841012406d1ea4 | 2b618fb69/ghc | | >--------------------------------------------------------------- | | commit 9f19723668b5ef012841012406d1ea42b618fb69 | Author: Herbert Valerio Riedel | Date: Tue Mar 10 15:25:59 2015 +0100 | | fixup T10019 output yet again | | | >--------------------------------------------------------------- | | 9f19723668b5ef012841012406d1ea42b618fb69 | testsuite/tests/th/T10019.stdout | 2 +- | 1 file changed, 1 insertion(+), 1 deletion(-) | | diff --git a/testsuite/tests/th/T10019.stdout | b/testsuite/tests/th/T10019.stdout | index 350338c..6345930 100644 | --- a/testsuite/tests/th/T10019.stdout | +++ b/testsuite/tests/th/T10019.stdout | @@ -1 +1 @@ | -"DataConI Ghci1.Some (ForallT [KindedTV a_1627391549 StarT] [] (AppT | (AppT ArrowT (VarT a_1627391549)) (AppT (ConT Ghci1.Option) (VarT | a_1627391549)))) Ghci1.Option (Fixity 9 InfixL)" | +"DataConI Ghci1.Some (ForallT [KindedTV a_1627391544 StarT] [] (AppT | (AppT ArrowT (VarT a_1627391544)) (AppT (ConT Ghci1.Option) (VarT | a_1627391544)))) Ghci1.Option (Fixity 9 InfixL)" | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits From simonpj at microsoft.com Wed Mar 11 09:39:41 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 11 Mar 2015 09:39:41 +0000 Subject: tyConHash -- quick fix? Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEF803C@DB3PRD3001MB020.064d.mgd.msft.net> data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, -- ^ @since 4.8.0.0 tyConPackage :: String, -- ^ @since 4.5.0.0 tyConModule :: String, -- ^ @since 4.5.0.0 tyConName :: String -- ^ @since 4.5.0.0 } Friends, Is tyConHash a good name here? Wouldn't tyConFingerprint be better? * Hash functions usually yield a Int. * tyConFingerprint :: TyCon -> Fingerprint makes the name match the type. * If we had fingerprintHash:: Fingerprint -> Int, then we might want tyConHash :: TyCon -> Int tyConHash = fingerprintHash . tyConFingerpring This is new in 7.10, so we could fix it now with no trouble. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Mar 11 09:44:49 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 11 Mar 2015 05:44:49 -0400 Subject: [core libraries] tyConHash -- quick fix? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEF803C@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEF803C@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I like your idea of using tyConHash for the Int version and tyConFingerprint to refer to the Fingerprint. The former fits more closely with the usage elsewhere e.g. hashUnique, hashStableName. -Edward On Wed, Mar 11, 2015 at 5:39 AM, Simon Peyton Jones wrote: > data TyCon = TyCon { > > tyConHash :: {-# UNPACK #-} !Fingerprint, -- ^ @since 4.8.0.0 > > tyConPackage :: String, -- ^ @since 4.5.0.0 > > tyConModule :: String, -- ^ @since 4.5.0.0 > > tyConName :: String -- ^ @since 4.5.0.0 > > } > > > > Friends, > > Is tyConHash a good name here? Wouldn?t tyConFingerprint be better? > > ? Hash functions usually yield a Int. > > ? tyConFingerprint :: TyCon -> Fingerprint makes the name match > the type. > > ? If we had fingerprintHash:: Fingerprint -> Int, then we might > want > tyConHash :: TyCon -> Int > tyConHash = fingerprintHash . tyConFingerpring > > > > This is new in 7.10, so we could fix it now with no trouble. > > Simon > > > > -- > You received this message because you are subscribed to the Google Groups > "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-core-libraries+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed Mar 11 09:47:45 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 11 Mar 2015 10:47:45 +0100 Subject: [core libraries] tyConHash -- quick fix? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEF803C@DB3PRD3001MB020.064d.mgd.msft.net> (Simon Peyton Jones's message of "Wed, 11 Mar 2015 09:39:41 +0000") References: <618BE556AADD624C9C918AA5D5911BEF7BEF803C@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <87zj7jq30e.fsf@gmail.com> On 2015-03-11 at 10:39:41 +0100, Simon Peyton Jones wrote: [...] > This is new in 7.10, so we could fix it now with no trouble. > Simon Here's a bit more background information: Afaics, tyConHash was introduced in http://git.haskell.org/ghc.git/commitdiff/e0b63e02b78d0bd31a073738b1154a93d22dccca and it was recently re-exported via http://git.haskell.org/ghc.git/commitdiff/56e0ac98c3a439b8757a2e886db259270bdc85f0 which followed the same questionable naming scheme for the really new 'typeRepHash' field accessor From malcolm.wallace at me.com Wed Mar 11 10:45:10 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Wed, 11 Mar 2015 10:45:10 +0000 Subject: GHC 7.8.4 for Windows 32bit In-Reply-To: References: Message-ID: <0746E638-C122-41A7-B3A3-B5FA43CE38BB@me.com> Any progress yet on win32 builds? Regards, Malcolm On 3 Mar 2015, at 14:05, Austin Seipp wrote: > Sorry about that; at the time I was having trouble with my build bots > and I've continuously had trouble remoting into the Win32 machines I > have... The 64bit build bots worked fine, but the 32 ones consistently > had flaky internet connectivity, to the point I couldn't bootstrap GHC > itself. I tried yesterday again, and seem to have fallen pray to > something else (which makes it so I cannot RDP in at all right now, it > seems). > > I've actually assembled a new PC here (that I have not yet installed > Windows on) however, so hopefully I can shortly get binaries up. > > On Tue, Mar 3, 2015 at 7:51 AM, Neil Mitchell wrote: >> Hi, >> >> GHC 7.8.4 was released a little while ago, but there still isn't a >> Windows 32bit version available. With my "MinGHC maintainer" hat on >> we're getting quite a lot of requests for a 32bit 7.8.4 version. With >> my "using Haskell commercially" hat on the lack of a 32bit build is >> causing delays to infrastructure upgrades. Any timeline for a 32bit >> Windows build? Anything you're stuck on? >> >> Going forward, it seems the 32bit Windows version remains popular, so >> if all releases and release candidates came with such a version it >> would be great. I note there wasn't (and still might not be) a 7.10 >> RC, and as a result I've only tested my packages on Linux. >> >> Thanks, Neil > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Wed Mar 11 14:38:27 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 11 Mar 2015 14:38:27 +0000 Subject: [core libraries] tyConHash -- quick fix? In-Reply-To: <87zj7jq30e.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF7BEF803C@DB3PRD3001MB020.064d.mgd.msft.net> <87zj7jq30e.fsf@gmail.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEF843E@DB3PRD3001MB020.064d.mgd.msft.net> Yes, but the original 'tyConHash' was not exported, so no one will be annoyed if we change its name. We only started exporting it recently. Hence my suggestion to change its name to tyConFingerprint. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] | Sent: 11 March 2015 09:48 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org; core-libraries-committee at haskell.org | Subject: Re: [core libraries] tyConHash -- quick fix? | | On 2015-03-11 at 10:39:41 +0100, Simon Peyton Jones wrote: | | [...] | | > This is new in 7.10, so we could fix it now with no trouble. | > Simon | | Here's a bit more background information: | | Afaics, tyConHash was introduced in | | | http://git.haskell.org/ghc.git/commitdiff/e0b63e02b78d0bd31a073738b1154 | a93d22dccca | | and it was recently re-exported via | | | http://git.haskell.org/ghc.git/commitdiff/56e0ac98c3a439b8757a2e886db25 | 9270bdc85f0 | | which followed the same questionable naming scheme for the really new | 'typeRepHash' field accessor | From tuncer.ayaz at gmail.com Wed Mar 11 15:00:38 2015 From: tuncer.ayaz at gmail.com (Tuncer Ayaz) Date: Wed, 11 Mar 2015 16:00:38 +0100 Subject: Porting to Haiku In-Reply-To: References: Message-ID: On Sat, Nov 1, 2014 at 3:36 PM, Jessica Hamilton wrote: > Hi, > > I (and one other) am working on porting GHC to Haiku; we've > successfully got a working GHC cross-compiler running on Haiku, and > now are able to also build GHC on Haiku from the cross-compiler when > using the "quickest" profile in the mk/build.mk file. > > However, using the default build profile, we're running into a > couple of issues. > > 1. A random segfault in ghc-stage1 (is probably an issue in Haiku, not > entirely sure yet), with the following call stack: > runCFinalizers + 0x3a > runAllCFinalizers + 0x37 > hs_exit_ +0x99 > shutdownHaskellAndExit + 0x2f > hs_main + 0xb1 > .../ghc-7.8.3/inplace/lib/bin/ghc-stage1 + 0xc7b374 > _start + 0x4b > runtime_loader + 0x130 > > I can't really see anything obvious in the source code myself > (although our debugger fails to enumerate the semaphores, and also > needs to be killed). Restarting the build is sufficient to get past > the issue, however. > > 2. A more pressing issue is with ghc-cabal. It fails with the error > "resource exhausted" when running the following command: > inplace/bin/ghc-cabal copy compiler stage2 > > This error is reproducible every time. I've tried setting up a > profile build in the mk/build.mk file in order to get a stack trace > from ghc-cabal; however, after rebuilding GHC from scratch, running > ghc-cabal +RTS -xc, it still complains that the flag -xc requires > the program to be built with -prof. > > Some advice would be handy before diving into another couple hours > of rebuilding GHC to try and get a profiled build of ghc-cabal out > of the build system ;-) Any progress? From johan.tibell at gmail.com Thu Mar 12 00:28:05 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 12 Mar 2015 11:28:05 +1100 Subject: [core libraries] tyConHash -- quick fix? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEF843E@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEF803C@DB3PRD3001MB020.064d.mgd.msft.net> <87zj7jq30e.fsf@gmail.com> <618BE556AADD624C9C918AA5D5911BEF7BEF843E@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: SGTM. I'm probably the only user of the newly exported symbol (by using it in hashable). On Thu, Mar 12, 2015 at 1:38 AM, Simon Peyton Jones wrote: > Yes, but the original 'tyConHash' was not exported, so no one will be > annoyed if we change its name. We only started exporting it recently. > Hence my suggestion to change its name to tyConFingerprint. > > Simon > > | -----Original Message----- > | From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com] > | Sent: 11 March 2015 09:48 > | To: Simon Peyton Jones > | Cc: ghc-devs at haskell.org; core-libraries-committee at haskell.org > | Subject: Re: [core libraries] tyConHash -- quick fix? > | > | On 2015-03-11 at 10:39:41 +0100, Simon Peyton Jones wrote: > | > | [...] > | > | > This is new in 7.10, so we could fix it now with no trouble. > | > Simon > | > | Here's a bit more background information: > | > | Afaics, tyConHash was introduced in > | > | > | http://git.haskell.org/ghc.git/commitdiff/e0b63e02b78d0bd31a073738b1154 > | a93d22dccca > | > | and it was recently re-exported via > | > | > | http://git.haskell.org/ghc.git/commitdiff/56e0ac98c3a439b8757a2e886db25 > | 9270bdc85f0 > | > | which followed the same questionable naming scheme for the really new > | 'typeRepHash' field accessor > | > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Mar 12 09:46:06 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 12 Mar 2015 10:46:06 +0100 Subject: GHC 7.10 Regression(?) regarding Unicode subscript characters in identifiers Message-ID: <87y4n28s69.fsf@gmail.com> Hello *, The comment https://ghc.haskell.org/trac/ghc/ticket/5108#comment:16 made me aware the Unicode7 update in GHC 7.10 had the side effect of breaking code making use of subscript symbols that did compile with GHC 7.8.4, but won't anymore with GHC 7.10.1: For instance, GHCi 7.8.4 accepts let x? = 1 let x? = 1 let x? = 1 let x? = 1 let x? = 1 let x? = 1 let x? = 1 whereas GHC 7.10.1RC fails parsing those with a lexical error. (NB: GHC 7.8 does not accept *all* latin subscript letters either). I wanted to raise attention to this, as this IMO deserves (at the very least) some release-note entry, or alternatively (if this is considered a regression) some workaround in the lexer to restore backward compatibility... Cheers, hvr From karel.gardas at centrum.cz Fri Mar 13 14:21:27 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 13 Mar 2015 15:21:27 +0100 Subject: Testsuite broken on builders. Message-ID: <5502F267.3040402@centrum.cz> Hello, we do have builders[1] broken for about 2-3 days now due to an issue in testsuite[2]. It shows as: Traceback (most recent call last): File "../driver/runtests.py", line 200, in "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE ../config/good.ps from testlib import * File "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 2058, in resultGood = runCmdExitCode(genGSCmd(config.confdir + '/good.ps')); File "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 1870, in runCmdExitCode return (runCmd(cmd) >> 8); File "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 1838, in runCmd r = rawSystemWithTimeout([config.timeout_prog, str(config.timeout), cmd]) File "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 1813, in rawSystemWithTimeout r = rawSystem(cmd_and_args) File "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", line 1790, in rawSystem return subprocess.call([strip_quotes(cmd)] + cmd_and_args[1:]) NameError: global name 'strip_quotes' is not defined gmake[1]: *** [test] Error 1 gmake[1]: Leaving directory `/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/tests' gmake: *** [test] Error 2 Following git log you were two developers dealing with testsuite recently. Perhaps you've broken the thing? Do you think you find some time to fix that? Thanks a lot! Karel [1]: http://haskell.inf.elte.hu/builders/ [2]: http://haskell.inf.elte.hu/builders/solaris-x86-head/342/21.html From thomasmiedema at gmail.com Fri Mar 13 15:47:55 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 13 Mar 2015 16:47:55 +0100 Subject: Testsuite broken on builders. In-Reply-To: <5502F267.3040402@centrum.cz> References: <5502F267.3040402@centrum.cz> Message-ID: I have a fix for this in https://phabricator.haskell.org/D728. Waiting for validate and review. On Fri, Mar 13, 2015 at 3:21 PM, Karel Gardas wrote: > > Hello, > > we do have builders[1] broken for about 2-3 days now due to an issue in > testsuite[2]. It shows as: > > Traceback (most recent call last): > File "../driver/runtests.py", line 200, in > "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE ../config/good.ps > from testlib import * > File > "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", > line 2058, in > resultGood = runCmdExitCode(genGSCmd(config.confdir + '/good.ps')); > File > "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", > line 1870, in runCmdExitCode > return (runCmd(cmd) >> 8); > File > "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", > line 1838, in runCmd > r = rawSystemWithTimeout([config.timeout_prog, str(config.timeout), cmd]) > File > "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", > line 1813, in rawSystemWithTimeout > r = rawSystem(cmd_and_args) > File > "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", > line 1790, in rawSystem > return subprocess.call([strip_quotes(cmd)] + cmd_and_args[1:]) > NameError: global name 'strip_quotes' is not defined > gmake[1]: *** [test] Error 1 > gmake[1]: Leaving directory > `/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/tests' > gmake: *** [test] Error 2 > > > Following git log you were two developers dealing with testsuite recently. > Perhaps you've broken the thing? Do you think you find some time to fix > that? > > Thanks a lot! > Karel > > [1]: http://haskell.inf.elte.hu/builders/ > > [2]: http://haskell.inf.elte.hu/builders/solaris-x86-head/342/21.html From karel.gardas at centrum.cz Fri Mar 13 15:48:37 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 13 Mar 2015 16:48:37 +0100 Subject: Testsuite broken on builders. In-Reply-To: References: <5502F267.3040402@centrum.cz> Message-ID: <550306D5.5090208@centrum.cz> Thomas, thanks a lot for this super-fast action! Karel On 03/13/15 04:47 PM, Thomas Miedema wrote: > I have a fix for this in https://phabricator.haskell.org/D728. Waiting > for validate and review. > > On Fri, Mar 13, 2015 at 3:21 PM, Karel Gardas wrote: >> >> Hello, >> >> we do have builders[1] broken for about 2-3 days now due to an issue in >> testsuite[2]. It shows as: >> >> Traceback (most recent call last): >> File "../driver/runtests.py", line 200, in >> "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE ../config/good.ps >> from testlib import * >> File >> "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", >> line 2058, in >> resultGood = runCmdExitCode(genGSCmd(config.confdir + '/good.ps')); >> File >> "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", >> line 1870, in runCmdExitCode >> return (runCmd(cmd)>> 8); >> File >> "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", >> line 1838, in runCmd >> r = rawSystemWithTimeout([config.timeout_prog, str(config.timeout), cmd]) >> File >> "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", >> line 1813, in rawSystemWithTimeout >> r = rawSystem(cmd_and_args) >> File >> "/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/driver/testlib.py", >> line 1790, in rawSystem >> return subprocess.call([strip_quotes(cmd)] + cmd_and_args[1:]) >> NameError: global name 'strip_quotes' is not defined >> gmake[1]: *** [test] Error 1 >> gmake[1]: Leaving directory >> `/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/testsuite/tests' >> gmake: *** [test] Error 2 >> >> >> Following git log you were two developers dealing with testsuite recently. >> Perhaps you've broken the thing? Do you think you find some time to fix >> that? >> >> Thanks a lot! >> Karel >> >> [1]: http://haskell.inf.elte.hu/builders/ >> >> [2]: http://haskell.inf.elte.hu/builders/solaris-x86-head/342/21.html > From ezyang at mit.edu Fri Mar 13 22:04:38 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 13 Mar 2015 15:04:38 -0700 Subject: GHC 7.8.4 for Windows 32bit In-Reply-To: <0746E638-C122-41A7-B3A3-B5FA43CE38BB@me.com> References: <0746E638-C122-41A7-B3A3-B5FA43CE38BB@me.com> Message-ID: <1426284258-sup-8473@sabre> In a similar vein, are instructions for how to build Windows release builds online anywhere? Edward Excerpts from Malcolm Wallace's message of 2015-03-11 03:45:10 -0700: > Any progress yet on win32 builds? > > Regards, > Malcolm > > On 3 Mar 2015, at 14:05, Austin Seipp wrote: > > > Sorry about that; at the time I was having trouble with my build bots > > and I've continuously had trouble remoting into the Win32 machines I > > have... The 64bit build bots worked fine, but the 32 ones consistently > > had flaky internet connectivity, to the point I couldn't bootstrap GHC > > itself. I tried yesterday again, and seem to have fallen pray to > > something else (which makes it so I cannot RDP in at all right now, it > > seems). > > > > I've actually assembled a new PC here (that I have not yet installed > > Windows on) however, so hopefully I can shortly get binaries up. > > > > On Tue, Mar 3, 2015 at 7:51 AM, Neil Mitchell wrote: > >> Hi, > >> > >> GHC 7.8.4 was released a little while ago, but there still isn't a > >> Windows 32bit version available. With my "MinGHC maintainer" hat on > >> we're getting quite a lot of requests for a 32bit 7.8.4 version. With > >> my "using Haskell commercially" hat on the lack of a 32bit build is > >> causing delays to infrastructure upgrades. Any timeline for a 32bit > >> Windows build? Anything you're stuck on? > >> > >> Going forward, it seems the 32bit Windows version remains popular, so > >> if all releases and release candidates came with such a version it > >> would be great. I note there wasn't (and still might not be) a 7.10 > >> RC, and as a result I've only tested my packages on Linux. > >> > >> Thanks, Neil > > > > > > > > -- > > Regards, > > > > Austin Seipp, Haskell Consultant > > Well-Typed LLP, http://www.well-typed.com/ > From david.feuer at gmail.com Mon Mar 16 01:47:02 2015 From: david.feuer at gmail.com (David Feuer) Date: Sun, 15 Mar 2015 21:47:02 -0400 Subject: More at-use-site extension pragmas please Message-ID: For people working on libraries intended to be portable but using/offering GHC specials when compiled with GHC, it's nice to be able to verify quickly that nothing relies on a GHC extension that shouldn't. For example, I just submitted a pull request to add an IsString instance to Data.Sequence: instance IsString (Seq Char) where fromString = fromList This instance requires FlexibleInstances to compile. Since that option is global, GHC will no longer complain about non-standard instance heads *anywhere* in the (large) module. The obvious long-term solution, I believe, is to add {-# FlexibleInstance #-} (and {-# FlexibleContext #-}) pragmas. Well, that or get some sort of termination checker into Haskell 2015! David From mietek at bak.io Mon Mar 16 13:21:25 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Mon, 16 Mar 2015 13:21:25 +0000 Subject: MAC builds of 7.8.4 and 7.10.1 RC2 In-Reply-To: References: Message-ID: <8F4FD416-C180-481B-9DF1-3A35A0683ABA@bak.io> It looks like an OS X build of 7.8.4 is now mirrored, but there?s no link from the GHC 7.8.4 page yet: https://downloads.haskell.org/~ghc/7.8.4/ https://www.haskell.org/ghc/download_ghc_7_8_4 The OS X build of 7.10.1-rc2 is not mirrored yet: https://downloads.haskell.org/~ghc/7.10.1-rc2/ How can I help get this fixed? -- Mi?tek On 2015-02-15, at 22:11, Bob Ippolito wrote: > Thanks Mark! This build seems to work well. I'm in the process of publishing a new http://ghcformacosx.github.io/ with it. > > Austin - do you still plan to get these binaries online? I think haskell.org has more bandwidth than ozonehouse.com :) > > On Thu, Feb 12, 2015 at 7:02 AM, Austin Seipp wrote: > I'll get them online with signed hashes today. > > On Thu, Feb 12, 2015 at 8:20 AM, Ozgur Akgun wrote: > > This is great. > > > > What would one have to do to get this added to > > https://www.haskell.org/ghc/download_ghc_7_8_4 ? > > > > Ozgur > > > > On 11 February 2015 at 06:16, Mark Lentczner > > wrote: > >> > >> My build procedure is very minimal: > >> > >> export MACOSX_DEPLOYMENT_TARGET=10.6 > >> ./configure 2>&1 | tee ../conf.log > >> cat > mk/build.mk < >> V=1 > >> SplitObjs=YES > >> SupportsSplitObjs=YES > >> HADDOCK_DOCS=YES > >> LATEX_DOCS=NO > >> HSCOLOUR_SRCS=YES > >> BUILD_DOCBOOK_HTML=YES > >> BUILD_DOCBOOK_PDF=NO > >> BUILD_DOCBOOK_PS=NO > >> BeConservative=YES > >> END > >> time make -j4 2>&1 | tee ../make.log > >> time make binary-dist 2>&1 | tee ../bd.log > >> > >> That is all! > > > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From austin at well-typed.com Mon Mar 16 20:30:09 2015 From: austin at well-typed.com (Austin Seipp) Date: Mon, 16 Mar 2015 15:30:09 -0500 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 Message-ID: We are pleased to announce the third release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc3 https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ This includes the source tarball and bindists for Windows and Debian Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.1 final release at the end of this week - so please test as much as possible; bugs are much cheaper if we find them before the release! The list of issues we plan on fixing can always be found in an up-to-date form here: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From mietek at bak.io Tue Mar 17 02:09:23 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Tue, 17 Mar 2015 02:09:23 +0000 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: References: Message-ID: <4FF22F98-5B3F-4A0A-8BEB-1DE1A71BAC51@bak.io> Thanks. 7.10.1-rc3 is now available in Halcyon, on CentOS 6 (x86_64 only), CentOS 7, Debian 7, Fedora 19, Fedora 20, Fedora 21 (x86_64 only), Ubuntu 12.04 LTS, Ubuntu 14.04 LTS, and Ubuntu 14.10. As with 7.10.1-rc2, installation fails on CentOS 6 (i386), Debian 6, and Ubuntu 10.04 LTS, in one of two following ways ? 1. On i386: "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/ghc-prim dist-install "strip" '' '/app/ghc' '/app/ghc/lib/ghc-7.10.0.20150316' '/app/ghc/share/doc/ghc/html/libraries' 'v p dyn' ghc-cabal/dist-install/build/tmp/ghc-cabal: symbol lookup error: libraries/integer-gmp2/dist-install/build/libHSinteger-gmp-1.0.0.0-6zeGtnFHpaVBJ80QaL9uVu-ghc7.10.0.20150316.so: undefined symbol: __gmpn_ior_n 2. On x86_64: ghc-cabal: '/app/ghc/lib/ghc-7.10.0.20150316/bin/ghc' exited with an error: /app/ghc/lib/ghc-7.10.0.20150316/bin/ghc: symbol lookup error: /app/ghc/lib/ghc-7.10.0.20150316/bin/../rts/libHSrts_thr-ghc7.10.0.20150316.so: undefined symbol: pthread_setname_np -- Mi?tek On 2015-03-16, at 20:30, Austin Seipp wrote: > We are pleased to announce the third release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc3 > https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ > > This includes the source tarball and bindists for Windows and Debian > Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow > soon. These binaries and tarballs have an accompanying > SHA256SUMS file signed by my GPG key id (0x3B58D86F). > > We plan to make the 7.10.1 final release at the end of this week - so > please test as much as possible; bugs are much cheaper if we find them > before the release! > > The list of issues we plan on fixing can always be found in an > up-to-date form here: > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From jan.stolarek at p.lodz.pl Tue Mar 17 07:12:07 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 17 Mar 2015 08:12:07 +0100 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: <4FF22F98-5B3F-4A0A-8BEB-1DE1A71BAC51@bak.io> References: <4FF22F98-5B3F-4A0A-8BEB-1DE1A71BAC51@bak.io> Message-ID: <201503170812.07988.jan.stolarek@p.lodz.pl> > 2. On x86_64: > > ghc-cabal: '/app/ghc/lib/ghc-7.10.0.20150316/bin/ghc' exited with an > error: /app/ghc/lib/ghc-7.10.0.20150316/bin/ghc: symbol lookup error: > /app/ghc/lib/ghc-7.10.0.20150316/bin/../rts/libHSrts_thr-ghc7.10.0.2015031 >6.so: undefined symbol: pthread_setname_np Same happens with the released x86_64 binary build on openSUSE 11.4 during "make install" step. $ uname -a Linux xerxes.discovery 2.6.37.6-24-desktop #1 SMP PREEMPT 2012-10-18 22:36:08 +0200 x86_64 x86_64 x86_64 GNU/Linux $ /lib64/libc.so.6 GNU C Library stable release version 2.11.3 (20110203), by Roland McGrath et al. Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Configured for x86_64-suse-linux. Compiled by GNU CC version 4.5.1 20101208 [gcc-4_5-branch revision 167585]. Compiled on a Linux 2.6.36 system on 2012-07-09. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From hvriedel at gmail.com Tue Mar 17 08:25:50 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 17 Mar 2015 09:25:50 +0100 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: <4FF22F98-5B3F-4A0A-8BEB-1DE1A71BAC51@bak.io> (=?utf-8?Q?=22M?= =?utf-8?Q?i=C3=ABtek?= Bak"'s message of "Tue, 17 Mar 2015 02:09:23 +0000") References: <4FF22F98-5B3F-4A0A-8BEB-1DE1A71BAC51@bak.io> Message-ID: <87vbi0kp2p.fsf@gmail.com> On 2015-03-17 at 03:09:23 +0100, Mi?tek Bak wrote: > As with 7.10.1-rc2, installation fails on CentOS 6 (i386), Debian 6, and Ubuntu 10.04 LTS, in one of two following ways ? > > 1. On i386: > > "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/ghc-prim dist-install "strip" '' '/app/ghc' '/app/ghc/lib/ghc-7.10.0.20150316' '/app/ghc/share/doc/ghc/html/libraries' 'v p dyn' > ghc-cabal/dist-install/build/tmp/ghc-cabal: symbol lookup error: libraries/integer-gmp2/dist-install/build/libHSinteger-gmp-1.0.0.0-6zeGtnFHpaVBJ80QaL9uVu-ghc7.10.0.20150316.so: undefined symbol: __gmpn_ior_n Well, it shouldn't be very surprising that the deb7 (wheezy) ghc bindist doesn't work on deb6 (squeeze), as it's been compile-time configured for the environment provided by deb7 which has newer libraries with more features/symbols. So what's needed here is probably a 2nd linux bindist build on an ancient enough (i.e. the one with the oldest libraries among CentOS6/Deb6/Ubuntu10.04) Linux environment. From mietek at bak.io Tue Mar 17 08:33:59 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Tue, 17 Mar 2015 08:33:59 +0000 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: <87vbi0kp2p.fsf@gmail.com> References: <4FF22F98-5B3F-4A0A-8BEB-1DE1A71BAC51@bak.io> <87vbi0kp2p.fsf@gmail.com> Message-ID: <3D055B5C-0DBF-49D0-B398-21F25E0E627C@bak.io> As I wrote previously ? the bindist name does mention ?deb7?, so perhaps this is all working as intended, and perhaps supporting such ancient distributions is not actually needed. However, the GHC 7.8.4, 7.8.3, and 7.8.2 bindists work fine with glibc 2.11, so this is a regression. -- Mi?tek On 2015-03-17, at 08:25, Herbert Valerio Riedel wrote: > On 2015-03-17 at 03:09:23 +0100, Mi?tek Bak wrote: >> As with 7.10.1-rc2, installation fails on CentOS 6 (i386), Debian 6, and Ubuntu 10.04 LTS, in one of two following ways ? >> >> 1. On i386: >> >> "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/ghc-prim dist-install "strip" '' '/app/ghc' '/app/ghc/lib/ghc-7.10.0.20150316' '/app/ghc/share/doc/ghc/html/libraries' 'v p dyn' >> ghc-cabal/dist-install/build/tmp/ghc-cabal: symbol lookup error: libraries/integer-gmp2/dist-install/build/libHSinteger-gmp-1.0.0.0-6zeGtnFHpaVBJ80QaL9uVu-ghc7.10.0.20150316.so: undefined symbol: __gmpn_ior_n > > Well, it shouldn't be very surprising that the deb7 (wheezy) ghc bindist > doesn't work on deb6 (squeeze), as it's been compile-time configured for > the environment provided by deb7 which has newer libraries with more > features/symbols. > > So what's needed here is probably a 2nd linux bindist build on an > ancient enough (i.e. the one with the oldest libraries among > CentOS6/Deb6/Ubuntu10.04) Linux environment. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From oleg.grenrus at iki.fi Tue Mar 17 08:35:26 2015 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 17 Mar 2015 10:35:26 +0200 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: <87vbi0kp2p.fsf@gmail.com> References: <4FF22F98-5B3F-4A0A-8BEB-1DE1A71BAC51@bak.io> <87vbi0kp2p.fsf@gmail.com> Message-ID: <5507E74E.6050209@iki.fi> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have made docker images if anyone is interested: https://registry.hub.docker.com/u/phadej/ghc/ - --- And we could use docker as build environment (for obscure distros), at least it seems to have Debian 6 (squeeze) image available. I could try to do that, if someone else thinks this is a good idea too. - - Oleg On 17/03/15 10:25, Herbert Valerio Riedel wrote: > On 2015-03-17 at 03:09:23 +0100, Mi?tek Bak wrote: >> As with 7.10.1-rc2, installation fails on CentOS 6 (i386), Debian >> 6, and Ubuntu 10.04 LTS, in one of two following ways ? >> >> 1. On i386: >> >> "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy >> libraries/ghc-prim dist-install "strip" '' '/app/ghc' >> '/app/ghc/lib/ghc-7.10.0.20150316' >> '/app/ghc/share/doc/ghc/html/libraries' 'v p dyn' >> ghc-cabal/dist-install/build/tmp/ghc-cabal: symbol lookup error: >> libraries/integer-gmp2/dist-install/build/libHSinteger-gmp-1.0.0.0-6zeGtnFHpaVBJ80QaL9uVu-ghc7.10.0.20150316.so: >> undefined symbol: __gmpn_ior_n > > Well, it shouldn't be very surprising that the deb7 (wheezy) ghc > bindist doesn't work on deb6 (squeeze), as it's been compile-time > configured for the environment provided by deb7 which has newer > libraries with more features/symbols. > > So what's needed here is probably a 2nd linux bindist build on an > ancient enough (i.e. the one with the oldest libraries among > CentOS6/Deb6/Ubuntu10.04) Linux environment. > _______________________________________________ ghc-devs mailing > list ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVB+dOAAoJEOt5Bae4uwukNMwQAL0XPXMlCoKpVtyc11Eu+OTG Tbdf9nP016MODCSKBwGZRFT8uK3mTs5/K7yy7HvXDjQ1rYQbgSDfUBKogY0628PC M6CcZE7BbGClDv/U6l2dgMVz6jFm94yqj5/mk4HcmpEFlyaSwedkrtchvITcFEZr cc5t5S2SpeVL89ijAPGfFH9yQpyWcVux+nWukSZ+ZG0vFg73Pr+WJUNKfKuJSinb Q0MdieyHLw5zDmYaedprLtM0Mj+jASUFc2cC3+lLPTdxVlNRlKH1QiLbYZtS8SrQ xvc9ZfaynD2prALQjGhyrkOWmc08zB3N6mJb63dfBAfY+D8qieTXRekNK182wd0d UWGB4N92UROqt0QenfcCV3V0RN86gPmnGQd1k8BDDL2vyOkBMUBWEXQrwZau+GfS 3SxGyKBvD8Rjk6IYT29uKMmN3V0k4+K8BTy0wYPIncYngdaMNQeRH6vO5UkzyH1E oecE441nYE8+8vZY0p9kPsnzNnCd2mpZZGnWyl4uIHQ4B3TUfQJ7hveAubAywNj4 3dAzojKndMXqcXA0sQmXqV1vvD3dkHGwa5LFKG/z2nJVxugkOq+M1kIJygxQGMJ9 77IlDtHmFtz7huYdSy0A+wgtbchpFjxtzYU4SldozMeGQ/C9HClv0n/TVw3wXpge KH1TaDPTHI4nm5oPIe3q =bQHs -----END PGP SIGNATURE----- From simonpj at microsoft.com Tue Mar 17 10:55:31 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Mar 2015 10:55:31 +0000 Subject: Testsuite broken on windows Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BF6F4B4@DB3PRD3001MB020.064d.mgd.msft.net> Thomas AAAARGH! Windows build is broken again. Could you please fix? Soon! I got going again by reverting the last four commits to testsuite/, but there's some complication with the hpc submodule so I couldn't do it mechanically. Better to fix it properly Thanks Simon python ../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs'" -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 --threads=5 --verbose=3 -e clean_only=False --rootdir=. --config=../config/ghc -e 'config.confdir="../config"' -e 'config.platform="i386-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="i386"' -e 'config.wordsize="32"' -e 'default_testopts.cleanup="1"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="C:/code/HEAD/testsuite"' -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.timeout_prog="\"../timeout/install-inplace/bin/timeout.exe\""' --output-summary "../../testsuite_summary.txt" --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/deepseq/tests --rootdir=../../libraries/directory/tests --rootdir=../../libraries/filepath/tests --rootdir=../../libraries/ghc-prim/tests --rootdir=../../libraries/haskeline/tests --rootdir=../../libraries/hpc/tests --rootdir=../../libraries/parallel/tests --rootdir=../../libraries/pretty/tests --rootdir=../../libraries/process/tests --rootdir=../../libraries/stm/tests --rootdir=../../libraries/template-haskell/tests --rootdir=../../libraries/containers/tests-ghc \ \ \ \ \ \ -e config.fast=1 \ Warning: Ignoring request to use threads as running on Windows Traceback (most recent call last): File "../driver/runtests.py", line 205, in pkginfo = getStdout([config.ghc_pkg, 'dump']) File "C:\code\HEAD\testsuite\driver\testlib.py", line 2277, in getStdout p = subprocess.Popen(strip_quotes(cmd), File "C:\code\HEAD\testsuite\driver\testutil.py", line 20, in strip_quotes return s.strip('\'"') AttributeError: 'list' object has no attribute 'strip' ../mk/test.mk:261: recipe for target 'test' failed make[2]: *** [test] Error 1 make[2]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' ../mk/test.mk:276: recipe for target 'fast' failed make[1]: *** [fast] Error 2 make[1]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' Makefile:117: recipe for target 'fasttest' failed make: *** [fasttest] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Tue Mar 17 11:12:24 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 17 Mar 2015 12:12:24 +0100 Subject: Testsuite broken on windows In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BF6F4B4@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BF6F4B4@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Simon, can you pull and try again. I'm very sorry, I really screwed up what should have been a small refactoring. Thomas On Tue, Mar 17, 2015 at 11:55 AM, Simon Peyton Jones wrote: > Thomas > > AAAARGH! Windows build is broken again. > > Could you please fix? Soon! > > I got going again by reverting the last four commits to testsuite/, but > there?s some complication with the hpc submodule so I couldn?t do it > mechanically. Better to fix it properly > > Thanks > > Simon > > python ../driver/runtests.py -e ghc_compiler_always_flags="'-fforce-recomp > -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts > -fno-warn-tabs'" -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 --threads=5 --verbose=3 -e clean_only=False > --rootdir=. --config=../config/ghc -e 'config.confdir="../config"' -e > 'config.platform="i386-unknown-mingw32"' -e 'config.os="mingw32"' -e > 'config.arch="i386"' -e 'config.wordsize="32"' -e > 'default_testopts.cleanup="1"' -e 'config.timeout=int() or config.timeout' > -e 'config.exeext=".exe"' -e 'config.top="C:/code/HEAD/testsuite"' -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.timeout_prog="\"../timeout/install-inplace/bin/timeout.exe\""' > --output-summary "../../testsuite_summary.txt" > --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/deepseq/tests > --rootdir=../../libraries/directory/tests > --rootdir=../../libraries/filepath/tests > --rootdir=../../libraries/ghc-prim/tests > --rootdir=../../libraries/haskeline/tests > --rootdir=../../libraries/hpc/tests > --rootdir=../../libraries/parallel/tests > --rootdir=../../libraries/pretty/tests > --rootdir=../../libraries/process/tests --rootdir=../../libraries/stm/tests > --rootdir=../../libraries/template-haskell/tests > --rootdir=../../libraries/containers/tests-ghc \ > > \ > > \ > > \ > > \ > > \ > > -e config.fast=1 \ > > > > Warning: Ignoring request to use threads as running on Windows > > Traceback (most recent call last): > > File "../driver/runtests.py", line 205, in > > pkginfo = getStdout([config.ghc_pkg, 'dump']) > > File "C:\code\HEAD\testsuite\driver\testlib.py", line 2277, in getStdout > > p = subprocess.Popen(strip_quotes(cmd), > > File "C:\code\HEAD\testsuite\driver\testutil.py", line 20, in strip_quotes > > return s.strip('\'"') > > AttributeError: 'list' object has no attribute 'strip' > > ../mk/test.mk:261: recipe for target 'test' failed > > make[2]: *** [test] Error 1 > > make[2]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' > > ../mk/test.mk:276: recipe for target 'fast' failed > > make[1]: *** [fast] Error 2 > > make[1]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' > > Makefile:117: recipe for target 'fasttest' failed > > make: *** [fasttest] Error 2 > > From simonpj at microsoft.com Tue Mar 17 11:25:54 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Mar 2015 11:25:54 +0000 Subject: Testsuite broken on windows In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7BF6F4B4@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BF72438@DB3PRD3001MB020.064d.mgd.msft.net> Don't worry. I break GHC all the time. A prompt repair is fantastic, thank you I'll try it S | -----Original Message----- | From: Thomas Miedema [mailto:thomasmiedema at gmail.com] | Sent: 17 March 2015 11:12 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Testsuite broken on windows | | Simon, | | can you pull and try again. | | I'm very sorry, I really screwed up what should have been a small | refactoring. | | Thomas | | | On Tue, Mar 17, 2015 at 11:55 AM, Simon Peyton Jones | wrote: | > Thomas | > | > AAAARGH! Windows build is broken again. | > | > Could you please fix? Soon! | > | > I got going again by reverting the last four commits to testsuite/, | > but there?s some complication with the hpc submodule so I couldn?t do | > it mechanically. Better to fix it properly | > | > Thanks | > | > Simon | > | > python ../driver/runtests.py -e | > ghc_compiler_always_flags="'-fforce-recomp | > -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts | > -fno-warn-tabs'" -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 --threads=5 --verbose=3 -e clean_only=False | > --rootdir=. --config=../config/ghc -e 'config.confdir="../config"' -e | > 'config.platform="i386-unknown-mingw32"' -e 'config.os="mingw32"' -e | > 'config.arch="i386"' -e 'config.wordsize="32"' -e | 'default_testopts.cleanup="1"' -e 'config.timeout=int() or | config.timeout' | > -e 'config.exeext=".exe"' -e 'config.top="C:/code/HEAD/testsuite"' -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.timeout_prog="\"../timeout/install- | inplace/bin/timeout.exe\""' | > --output-summary "../../testsuite_summary.txt" | > --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/deepseq/tests | > --rootdir=../../libraries/directory/tests | > --rootdir=../../libraries/filepath/tests | > --rootdir=../../libraries/ghc-prim/tests | > --rootdir=../../libraries/haskeline/tests | > --rootdir=../../libraries/hpc/tests | > --rootdir=../../libraries/parallel/tests | > --rootdir=../../libraries/pretty/tests | > --rootdir=../../libraries/process/tests | > --rootdir=../../libraries/stm/tests | > --rootdir=../../libraries/template-haskell/tests | > --rootdir=../../libraries/containers/tests-ghc \ | > | > \ | > | > \ | > | > \ | > | > \ | > | > \ | > | > -e config.fast=1 \ | > | > | > | > Warning: Ignoring request to use threads as running on Windows | > | > Traceback (most recent call last): | > | > File "../driver/runtests.py", line 205, in | > | > pkginfo = getStdout([config.ghc_pkg, 'dump']) | > | > File "C:\code\HEAD\testsuite\driver\testlib.py", line 2277, in | > getStdout | > | > p = subprocess.Popen(strip_quotes(cmd), | > | > File "C:\code\HEAD\testsuite\driver\testutil.py", line 20, in | > strip_quotes | > | > return s.strip('\'"') | > | > AttributeError: 'list' object has no attribute 'strip' | > | > ../mk/test.mk:261: recipe for target 'test' failed | > | > make[2]: *** [test] Error 1 | > | > make[2]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' | > | > ../mk/test.mk:276: recipe for target 'fast' failed | > | > make[1]: *** [fast] Error 2 | > | > make[1]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' | > | > Makefile:117: recipe for target 'fasttest' failed | > | > make: *** [fasttest] Error 2 | > | > From ndmitchell at gmail.com Tue Mar 17 12:52:49 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue, 17 Mar 2015 12:52:49 +0000 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: References: Message-ID: All of the mingw links give me 403 forbidden errors. Do they have permission issues? Thanks, Neil On Mon, Mar 16, 2015 at 8:30 PM, Austin Seipp wrote: > We are pleased to announce the third release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc3 > https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ > > This includes the source tarball and bindists for Windows and Debian > Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow > soon. These binaries and tarballs have an accompanying > SHA256SUMS file signed by my GPG key id (0x3B58D86F). > > We plan to make the 7.10.1 final release at the end of this week - so > please test as much as possible; bugs are much cheaper if we find them > before the release! > > The list of issues we plan on fixing can always be found in an > up-to-date form here: > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From austin at well-typed.com Tue Mar 17 13:47:00 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 17 Mar 2015 08:47:00 -0500 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: References: Message-ID: Neil, this has been fixed. On Tue, Mar 17, 2015 at 7:52 AM, Neil Mitchell wrote: > All of the mingw links give me 403 forbidden errors. Do they have > permission issues? > > Thanks, Neil > > > On Mon, Mar 16, 2015 at 8:30 PM, Austin Seipp wrote: >> We are pleased to announce the third release candidate for GHC 7.10.1: >> >> https://downloads.haskell.org/~ghc/7.10.1-rc3 >> https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ >> >> This includes the source tarball and bindists for Windows and Debian >> Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow >> soon. These binaries and tarballs have an accompanying >> SHA256SUMS file signed by my GPG key id (0x3B58D86F). >> >> We plan to make the 7.10.1 final release at the end of this week - so >> please test as much as possible; bugs are much cheaper if we find them >> before the release! >> >> The list of issues we plan on fixing can always be found in an >> up-to-date form here: >> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From karel.gardas at centrum.cz Tue Mar 17 13:48:26 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Tue, 17 Mar 2015 14:48:26 +0100 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: References: Message-ID: <550830AA.50608@centrum.cz> BTW, *-testsuite tarball contains bits left from the amd64/linux build so gmake test is not working due to missing /lib64/ld-linux* library for ghc-config. Solaris 11 builds are uploading now... Karel On 03/16/15 09:30 PM, Austin Seipp wrote: > We are pleased to announce the third release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc3 > https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ > > This includes the source tarball and bindists for Windows and Debian > Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow > soon. These binaries and tarballs have an accompanying > SHA256SUMS file signed by my GPG key id (0x3B58D86F). > > We plan to make the 7.10.1 final release at the end of this week - so > please test as much as possible; bugs are much cheaper if we find them > before the release! > > The list of issues we plan on fixing can always be found in an > up-to-date form here: > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 > From ndmitchell at gmail.com Tue Mar 17 13:58:30 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue, 17 Mar 2015 13:58:30 +0000 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: References: Message-ID: Confirmed, thanks a lot! On Tue, Mar 17, 2015 at 1:47 PM, Austin Seipp wrote: > Neil, this has been fixed. > > On Tue, Mar 17, 2015 at 7:52 AM, Neil Mitchell wrote: >> All of the mingw links give me 403 forbidden errors. Do they have >> permission issues? >> >> Thanks, Neil >> >> >> On Mon, Mar 16, 2015 at 8:30 PM, Austin Seipp wrote: >>> We are pleased to announce the third release candidate for GHC 7.10.1: >>> >>> https://downloads.haskell.org/~ghc/7.10.1-rc3 >>> https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ >>> >>> This includes the source tarball and bindists for Windows and Debian >>> Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow >>> soon. These binaries and tarballs have an accompanying >>> SHA256SUMS file signed by my GPG key id (0x3B58D86F). >>> >>> We plan to make the 7.10.1 final release at the end of this week - so >>> please test as much as possible; bugs are much cheaper if we find them >>> before the release! >>> >>> The list of issues we plan on fixing can always be found in an >>> up-to-date form here: >>> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 >>> >>> -- >>> Regards, >>> >>> Austin Seipp, Haskell Consultant >>> Well-Typed LLP, http://www.well-typed.com/ >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ From austin at well-typed.com Tue Mar 17 14:40:46 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 17 Mar 2015 09:40:46 -0500 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: <3D055B5C-0DBF-49D0-B398-21F25E0E627C@bak.io> References: <4FF22F98-5B3F-4A0A-8BEB-1DE1A71BAC51@bak.io> <87vbi0kp2p.fsf@gmail.com> <3D055B5C-0DBF-49D0-B398-21F25E0E627C@bak.io> Message-ID: The only reason they work on glibc 2.11 is, AFAIK, because we built separate CentOS 6.5 binaries for them. :) FWIW, the source should build fine on these platforms, so once we add the bindists for those systems, it should work Out Of The Box. But the Debian 7 bindist isn't going to work on them, that's true. We should probably rename the tarballs however... it's clear "deb7" and "centos65" aren't very enlightening names; something like "-glibc211-gmp4" vs "glibc212-gmp5" would be better, even if slightly longer. On Tue, Mar 17, 2015 at 3:33 AM, Mi?tek Bak wrote: > As I wrote previously ? the bindist name does mention ?deb7?, so perhaps this is all working as intended, and perhaps supporting such ancient distributions is not actually needed. > > However, the GHC 7.8.4, 7.8.3, and 7.8.2 bindists work fine with glibc 2.11, so this is a regression. > > > -- > Mi?tek > > > > > On 2015-03-17, at 08:25, Herbert Valerio Riedel wrote: > >> On 2015-03-17 at 03:09:23 +0100, Mi?tek Bak wrote: >>> As with 7.10.1-rc2, installation fails on CentOS 6 (i386), Debian 6, and Ubuntu 10.04 LTS, in one of two following ways ? >>> >>> 1. On i386: >>> >>> "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/ghc-prim dist-install "strip" '' '/app/ghc' '/app/ghc/lib/ghc-7.10.0.20150316' '/app/ghc/share/doc/ghc/html/libraries' 'v p dyn' >>> ghc-cabal/dist-install/build/tmp/ghc-cabal: symbol lookup error: libraries/integer-gmp2/dist-install/build/libHSinteger-gmp-1.0.0.0-6zeGtnFHpaVBJ80QaL9uVu-ghc7.10.0.20150316.so: undefined symbol: __gmpn_ior_n >> >> Well, it shouldn't be very surprising that the deb7 (wheezy) ghc bindist >> doesn't work on deb6 (squeeze), as it's been compile-time configured for >> the environment provided by deb7 which has newer libraries with more >> features/symbols. >> >> So what's needed here is probably a 2nd linux bindist build on an >> ancient enough (i.e. the one with the oldest libraries among >> CentOS6/Deb6/Ubuntu10.04) Linux environment. > > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From v.dijk.bas at gmail.com Tue Mar 17 16:25:34 2015 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Tue, 17 Mar 2015 17:25:34 +0100 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: References: Message-ID: On 16 March 2015 at 21:30, Austin Seipp wrote: > We are pleased to announce the third release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc3 > https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ I noticed that the Haddock docs return 404s: https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/libraries/Prelude.html From pali.gabor at gmail.com Tue Mar 17 17:46:00 2015 From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=) Date: Tue, 17 Mar 2015 18:46:00 +0100 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: References: Message-ID: 2015-03-16 21:30 GMT+01:00 Austin Seipp : > We are pleased to announce the third release candidate for GHC 7.10.1: > [..] FreeBSD [..] binary distributions will follow > soon. There you can find the FreeBSD tarballs and their checksums: http://haskell.inf.elte.hu/ghc/ghc-7.10.0.20150316-i386-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.10.0.20150316-i386-portbld-freebsd.tar.xz http://haskell.inf.elte.hu/ghc/ghc-7.10.0.20150316-x86_64-portbld-freebsd.tar.bz2 http://haskell.inf.elte.hu/ghc/ghc-7.10.0.20150316-x86_64-portbld-freebsd.tar.xz http://haskell.inf.elte.hu/ghc/SHA256SUMS A brief install guide is also available, although it says GHC 7.8.4, it shall work for this version as well: http://haskell.inf.elte.hu/ghc/README.html From dburke.gw at gmail.com Tue Mar 17 19:54:54 2015 From: dburke.gw at gmail.com (Doug Burke) Date: Tue, 17 Mar 2015 15:54:54 -0400 Subject: Minor doc patch for ghc 7.10 + did I submit the patch correctly/follow the process? Message-ID: I've submitted a small patch for 7.10.1 to the docs, to re-arrange the order of the "important changes", since - as a "casual" user, things like the AMP/BPP seem like they should be mentioned first, before changes labelled as experimental. The change is at https://phabricator.haskell.org/D736 I'm sending this email to a) make sure this change gets seen b) ask if I did this the right way; I'm happy to write this up as an addendum to the newcomers guide/something else on the wiki if it is a sensible path for a doc-only patch I followed a combination of the phabricator intro [1] and newcomers guide [2] but 1) I did not create a ticket; should I have done so? The existing documentation assumes that you are fixing a bug. It's not clearto me if "RFE to the docs" should be treated the same way 2) since the master branch doesn't contain the 7.10 doc file, and the newcomer guide assumes you are working from the master branch, I did # downloading the submodules seems excessive for a doc-only patch % git config --global url."git://github.com/ghc/packages-".insteadOf git:// github.com/ghc/packages/ % git clone --recursive git://github.com/ghc/ghc % cd git % arc install-certificate ... enter in the token as requested % git checkout ghc-7.10 # as I'm on a very slow download link the repository needed to be updated, so % git fetch origin % git pull origin ghc-7.10 # since some of these were in need of updating and 'arc diff' complained % git submodule update ... edit docs/users_guide/7.10.1-notes.xml # just to check I didn't make any obvious snafus % xmllint 7.10.1-notes.xml % git diff % git add 7.10.1-notes.xml % git commit -m '...' # finally get to arc; the first time I tried it complained about a missing "branch" # so I guessed it made sense to use the branch I had started with, rather than the # suggested one (which I think was master) % arc diff ghc-7.10 ... edit the file and guess at what to put in for reviewers (which I just left as blank and fortunately it looks like it defaults to something sensible). Which is a rather heavy weight process when all I wanted to do was re-organize several paragraphs of a text file! Note that I was lazy and didn't try building ghc since it really is a simple doc change and I didn't want to go and spend even more time working out what I needed to build ghc documentation. Doug [1] https://ghc.haskell.org/trac/ghc/wiki/Phabricator [2] https://ghc.haskell.org/trac/ghc/wiki/Newcomers -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Tue Mar 17 23:04:14 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Wed, 18 Mar 2015 00:04:14 +0100 Subject: Minor doc patch for ghc 7.10 + did I submit the patch correctly/follow the process? In-Reply-To: References: Message-ID: Hi Doug, thank you for describing the steps you took to submit a code review. That's quite useful. Your patch looks good too. > b) ask if I did this the right way; I'm happy to write this up as an > addendum to the newcomers guide/something else on the wiki if it is a > sensible path for a doc-only patch Those steps you mention seem about right. Only this would have gotten you there somewhat sooner: https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#GettingabranchGHC7.9orlater I don't think that the Newcomers page should have to mention that specific link however, because: 1. almost all patches are made for the master branch. That release notes file could be the only exception. 2. the wiki contains a lot of information that would be useful to read for newcomers, but we can't link to all of them 3. there is already a link to https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources 4. you proved you could make it happen without it Other things you mentioned: > 1) I did not create a ticket; should I have done so? Just a Phabricator code review is ok for small patches. Since we started using Phabricator, quite a few patches have been submitted and accepted without a ticket number. This workflow is however not mentioned on the wiki yet. > downloading the submodules seems excessive for a doc-only patch Maybe, but it's also more simple to just have one explanation for how to get the sources instead of two. But if you think the Newcomers page could be improved, please feel free to edit it. -Thomas P.S. The Newcomers page makes you download from Github to prevent git.haskell.org from becomming overloaded when the Newcomers page gets linked from reddit. From dburke.gw at gmail.com Tue Mar 17 23:45:18 2015 From: dburke.gw at gmail.com (Doug Burke) Date: Tue, 17 Mar 2015 19:45:18 -0400 Subject: Minor doc patch for ghc 7.10 + did I submit the patch correctly/follow the process? In-Reply-To: References: Message-ID: Thanks for the confirmation. There's always a tension between simplicity and completeness, but I'll have a look and see if I can come up with some suggestions. Doug On Tue, Mar 17, 2015 at 7:04 PM, Thomas Miedema wrote: > Hi Doug, > > thank you for describing the steps you took to submit a code review. > That's quite useful. Your patch looks good too. > > > b) ask if I did this the right way; I'm happy to write this up as an > > addendum to the newcomers guide/something else on the wiki if it is a > > sensible path for a doc-only patch > > Those steps you mention seem about right. Only this would have gotten > you there somewhat sooner: > > https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#GettingabranchGHC7.9orlater > > I don't think that the Newcomers page should have to mention that > specific link however, because: > 1. almost all patches are made for the master branch. That release > notes file could be the only exception. > 2. the wiki contains a lot of information that would be useful to read > for newcomers, but we can't link to all of them > 3. there is already a link to > https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources > 4. you proved you could make it happen without it > > Other things you mentioned: > > 1) I did not create a ticket; should I have done so? > > Just a Phabricator code review is ok for small patches. Since we > started using Phabricator, quite a few patches have been submitted and > accepted without a ticket number. This workflow is however not > mentioned on the wiki yet. > > > downloading the submodules seems excessive for a doc-only patch > Maybe, but it's also more simple to just have one explanation for how > to get the sources instead of two. But if you think the Newcomers page > could be improved, please feel free to edit it. > > -Thomas > > P.S. The Newcomers page makes you download from Github to prevent > git.haskell.org from becomming overloaded when the Newcomers page gets > linked from reddit. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Wed Mar 18 00:14:36 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 17 Mar 2015 19:14:36 -0500 Subject: Minor doc patch for ghc 7.10 + did I submit the patch correctly/follow the process? In-Reply-To: References: Message-ID: Hi Doug, On Tue, Mar 17, 2015 at 2:54 PM, Doug Burke wrote: > 1) I did not create a ticket; should I have done so? The existing > documentation assumes that you are fixing a bug. It's not clearto me if > "RFE to the docs" should be treated the same way We like to have tickets for every revision. This is mostly because a ticket has more metadata; for example, I very regularly find out what I need to merge into the stable branch using tickets, not Phabricator. This occurs when people submit patches there, and change the status of the related ticket on Trac. This ensures I don't forget them, and it leaves a nice history in Trac about what-was-fixed-when. For small documentation changes like this, not having a ticket is fine; for future patches, you can simply use your better judgement on whether you think a full ticket is necessary. I don't think it is here. > 2) since the master branch doesn't contain the 7.10 doc file, and the > newcomer guide > assumes you are working from the master branch, I did > > # downloading the submodules seems excessive for a doc-only patch > % git config --global url."git://github.com/ghc/packages-".insteadOf > git://github.com/ghc/packages/ > % git clone --recursive git://github.com/ghc/ghc > % cd git > % arc install-certificate > ... enter in the token as requested > % git checkout ghc-7.10 > # as I'm on a very slow download link the repository needed to be updated, > so > % git fetch origin > % git pull origin ghc-7.10 FWIW, all of these steps can really be condensed into one: $ git clone -b ghc-7.10 --recursive git://git.haskell.org/ghc.git ghc-7.10 $ cd ghc-7.10/ $ ... hack hack hack ... This clones the 7.10 branch and all subrepositories. A similar incantation without the '-b' works for HEAD. In general, it's a bit easier to manage the branches by just using separate directories. You can use one directory, which is totally fine but it's easy to forget things like 'git submodule update' when you 'git checkout', and that's a bit annoying unfortunately. We should definitely fix the docs up a bit here. > # since some of these were in need of updating and 'arc diff' complained > % git submodule update > ... edit docs/users_guide/7.10.1-notes.xml > > # just to check I didn't make any obvious snafus > % xmllint 7.10.1-notes.xml > % git diff > > % git add 7.10.1-notes.xml > % git commit -m '...' > > # finally get to arc; the first time I tried it complained about a missing > "branch" > # so I guessed it made sense to use the branch I had started with, rather > than the > # suggested one (which I think was master) > % arc diff ghc-7.10 > ... edit the file and guess at what to put in for reviewers (which I just > left as blank > and fortunately it looks like it defaults to something sensible). The easiest way to submit a review, although there are several workflows, is, IMO: $ git checkout -b my-new-branch $ ... hack hack hack ... $ git commit -sm "new thing" $ arc diff "HEAD~" This basically says "Send the latest patch against my current branch to Phabricator", which is normally what most people want, since they're just sending up a small diff. Then you can keep saying: $ ... hack hack hack ... $ git commit -am "fix some things" $ arc diff $ ... hack hack hack ... $ git commit -am "fix some things" $ arc diff which will keep updating that particular review. You can also always say: $ arc which which will tell you the logic Arcanist used to compute diffs and why it did something. I've been meaning to clean up the Phabricator documentation on the wiki for a while; there are a few particular things that can handle 99% of workflows, but right now the doc page is a bit crammed. > Which is a rather heavy weight process when all I wanted to do was > re-organize several paragraphs of a text file! > > Note that I was lazy and didn't try building ghc since it really is a simple > doc change and I didn't want to go and spend even more time working out what > I needed to build ghc documentation. FWIW, you should just need DocBook, dblatex, etc. There are docs here: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation But also, we need to make it possible to build the documentation 'standalone', since right now it requires the build system (in some bizarre ways). Hopefully this will become easier when we move to AsciiDoc... In general our onboarding documentation could use a refactoring on this front. All suggestions appreciated! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From karel.gardas at centrum.cz Wed Mar 18 09:11:34 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 18 Mar 2015 10:11:34 +0100 Subject: HEAD not buildable by 7.10.1 RC3? Message-ID: <55094146.7050701@centrum.cz> Hi, for a few last days I'm not able to build amd64/solaris11 build of HEAD using 7.10.1. I've been using RC1 for this, then post RC2 and now RC3 and the issue is still the same: ld: fatal: library -lHSghc-7.11.20150318-5E218FiotzLAN97RtaMkIl: not found ld: fatal: file processing errors. No output written to ghc/stage1/build/tmp/ghc-stage1 collect2: ld returned 1 exit status gmake[1]: *** [ghc/stage1/build/tmp/ghc-stage1] Error 1 gmake: *** [all] Error 2 the problem is that the library which is created is named: libHSghc-7.11-5E218FiotzLAN97RtaMkIl.a and so is missing there, hence linking fails. I assume this may be caused by the patch below, but I'm not sure so if I'm mistaken here I'm sorry for this Edward. Anyway, I would like to raise this concern since we're already in RC3 for 7.10.1 and if something needs to be changed there, it would be better to do that rather sooner IMHO. Although this is issue on Solaris I assume it to be same on Linux, except that we probably don't have user/buildbot building HEAD with not yet release 7.10.1 and so we do not have this reported. Solaris11/amd64 is kind of special here, since the support for this platform is new in 7.10.1 and so I need to use this unreleased compiler. For compilation log please have a look into amd64/solaris11 buildbot output: http://haskell.inf.elte.hu/builders/solaris-amd64-head/232/10.html -- this is still using post-RC2 as a bootstrap compiler, but the issue with RC3 is the same. Thanks! Karel commit 838d8044896b6544d8c80c2ab5de63d97220f06c Author: Edward Z. Yang Date: Wed Mar 11 14:53:17 2015 +0100 Update Cabal submodule to latest 1.22 snapshot This changes the library file name format NOTE: This patch originally updated to Cabal HEAD, but was reduced to update to Cabal 1.22 HEAD by hvr as this is needed in order to update the filepath submodule to version 1.4.0, and subsequently to be cherry-picked into the ghc-7.10 branch Signed-off-by: Edward Z. Yang Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D707 From gale at sefer.org Wed Mar 18 15:10:36 2015 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 18 Mar 2015 17:10:36 +0200 Subject: Bootstrapping 7.8 using 7.10 Message-ID: Moving here from Reddit, as suggested by Herbert. This a continuation of a thread that started with Edward Yang's post here: http://mail.haskell.org/pipermail/glasgow-haskell-users/2014-October/025389.html continued here, a few months later: http://mail.haskell.org/pipermail/glasgow-haskell-users/2014-December/025529.html and ended here, in the following month: http://mail.haskell.org/pipermail/glasgow-haskell-users/2015-January/025551.html Herbert Valerio Riedel wrote on Reddit (http://www.reddit.com/r/haskell/comments/2zc2jg/ghc_7101_rc3_is_out_test_it_while_its_fresh/cpindvt) > I think I remember what the problem was with your patch (and why it > wasn't picked up rightaway): you needed tweaks to boot packages such > as transformers would cause the GHC source-tarball to diverge from > the officially released upstream packages. One solution would be to > rather provide an out-of-tree patch a user can apply manually, > rather than making an official GHC 7.8.5 release with unofficial > modifications to upstream packages (which would also require some > administration overhead on the Git level as upstream packages are > automatically mirrored Git submodules). I think Edward's last post (in January, linked above) addressed those concerns. In summary: release upstream point releases for hpc and hoopl that only bump the dependencies of base and time, and provide instance Applicative IO in the GHC sources for 7.8.5 so that no change is needed for transformers. Will that work? Can we go with this? Thanks, Yitz From ndmitchell at gmail.com Wed Mar 18 15:33:00 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed, 18 Mar 2015 15:33:00 +0000 Subject: Shake fails test with GHC 7.10 RC3 Message-ID: Hi, Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch the wrong exception in the wrong place. It's only hit by one of my tests, and I've managed to isolate it to a fragment of code with no unsafePerformIO, that throws exceptions using error (so not in IO), and operates in IO. Turning off the stack hack makes the bug go away, but then so does -O0, marking one of the functions it calls NOINLINE, or moving an INLINE function it calls to a different module, or adding a putStrLn under a catch block - it's very sensitive to the exact conditions. This test and this exact code worked fine with GHC 7.10 RC2. I was wondering if there have been any state hack related changes or other potentially dangerous optimisation changes since RC2? I'll continue to try reducing the bug, but it's somewhat difficult as the larger system is quite big, and the code is very sensitive. Thanks, Neil From hvriedel at gmail.com Wed Mar 18 16:05:19 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 18 Mar 2015 17:05:19 +0100 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: (Neil Mitchell's message of "Wed, 18 Mar 2015 15:33:00 +0000") References: Message-ID: <87fv92qojk.fsf@gmail.com> On 2015-03-18 at 16:33:00 +0100, Neil Mitchell wrote: [...] > I was wondering if there have been any state hack related changes or > other potentially dangerous optimisation changes since RC2? I'll > continue to try reducing the bug, but it's somewhat difficult as the > larger system is quite big, and the code is very sensitive. Fwiw, here's the Git history-fragment between RC2 and RC3: https://github.com/ghc/ghc/compare/174082ffeb69b2f9df19e7af7b63a331dd074145...feccb32bd54e0d01d4393c0eeaf7da890760664a HTH, hvr From simonpj at microsoft.com Wed Mar 18 17:04:35 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 18 Mar 2015 17:04:35 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> I'm really sorry but I can't think of anything. Sounds horrible. If you throw exceptions using 'error' (not in IO), then you are of course vulnerable to strictness changes. If the thing isn't actually evaluated inside the catch block, you won't see the exception. But I'm sure you've thought of that. I'd experiment with one of the smaller changes you describe, such as adding a putStrLn, and comparing Core, before and after. Switching off -O will make a huge difference, so hard to compare. Turning off the state hack will have a more global effect. But the other changes sound more pin-point and hence the differences will be smaller. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Neil | Mitchell | Sent: 18 March 2015 15:33 | To: ghc-devs at haskell.org | Subject: Shake fails test with GHC 7.10 RC3 | | Hi, | | Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch the | wrong exception in the wrong place. It's only hit by one of my tests, | and I've managed to isolate it to a fragment of code with no | unsafePerformIO, that throws exceptions using error (so not in IO), and | operates in IO. Turning off the stack hack makes the bug go away, but | then so does -O0, marking one of the functions it calls NOINLINE, or | moving an INLINE function it calls to a different module, or adding a | putStrLn under a catch block - it's very sensitive to the exact | conditions. This test and this exact code worked fine with GHC 7.10 | RC2. | | I was wondering if there have been any state hack related changes or | other potentially dangerous optimisation changes since RC2? I'll | continue to try reducing the bug, but it's somewhat difficult as the | larger system is quite big, and the code is very sensitive. | | Thanks, Neil | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ezyang at mit.edu Wed Mar 18 22:31:57 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 18 Mar 2015 15:31:57 -0700 Subject: HEAD not buildable by 7.10.1 RC3? In-Reply-To: <55094146.7050701@centrum.cz> References: <55094146.7050701@centrum.cz> Message-ID: <1426717898-sup-3261@sabre> It's just a build system bug. I think this fixes it: https://phabricator.haskell.org/D740 Edward Excerpts from Karel Gardas's message of 2015-03-18 02:11:34 -0700: > > Hi, > > for a few last days I'm not able to build amd64/solaris11 build of HEAD > using 7.10.1. I've been using RC1 for this, then post RC2 and now RC3 > and the issue is still the same: > > ld: fatal: library -lHSghc-7.11.20150318-5E218FiotzLAN97RtaMkIl: not found > ld: fatal: file processing errors. No output written to > ghc/stage1/build/tmp/ghc-stage1 > collect2: ld returned 1 exit status > gmake[1]: *** [ghc/stage1/build/tmp/ghc-stage1] Error 1 > gmake: *** [all] Error 2 > > > the problem is that the library which is created is named: > libHSghc-7.11-5E218FiotzLAN97RtaMkIl.a and so is > missing there, hence linking fails. > > I assume this may be caused by the patch below, but I'm not sure so if > I'm mistaken here I'm sorry for this Edward. > > Anyway, I would like to raise this concern since we're already in RC3 > for 7.10.1 and if something needs to be changed there, it would be > better to do that rather sooner IMHO. Although this is issue on Solaris > I assume it to be same on Linux, except that we probably don't have > user/buildbot building HEAD with not yet release 7.10.1 and so we do not > have this reported. Solaris11/amd64 is kind of special here, since the > support for this platform is new in 7.10.1 and so I need to use this > unreleased compiler. > > For compilation log please have a look into amd64/solaris11 buildbot > output: > http://haskell.inf.elte.hu/builders/solaris-amd64-head/232/10.html -- > this is still using post-RC2 as a bootstrap compiler, but the issue with > RC3 is the same. > > > Thanks! > Karel > > > > commit 838d8044896b6544d8c80c2ab5de63d97220f06c > Author: Edward Z. Yang > Date: Wed Mar 11 14:53:17 2015 +0100 > > Update Cabal submodule to latest 1.22 snapshot > > This changes the library file name format > > NOTE: This patch originally updated to Cabal HEAD, but was reduced to > update to Cabal 1.22 HEAD by hvr as this is needed in order to > update the filepath submodule to version 1.4.0, and subsequently > to be cherry-picked into the ghc-7.10 branch > > Signed-off-by: Edward Z. Yang > > Reviewed By: austin > > Differential Revision: https://phabricator.haskell.org/D707 From ezyang at mit.edu Wed Mar 18 22:53:19 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 18 Mar 2015 15:53:19 -0700 Subject: Bootstrapping 7.8 using 7.10 In-Reply-To: References: Message-ID: <1426719166-sup-4422@sabre> Since 7.10 moved onto a new major version of filepath, a bunch more of module bumps is necessary. Edward Excerpts from Yitzchak Gale's message of 2015-03-18 08:10:36 -0700: > Moving here from Reddit, as suggested by Herbert. > This a continuation of a thread that started with > Edward Yang's post here: > > http://mail.haskell.org/pipermail/glasgow-haskell-users/2014-October/025389.html > > continued here, a few months later: > > http://mail.haskell.org/pipermail/glasgow-haskell-users/2014-December/025529.html > > and ended here, in the following month: > > http://mail.haskell.org/pipermail/glasgow-haskell-users/2015-January/025551.html > > Herbert Valerio Riedel wrote on Reddit > (http://www.reddit.com/r/haskell/comments/2zc2jg/ghc_7101_rc3_is_out_test_it_while_its_fresh/cpindvt) > > > I think I remember what the problem was with your patch (and why it > > wasn't picked up rightaway): you needed tweaks to boot packages such > > as transformers would cause the GHC source-tarball to diverge from > > the officially released upstream packages. One solution would be to > > rather provide an out-of-tree patch a user can apply manually, > > rather than making an official GHC 7.8.5 release with unofficial > > modifications to upstream packages (which would also require some > > administration overhead on the Git level as upstream packages are > > automatically mirrored Git submodules). > > I think Edward's last post (in January, linked above) addressed those > concerns. In summary: release upstream point releases for hpc and > hoopl that only bump the dependencies of base and time, and provide > instance Applicative IO in the GHC sources for 7.8.5 so that no change > is needed for transformers. > > Will that work? Can we go with this? > > Thanks, > Yitz From ezyang at mit.edu Wed Mar 18 23:34:34 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 18 Mar 2015 16:34:34 -0700 Subject: Bootstrapping 7.8 using 7.10 In-Reply-To: References: Message-ID: <1426720995-sup-8637@sabre> OK, let me clarify the modern situation right now: - Libraries which need to have their bounds bumped are now hpc, hoopl, haskeline, terminfo, Cabal (the new ones are due to the filepath bump) - An alternative to the transformers issue is to simply remove transformers as a bootstrap package. This is what my current ghc-7.8 branch does. Cheers, Edward Excerpts from Yitzchak Gale's message of 2015-03-18 08:10:36 -0700: > Moving here from Reddit, as suggested by Herbert. > This a continuation of a thread that started with > Edward Yang's post here: > > http://mail.haskell.org/pipermail/glasgow-haskell-users/2014-October/025389.html > > continued here, a few months later: > > http://mail.haskell.org/pipermail/glasgow-haskell-users/2014-December/025529.html > > and ended here, in the following month: > > http://mail.haskell.org/pipermail/glasgow-haskell-users/2015-January/025551.html > > Herbert Valerio Riedel wrote on Reddit > (http://www.reddit.com/r/haskell/comments/2zc2jg/ghc_7101_rc3_is_out_test_it_while_its_fresh/cpindvt) > > > I think I remember what the problem was with your patch (and why it > > wasn't picked up rightaway): you needed tweaks to boot packages such > > as transformers would cause the GHC source-tarball to diverge from > > the officially released upstream packages. One solution would be to > > rather provide an out-of-tree patch a user can apply manually, > > rather than making an official GHC 7.8.5 release with unofficial > > modifications to upstream packages (which would also require some > > administration overhead on the Git level as upstream packages are > > automatically mirrored Git submodules). > > I think Edward's last post (in January, linked above) addressed those > concerns. In summary: release upstream point releases for hpc and > hoopl that only bump the dependencies of base and time, and provide > instance Applicative IO in the GHC sources for 7.8.5 so that no change > is needed for transformers. > > Will that work? Can we go with this? > > Thanks, > Yitz From jan.stolarek at p.lodz.pl Thu Mar 19 08:13:31 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 19 Mar 2015 09:13:31 +0100 Subject: Extracting kind variables from LHsTyVarBndr Message-ID: <201503190913.31803.jan.stolarek@p.lodz.pl> forall hi, is there a function somewhere in the source code that extracts kind variable names from LHsTyVarBndr? I couldn't find anything. Writing one seems a bit scary given the fact that not all fields in HsType constructors are obvious to me. Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From simonpj at microsoft.com Thu Mar 19 10:36:29 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 19 Mar 2015 10:36:29 +0000 Subject: [Diffusion] [Committed] rHADDOCK4bb685bd0f57: Track changes in HsSyn for quasi-quotes In-Reply-To: <20150319001317.30738.92799@phabricator.haskell.org> References: <20150319001317.30738.92799@phabricator.haskell.org> Message-ID: <6f7455e63ada4033a35b00a900b89d71@DB4PR30MB030.064d.mgd.msft.net> Austin I'm puzzled about this. This relates to something I did ages ago, and I thought was fully committed. I didn't intend to commit anything yesterday. Something mysterious. I hope I have not messed up. Simon | -----Original Message----- | From: noreply at phabricator.haskell.org | [mailto:noreply at phabricator.haskell.org] | Sent: 19 March 2015 00:13 | To: Simon Peyton Jones | Subject: [Diffusion] [Committed] rHADDOCK4bb685bd0f57: Track changes in | HsSyn for quasi-quotes | | simonpj committed rHADDOCK4bb685bd0f57: Track changes in HsSyn for | quasi-quotes (authored by simonpj). | | Track changes in HsSyn for quasi-quotes | | | AFFECTED FILES | /haddock-api/src/Haddock/Backends/LaTeX.hs | /haddock-api/src/Haddock/Backends/Xhtml/Decl.hs | /haddock-api/src/Haddock/Interface/Rename.hs | | USERS | simonpj (Author) | | COMMIT | https://phabricator.haskell.org/rHADDOCK4bb685bd0f57 | | REPLY HANDLER ACTIONS | Reply to comment. | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj From hvriedel at gmail.com Thu Mar 19 10:54:05 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 19 Mar 2015 11:54:05 +0100 Subject: [Diffusion] [Committed] rHADDOCK4bb685bd0f57: Track changes in HsSyn for quasi-quotes In-Reply-To: <6f7455e63ada4033a35b00a900b89d71@DB4PR30MB030.064d.mgd.msft.net> (Simon Peyton Jones's message of "Thu, 19 Mar 2015 10:36:29 +0000") References: <20150319001317.30738.92799@phabricator.haskell.org> <6f7455e63ada4033a35b00a900b89d71@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87fv915kc2.fsf@gmail.com> On 2015-03-19 at 11:36:29 +0100, Simon Peyton Jones wrote: > Austin > > I'm puzzled about this. This relates to something I did ages ago, and > I thought was fully committed. I didn't intend to commit anything > yesterday. Something mysterious. I hope I have not messed up. I suspect that this is just Phabricator having picked up only now; that commit had been pushed in the Haddock since at least http://git.haskell.org/ghc.git/commitdiff/f46360ed7139ff25741b381647b0a0b6d1000d84 (that's the commit in ghc.git that updated the haddock gitlink to point to 4bb685bd0f57, hence that commit had to be in there already back then) So this is most likely some harmless symptom... nothing to worry :) > Simon > > | -----Original Message----- > | From: noreply at phabricator.haskell.org > | [mailto:noreply at phabricator.haskell.org] > | Sent: 19 March 2015 00:13 > | To: Simon Peyton Jones > | Subject: [Diffusion] [Committed] rHADDOCK4bb685bd0f57: Track changes in > | HsSyn for quasi-quotes > | > | simonpj committed rHADDOCK4bb685bd0f57: Track changes in HsSyn for > | quasi-quotes (authored by simonpj). > | > | Track changes in HsSyn for quasi-quotes > | > | > | AFFECTED FILES > | /haddock-api/src/Haddock/Backends/LaTeX.hs > | /haddock-api/src/Haddock/Backends/Xhtml/Decl.hs > | /haddock-api/src/Haddock/Interface/Rename.hs > | > | USERS > | simonpj (Author) > | > | COMMIT > | https://phabricator.haskell.org/rHADDOCK4bb685bd0f57 > | > | REPLY HANDLER ACTIONS > | Reply to comment. > | > | EMAIL PREFERENCES > | https://phabricator.haskell.org/settings/panel/emailpreferences/ > | > | To: simonpj > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- "Elegance is not optional" -- Richard O'Keefe From george.colpitts at gmail.com Thu Mar 19 13:53:58 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Thu, 19 Mar 2015 10:53:58 -0300 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: References: Message-ID: Do we have an ETA for a MacOS binary distribution? Regards George On Mon, Mar 16, 2015 at 5:30 PM, Austin Seipp wrote: > We are pleased to announce the third release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc3 > https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ > > This includes the source tarball and bindists for Windows and Debian > Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow > soon. These binaries and tarballs have an accompanying > SHA256SUMS file signed by my GPG key id (0x3B58D86F). > > We plan to make the 7.10.1 final release at the end of this week - so > please test as much as possible; bugs are much cheaper if we find them > before the release! > > The list of issues we plan on fixing can always be found in an > up-to-date form here: > https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Thu Mar 19 14:38:00 2015 From: juhpetersen at gmail.com (Jens Petersen) Date: Thu, 19 Mar 2015 23:38:00 +0900 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: References: <4FF22F98-5B3F-4A0A-8BEB-1DE1A71BAC51@bak.io> <87vbi0kp2p.fsf@gmail.com> <3D055B5C-0DBF-49D0-B398-21F25E0E627C@bak.io> Message-ID: On 17 March 2015 at 23:40, Austin Seipp wrote: > We should probably rename the tarballs however... it's clear "deb7" > and "centos65" aren't very enlightening names; something like > "-glibc211-gmp4" vs "glibc212-gmp5" would be better, even if slightly > longer. +1 I tried building RC3 on Fedora Rawhide and hit this surprise i686 failure: https://copr-be.cloud.fedoraproject.org/results/petersen/ghc-7.10/fedora-rawhide-i386/ghc-7.10.0.20150316-0.5.fc21/build.log [400kB] ``` "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db libraries/bootstrapping.conf -this-package-key ghc_FEyGu5JjJqTFXJN7t0AjtZ -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package-key array_3w0nMK0JfaFJPpLFn2yWAJ -package-key base_469rOtLAqwTGFEOGWxSUiQ -package-key binpa_IZvsDnGi11pBzTC71ohLx0 -package-key bytes_GyKPtAP9tDU8R3kplaOsGL -package-key conta_LC4pLE3kBzGKpeTiXrfSYW -package-key direc_CDNjUHiqrmpKhmAfHuWHQd -package-key filep_1vDJvPDP7mkAk0dVCj6gws -package-key hoopl_67gYDpMwqMo76vntD1o2bl -package-key hpc_JgusJLXnrCmLlRsEHGsV8F -package-key proce_8QjZAz7MOkA18YytQjzGwY -package-key time_GZv5NIWYuYvJeCRUBFgGQL -package-key trans_A1N0ErqCzkOAdEhQZ5kT5v -package-key unix_0eL7iagUGBD0Zhli8uoZQW -Wall -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010 -DSTAGE=1 -Rghc-timing -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/Pair.hs -o compiler/stage1/build/Pair.o compiler/utils/Pair.hs:38:32: Not in scope: ?<$>? Perhaps you meant one of these: ?<*>? (imported from Prelude), ?<+>? (imported from Outputable), ?<>? (imported from Outputable) ``` Not sure how reproducible it is: I am firing off another build now on Fedora 22 and 23: https://copr.fedoraproject.org/coprs/petersen/ghc-7.10/build/82399/ I managed to build RC3 on Fedora aarch64. Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Thu Mar 19 14:41:42 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 19 Mar 2015 15:41:42 +0100 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: References: Message-ID: I made an unofficial OS X build again [0]. I'd be happy to offer my services to make an official build as well if people are interested and know how to get this on the ghc download page. Regards, Erik [0] http://www.reddit.com/r/haskell/comments/2rims6/ghc_7100rc1_build_for_mac_os_x/ On Thu, Mar 19, 2015 at 2:53 PM, George Colpitts wrote: > Do we have an ETA for a MacOS binary distribution? > > Regards > George > > On Mon, Mar 16, 2015 at 5:30 PM, Austin Seipp wrote: >> >> We are pleased to announce the third release candidate for GHC 7.10.1: >> >> https://downloads.haskell.org/~ghc/7.10.1-rc3 >> https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ >> >> This includes the source tarball and bindists for Windows and Debian >> Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow >> soon. These binaries and tarballs have an accompanying >> SHA256SUMS file signed by my GPG key id (0x3B58D86F). >> >> We plan to make the 7.10.1 final release at the end of this week - so >> please test as much as possible; bugs are much cheaper if we find them >> before the release! >> >> The list of issues we plan on fixing can always be found in an >> up-to-date form here: >> https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > From karel.gardas at centrum.cz Thu Mar 19 14:45:20 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Thu, 19 Mar 2015 15:45:20 +0100 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: References: <4FF22F98-5B3F-4A0A-8BEB-1DE1A71BAC51@bak.io> <87vbi0kp2p.fsf@gmail.com> <3D055B5C-0DBF-49D0-B398-21F25E0E627C@bak.io> Message-ID: <550AE100.1020406@centrum.cz> On 03/19/15 03:38 PM, Jens Petersen wrote: > > I tried building RC3 on Fedora Rawhide and hit this surprise i686 failure: > Jens, are you by any chance building RC3 with RC1/2 ? If so, then this is not well supported. I already reported this issue to ghc-devs few days/weeks ago. Karel > https://copr-be.cloud.fedoraproject.org/results/petersen/ghc-7.10/fedora-rawhide-i386/ghc-7.10.0.20150316-0.5.fc21/build.log > [400kB] > > ``` > "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-db > libraries/bootstrapping.conf -this-package-key > ghc_FEyGu5JjJqTFXJN7t0AjtZ -hide-all-packages -i -icompiler/basicTypes > -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar > -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen > -icompiler/main -icompiler/nativeGen -icompiler/parser > -icompiler/prelude -icompiler/profiling -icompiler/rename > -icompiler/simplCore -icompiler/simplStg -icompiler/specialise > -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck > -icompiler/types -icompiler/utils -icompiler/vectorise > -icompiler/stage1/build -icompiler/stage1/build/autogen > -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. > -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -optP-include > -optPcompiler/stage1/build/autogen/cabal_macros.h -package-key > array_3w0nMK0JfaFJPpLFn2yWAJ -package-key base_469rOtLAqwTGFEOGWxSUiQ > -package-key binpa_IZvsDnGi11pBzTC71ohLx0 -package-key > bytes_GyKPtAP9tDU8R3kplaOsGL -package-key conta_LC4pLE3kBzGKpeTiXrfSYW > -package-key direc_CDNjUHiqrmpKhmAfHuWHQd -package-key > filep_1vDJvPDP7mkAk0dVCj6gws -package-key hoopl_67gYDpMwqMo76vntD1o2bl > -package-key hpc_JgusJLXnrCmLlRsEHGsV8F -package-key > proce_8QjZAz7MOkA18YytQjzGwY -package-key time_GZv5NIWYuYvJeCRUBFgGQL > -package-key trans_A1N0ErqCzkOAdEhQZ5kT5v -package-key > unix_0eL7iagUGBD0Zhli8uoZQW -Wall -fno-warn-name-shadowing > -this-package-key ghc -XHaskell2010 -DSTAGE=1 -Rghc-timing > -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir > compiler/stage1/build -stubdir compiler/stage1/build -c > compiler/utils/Pair.hs -o compiler/stage1/build/Pair.o > > compiler/utils/Pair.hs:38:32: > Not in scope: ?<$>? > Perhaps you meant one of these: > ?<*>? (imported from Prelude), ?<+>? (imported from Outputable), > ?<>? (imported from Outputable) > > ``` > > Not sure how reproducible it is: I am firing off another build now on Fedora 22 and 23: > > https://copr.fedoraproject.org/coprs/petersen/ghc-7.10/build/82399/ > > I managed to build RC3 on Fedora aarch64. > > Jens > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From juhpetersen at gmail.com Thu Mar 19 14:53:34 2015 From: juhpetersen at gmail.com (Jens Petersen) Date: Thu, 19 Mar 2015 23:53:34 +0900 Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 3 In-Reply-To: <550AE100.1020406@centrum.cz> References: <4FF22F98-5B3F-4A0A-8BEB-1DE1A71BAC51@bak.io> <87vbi0kp2p.fsf@gmail.com> <3D055B5C-0DBF-49D0-B398-21F25E0E627C@bak.io> <550AE100.1020406@centrum.cz> Message-ID: On 19 March 2015 at 23:45, Karel Gardas wrote: > On 03/19/15 03:38 PM, Jens Petersen wrote: >> >> I tried building RC3 on Fedora Rawhide and hit this surprise i686 failure: >> > > are you by any chance building RC3 with RC1/2 ? If so, then this is not > well supported. I already reported this issue to ghc-devs few days/weeks > ago. > >> Ah! Good point - yes building with RC2. Okay I will switch to ghc-7.8. Thanks! compiler/utils/Pair.hs:38:32: >> Not in scope: ?<$>? >> Perhaps you meant one of these: >> ?<*>? (imported from Prelude), ?<+>? (imported from Outputable), >> ?<>? (imported from Outputable) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Mar 19 14:44:10 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 19 Mar 2015 10:44:10 -0400 Subject: Extracting kind variables from LHsTyVarBndr In-Reply-To: <201503190913.31803.jan.stolarek@p.lodz.pl> References: <201503190913.31803.jan.stolarek@p.lodz.pl> Message-ID: Do you mean extract kind variable names from a LHsTyVarBndrs (note the 's' at the end!)? That's straightforward: use hsq_kvs. Or do you want to extract variables from an HsType? Then RnTypes.extractHsTyRdrTyVars might be of help. I hope this helps, Richard On Mar 19, 2015, at 4:13 AM, Jan Stolarek wrote: > forall hi, > > is there a function somewhere in the source code that extracts kind variable names from > LHsTyVarBndr? I couldn't find anything. Writing one seems a bit scary given the fact that not all > fields in HsType constructors are obvious to me. > > Janek > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From ndmitchell at gmail.com Thu Mar 19 23:07:13 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu, 19 Mar 2015 23:07:13 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: Herbert, thanks for the list of patches, nothing obvious there - my best guess is it's something incredibly sensitive and it only needs the tiniest change anywhere to make it happen. Things like moving NOINLINE monomorphic-type definitions from one module to another are causing the bug to appear/disappear, which isn't what I'd expect. Simon, changing from error to error in IO causes the bug to disappear, but then so do most things. The error return type is type IO (), so I suspect that forces it to be raised at the right place - but it's certainly one of the possibilities for what is going wrong. Diffing the Core is a great idea. I'll keep reducing and see what I get to. Given the sensitivity of the bug, I'm sure a NOINLINE on an out-of-the-way function will make it go away, so I can easily fix Shake itself - so I'm more tracking it down from the point of GHC now. Thanks, Neil On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones wrote: > I'm really sorry but I can't think of anything. Sounds horrible. > > If you throw exceptions using 'error' (not in IO), then you are of course vulnerable to strictness changes. If the thing isn't actually evaluated inside the catch block, you won't see the exception. But I'm sure you've thought of that. > > I'd experiment with one of the smaller changes you describe, such as adding a putStrLn, and comparing Core, before and after. Switching off -O will make a huge difference, so hard to compare. Turning off the state hack will have a more global effect. But the other changes sound more pin-point and hence the differences will be smaller. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Neil > | Mitchell > | Sent: 18 March 2015 15:33 > | To: ghc-devs at haskell.org > | Subject: Shake fails test with GHC 7.10 RC3 > | > | Hi, > | > | Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch the > | wrong exception in the wrong place. It's only hit by one of my tests, > | and I've managed to isolate it to a fragment of code with no > | unsafePerformIO, that throws exceptions using error (so not in IO), and > | operates in IO. Turning off the stack hack makes the bug go away, but > | then so does -O0, marking one of the functions it calls NOINLINE, or > | moving an INLINE function it calls to a different module, or adding a > | putStrLn under a catch block - it's very sensitive to the exact > | conditions. This test and this exact code worked fine with GHC 7.10 > | RC2. > | > | I was wondering if there have been any state hack related changes or > | other potentially dangerous optimisation changes since RC2? I'll > | continue to try reducing the bug, but it's somewhat difficult as the > | larger system is quite big, and the code is very sensitive. > | > | Thanks, Neil > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Thu Mar 19 23:24:59 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 19 Mar 2015 23:24:59 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> Message-ID: <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> Thanks! I think a -ddump-simpl before and after the smallest change the makes the difference would be illuminating. Simon | -----Original Message----- | From: Neil Mitchell [mailto:ndmitchell at gmail.com] | Sent: 19 March 2015 23:07 | To: Simon Peyton Jones | Cc: ghc-devs at haskell.org | Subject: Re: Shake fails test with GHC 7.10 RC3 | | Herbert, thanks for the list of patches, nothing obvious there - my | best guess is it's something incredibly sensitive and it only needs | the tiniest change anywhere to make it happen. Things like moving | NOINLINE monomorphic-type definitions from one module to another are | causing the bug to appear/disappear, which isn't what I'd expect. | | Simon, changing from error to error in IO causes the bug to disappear, | but then so do most things. The error return type is type IO (), so I | suspect that forces it to be raised at the right place - but it's | certainly one of the possibilities for what is going wrong. Diffing | the Core is a great idea. | | I'll keep reducing and see what I get to. Given the sensitivity of the | bug, I'm sure a NOINLINE on an out-of-the-way function will make it go | away, so I can easily fix Shake itself - so I'm more tracking it down | from the point of GHC now. | | Thanks, Neil | | | On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones | wrote: | > I'm really sorry but I can't think of anything. Sounds horrible. | > | > If you throw exceptions using 'error' (not in IO), then you are of | course vulnerable to strictness changes. If the thing isn't actually | evaluated inside the catch block, you won't see the exception. But I'm | sure you've thought of that. | > | > I'd experiment with one of the smaller changes you describe, such as | adding a putStrLn, and comparing Core, before and after. Switching off - | O will make a huge difference, so hard to compare. Turning off the state | hack will have a more global effect. But the other changes sound more | pin-point and hence the differences will be smaller. | > | > Simon | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | Neil | > | Mitchell | > | Sent: 18 March 2015 15:33 | > | To: ghc-devs at haskell.org | > | Subject: Shake fails test with GHC 7.10 RC3 | > | | > | Hi, | > | | > | Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch the | > | wrong exception in the wrong place. It's only hit by one of my | tests, | > | and I've managed to isolate it to a fragment of code with no | > | unsafePerformIO, that throws exceptions using error (so not in IO), | and | > | operates in IO. Turning off the stack hack makes the bug go away, | but | > | then so does -O0, marking one of the functions it calls NOINLINE, or | > | moving an INLINE function it calls to a different module, or adding | a | > | putStrLn under a catch block - it's very sensitive to the exact | > | conditions. This test and this exact code worked fine with GHC 7.10 | > | RC2. | > | | > | I was wondering if there have been any state hack related changes or | > | other potentially dangerous optimisation changes since RC2? I'll | > | continue to try reducing the bug, but it's somewhat difficult as the | > | larger system is quite big, and the code is very sensitive. | > | | > | Thanks, Neil | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ndmitchell at gmail.com Fri Mar 20 00:01:16 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri, 20 Mar 2015 00:01:16 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> Message-ID: More delving later, it seems the incorrect optimized version has been turned into: case (\ _ [Occ=Dead, OS=OneShot] -> error "here") of _ [Occ=Dead] {} While the working one has been turned into: errorFunc argument realWorldToken where errorFunc _ = error "here" I'm not familiar with case ... of _ {} - what does it mean when there are no alternatives to the case? And why isn't case on a literal lambda optimised out? Is it the OneShot annotation (perhaps coming from the state hack?) The full trace is at https://gist.github.com/ndmitchell/b222e04eb0c3a397c758. I've uploaded bad (optimises the error out) and good (works as expected) versions of the Core. The summary files are the subexpression that changed making a single difference (moving a monomorphic NOINLINE function from one module to another) plus the handful of functions they depend on, which I've reformatted/inlined/simplified to produce the expressions above. The full versions are the entire -ddump-simpl output from about halfway through the build, starting when the differences occur - let me know if you need further back. The dodgy function is "exec". Thanks, Neil On Thu, Mar 19, 2015 at 11:07 PM, Neil Mitchell wrote: > Herbert, thanks for the list of patches, nothing obvious there - my > best guess is it's something incredibly sensitive and it only needs > the tiniest change anywhere to make it happen. Things like moving > NOINLINE monomorphic-type definitions from one module to another are > causing the bug to appear/disappear, which isn't what I'd expect. > > Simon, changing from error to error in IO causes the bug to disappear, > but then so do most things. The error return type is type IO (), so I > suspect that forces it to be raised at the right place - but it's > certainly one of the possibilities for what is going wrong. Diffing > the Core is a great idea. > > I'll keep reducing and see what I get to. Given the sensitivity of the > bug, I'm sure a NOINLINE on an out-of-the-way function will make it go > away, so I can easily fix Shake itself - so I'm more tracking it down > from the point of GHC now. > > Thanks, Neil > > > On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones > wrote: >> I'm really sorry but I can't think of anything. Sounds horrible. >> >> If you throw exceptions using 'error' (not in IO), then you are of course vulnerable to strictness changes. If the thing isn't actually evaluated inside the catch block, you won't see the exception. But I'm sure you've thought of that. >> >> I'd experiment with one of the smaller changes you describe, such as adding a putStrLn, and comparing Core, before and after. Switching off -O will make a huge difference, so hard to compare. Turning off the state hack will have a more global effect. But the other changes sound more pin-point and hence the differences will be smaller. >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Neil >> | Mitchell >> | Sent: 18 March 2015 15:33 >> | To: ghc-devs at haskell.org >> | Subject: Shake fails test with GHC 7.10 RC3 >> | >> | Hi, >> | >> | Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch the >> | wrong exception in the wrong place. It's only hit by one of my tests, >> | and I've managed to isolate it to a fragment of code with no >> | unsafePerformIO, that throws exceptions using error (so not in IO), and >> | operates in IO. Turning off the stack hack makes the bug go away, but >> | then so does -O0, marking one of the functions it calls NOINLINE, or >> | moving an INLINE function it calls to a different module, or adding a >> | putStrLn under a catch block - it's very sensitive to the exact >> | conditions. This test and this exact code worked fine with GHC 7.10 >> | RC2. >> | >> | I was wondering if there have been any state hack related changes or >> | other potentially dangerous optimisation changes since RC2? I'll >> | continue to try reducing the bug, but it's somewhat difficult as the >> | larger system is quite big, and the code is very sensitive. >> | >> | Thanks, Neil >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs at haskell.org >> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs On Thu, Mar 19, 2015 at 11:24 PM, Simon Peyton Jones wrote: > Thanks! I think a -ddump-simpl before and after the smallest change the makes the difference would be illuminating. > > Simon > > | -----Original Message----- > | From: Neil Mitchell [mailto:ndmitchell at gmail.com] > | Sent: 19 March 2015 23:07 > | To: Simon Peyton Jones > | Cc: ghc-devs at haskell.org > | Subject: Re: Shake fails test with GHC 7.10 RC3 > | > | Herbert, thanks for the list of patches, nothing obvious there - my > | best guess is it's something incredibly sensitive and it only needs > | the tiniest change anywhere to make it happen. Things like moving > | NOINLINE monomorphic-type definitions from one module to another are > | causing the bug to appear/disappear, which isn't what I'd expect. > | > | Simon, changing from error to error in IO causes the bug to disappear, > | but then so do most things. The error return type is type IO (), so I > | suspect that forces it to be raised at the right place - but it's > | certainly one of the possibilities for what is going wrong. Diffing > | the Core is a great idea. > | > | I'll keep reducing and see what I get to. Given the sensitivity of the > | bug, I'm sure a NOINLINE on an out-of-the-way function will make it go > | away, so I can easily fix Shake itself - so I'm more tracking it down > | from the point of GHC now. > | > | Thanks, Neil > | > | > | On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones > | wrote: > | > I'm really sorry but I can't think of anything. Sounds horrible. > | > > | > If you throw exceptions using 'error' (not in IO), then you are of > | course vulnerable to strictness changes. If the thing isn't actually > | evaluated inside the catch block, you won't see the exception. But I'm > | sure you've thought of that. > | > > | > I'd experiment with one of the smaller changes you describe, such as > | adding a putStrLn, and comparing Core, before and after. Switching off - > | O will make a huge difference, so hard to compare. Turning off the state > | hack will have a more global effect. But the other changes sound more > | pin-point and hence the differences will be smaller. > | > > | > Simon > | > > | > | -----Original Message----- > | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | Neil > | > | Mitchell > | > | Sent: 18 March 2015 15:33 > | > | To: ghc-devs at haskell.org > | > | Subject: Shake fails test with GHC 7.10 RC3 > | > | > | > | Hi, > | > | > | > | Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch the > | > | wrong exception in the wrong place. It's only hit by one of my > | tests, > | > | and I've managed to isolate it to a fragment of code with no > | > | unsafePerformIO, that throws exceptions using error (so not in IO), > | and > | > | operates in IO. Turning off the stack hack makes the bug go away, > | but > | > | then so does -O0, marking one of the functions it calls NOINLINE, or > | > | moving an INLINE function it calls to a different module, or adding > | a > | > | putStrLn under a catch block - it's very sensitive to the exact > | > | conditions. This test and this exact code worked fine with GHC 7.10 > | > | RC2. > | > | > | > | I was wondering if there have been any state hack related changes or > | > | other potentially dangerous optimisation changes since RC2? I'll > | > | continue to try reducing the bug, but it's somewhat difficult as the > | > | larger system is quite big, and the code is very sensitive. > | > | > | > | Thanks, Neil > | > | _______________________________________________ > | > | ghc-devs mailing list > | > | ghc-devs at haskell.org > | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ndmitchell at gmail.com Fri Mar 20 00:12:29 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri, 20 Mar 2015 00:12:29 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Since I won't have access to my development computer during work hours tomorrow, I generated complete Core for both versions and put them in http://community.haskell.org/~ndm/temp/core.zip. Thanks, Neil On Fri, Mar 20, 2015 at 12:01 AM, Neil Mitchell wrote: > More delving later, it seems the incorrect optimized version has been > turned into: > > case (\ _ [Occ=Dead, OS=OneShot] -> error "here") of _ [Occ=Dead] {} > > While the working one has been turned into: > > errorFunc argument realWorldToken > > where errorFunc _ = error "here" > > I'm not familiar with case ... of _ {} - what does it mean when there > are no alternatives to the case? And why isn't case on a literal > lambda optimised out? Is it the OneShot annotation (perhaps coming > from the state hack?) > > The full trace is at > https://gist.github.com/ndmitchell/b222e04eb0c3a397c758. I've uploaded > bad (optimises the error out) and good (works as expected) versions of > the Core. The summary files are the subexpression that changed making > a single difference (moving a monomorphic NOINLINE function from one > module to another) plus the handful of functions they depend on, which > I've reformatted/inlined/simplified to produce the expressions above. > The full versions are the entire -ddump-simpl output from about > halfway through the build, starting when the differences occur - let > me know if you need further back. The dodgy function is "exec". > > Thanks, Neil > > On Thu, Mar 19, 2015 at 11:07 PM, Neil Mitchell wrote: >> Herbert, thanks for the list of patches, nothing obvious there - my >> best guess is it's something incredibly sensitive and it only needs >> the tiniest change anywhere to make it happen. Things like moving >> NOINLINE monomorphic-type definitions from one module to another are >> causing the bug to appear/disappear, which isn't what I'd expect. >> >> Simon, changing from error to error in IO causes the bug to disappear, >> but then so do most things. The error return type is type IO (), so I >> suspect that forces it to be raised at the right place - but it's >> certainly one of the possibilities for what is going wrong. Diffing >> the Core is a great idea. >> >> I'll keep reducing and see what I get to. Given the sensitivity of the >> bug, I'm sure a NOINLINE on an out-of-the-way function will make it go >> away, so I can easily fix Shake itself - so I'm more tracking it down >> from the point of GHC now. >> >> Thanks, Neil >> >> >> On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones >> wrote: >>> I'm really sorry but I can't think of anything. Sounds horrible. >>> >>> If you throw exceptions using 'error' (not in IO), then you are of course vulnerable to strictness changes. If the thing isn't actually evaluated inside the catch block, you won't see the exception. But I'm sure you've thought of that. >>> >>> I'd experiment with one of the smaller changes you describe, such as adding a putStrLn, and comparing Core, before and after. Switching off -O will make a huge difference, so hard to compare. Turning off the state hack will have a more global effect. But the other changes sound more pin-point and hence the differences will be smaller. >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Neil >>> | Mitchell >>> | Sent: 18 March 2015 15:33 >>> | To: ghc-devs at haskell.org >>> | Subject: Shake fails test with GHC 7.10 RC3 >>> | >>> | Hi, >>> | >>> | Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch the >>> | wrong exception in the wrong place. It's only hit by one of my tests, >>> | and I've managed to isolate it to a fragment of code with no >>> | unsafePerformIO, that throws exceptions using error (so not in IO), and >>> | operates in IO. Turning off the stack hack makes the bug go away, but >>> | then so does -O0, marking one of the functions it calls NOINLINE, or >>> | moving an INLINE function it calls to a different module, or adding a >>> | putStrLn under a catch block - it's very sensitive to the exact >>> | conditions. This test and this exact code worked fine with GHC 7.10 >>> | RC2. >>> | >>> | I was wondering if there have been any state hack related changes or >>> | other potentially dangerous optimisation changes since RC2? I'll >>> | continue to try reducing the bug, but it's somewhat difficult as the >>> | larger system is quite big, and the code is very sensitive. >>> | >>> | Thanks, Neil >>> | _______________________________________________ >>> | ghc-devs mailing list >>> | ghc-devs at haskell.org >>> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > On Thu, Mar 19, 2015 at 11:24 PM, Simon Peyton Jones > wrote: >> Thanks! I think a -ddump-simpl before and after the smallest change the makes the difference would be illuminating. >> >> Simon >> >> | -----Original Message----- >> | From: Neil Mitchell [mailto:ndmitchell at gmail.com] >> | Sent: 19 March 2015 23:07 >> | To: Simon Peyton Jones >> | Cc: ghc-devs at haskell.org >> | Subject: Re: Shake fails test with GHC 7.10 RC3 >> | >> | Herbert, thanks for the list of patches, nothing obvious there - my >> | best guess is it's something incredibly sensitive and it only needs >> | the tiniest change anywhere to make it happen. Things like moving >> | NOINLINE monomorphic-type definitions from one module to another are >> | causing the bug to appear/disappear, which isn't what I'd expect. >> | >> | Simon, changing from error to error in IO causes the bug to disappear, >> | but then so do most things. The error return type is type IO (), so I >> | suspect that forces it to be raised at the right place - but it's >> | certainly one of the possibilities for what is going wrong. Diffing >> | the Core is a great idea. >> | >> | I'll keep reducing and see what I get to. Given the sensitivity of the >> | bug, I'm sure a NOINLINE on an out-of-the-way function will make it go >> | away, so I can easily fix Shake itself - so I'm more tracking it down >> | from the point of GHC now. >> | >> | Thanks, Neil >> | >> | >> | On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones >> | wrote: >> | > I'm really sorry but I can't think of anything. Sounds horrible. >> | > >> | > If you throw exceptions using 'error' (not in IO), then you are of >> | course vulnerable to strictness changes. If the thing isn't actually >> | evaluated inside the catch block, you won't see the exception. But I'm >> | sure you've thought of that. >> | > >> | > I'd experiment with one of the smaller changes you describe, such as >> | adding a putStrLn, and comparing Core, before and after. Switching off - >> | O will make a huge difference, so hard to compare. Turning off the state >> | hack will have a more global effect. But the other changes sound more >> | pin-point and hence the differences will be smaller. >> | > >> | > Simon >> | > >> | > | -----Original Message----- >> | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >> | Neil >> | > | Mitchell >> | > | Sent: 18 March 2015 15:33 >> | > | To: ghc-devs at haskell.org >> | > | Subject: Shake fails test with GHC 7.10 RC3 >> | > | >> | > | Hi, >> | > | >> | > | Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch the >> | > | wrong exception in the wrong place. It's only hit by one of my >> | tests, >> | > | and I've managed to isolate it to a fragment of code with no >> | > | unsafePerformIO, that throws exceptions using error (so not in IO), >> | and >> | > | operates in IO. Turning off the stack hack makes the bug go away, >> | but >> | > | then so does -O0, marking one of the functions it calls NOINLINE, or >> | > | moving an INLINE function it calls to a different module, or adding >> | a >> | > | putStrLn under a catch block - it's very sensitive to the exact >> | > | conditions. This test and this exact code worked fine with GHC 7.10 >> | > | RC2. >> | > | >> | > | I was wondering if there have been any state hack related changes or >> | > | other potentially dangerous optimisation changes since RC2? I'll >> | > | continue to try reducing the bug, but it's somewhat difficult as the >> | > | larger system is quite big, and the code is very sensitive. >> | > | >> | > | Thanks, Neil >> | > | _______________________________________________ >> | > | ghc-devs mailing list >> | > | ghc-devs at haskell.org >> | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From carter.schonwald at gmail.com Fri Mar 20 15:45:22 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 20 Mar 2015 11:45:22 -0400 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> Message-ID: do you use a deepSeq when catching errors from a pure computation? Or is it in a context where you know the value should be treated strictly? ( https://github.com/ndmitchell/shake/issues/216 seems to be the ticket in question, but since i dont have a 7.10 handy and the test suite seems to be quite large, itd be super helpful if you could point out which tests are failing). On Thu, Mar 19, 2015 at 8:12 PM, Neil Mitchell wrote: > Since I won't have access to my development computer during work hours > tomorrow, I generated complete Core for both versions and put them in > http://community.haskell.org/~ndm/temp/core.zip. > > Thanks, Neil > > On Fri, Mar 20, 2015 at 12:01 AM, Neil Mitchell > wrote: > > More delving later, it seems the incorrect optimized version has been > > turned into: > > > > case (\ _ [Occ=Dead, OS=OneShot] -> error "here") of _ [Occ=Dead] {} > > > > While the working one has been turned into: > > > > errorFunc argument realWorldToken > > > > where errorFunc _ = error "here" > > > > I'm not familiar with case ... of _ {} - what does it mean when there > > are no alternatives to the case? And why isn't case on a literal > > lambda optimised out? Is it the OneShot annotation (perhaps coming > > from the state hack?) > > > > The full trace is at > > https://gist.github.com/ndmitchell/b222e04eb0c3a397c758. I've uploaded > > bad (optimises the error out) and good (works as expected) versions of > > the Core. The summary files are the subexpression that changed making > > a single difference (moving a monomorphic NOINLINE function from one > > module to another) plus the handful of functions they depend on, which > > I've reformatted/inlined/simplified to produce the expressions above. > > The full versions are the entire -ddump-simpl output from about > > halfway through the build, starting when the differences occur - let > > me know if you need further back. The dodgy function is "exec". > > > > Thanks, Neil > > > > On Thu, Mar 19, 2015 at 11:07 PM, Neil Mitchell > wrote: > >> Herbert, thanks for the list of patches, nothing obvious there - my > >> best guess is it's something incredibly sensitive and it only needs > >> the tiniest change anywhere to make it happen. Things like moving > >> NOINLINE monomorphic-type definitions from one module to another are > >> causing the bug to appear/disappear, which isn't what I'd expect. > >> > >> Simon, changing from error to error in IO causes the bug to disappear, > >> but then so do most things. The error return type is type IO (), so I > >> suspect that forces it to be raised at the right place - but it's > >> certainly one of the possibilities for what is going wrong. Diffing > >> the Core is a great idea. > >> > >> I'll keep reducing and see what I get to. Given the sensitivity of the > >> bug, I'm sure a NOINLINE on an out-of-the-way function will make it go > >> away, so I can easily fix Shake itself - so I'm more tracking it down > >> from the point of GHC now. > >> > >> Thanks, Neil > >> > >> > >> On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones > >> wrote: > >>> I'm really sorry but I can't think of anything. Sounds horrible. > >>> > >>> If you throw exceptions using 'error' (not in IO), then you are of > course vulnerable to strictness changes. If the thing isn't actually > evaluated inside the catch block, you won't see the exception. But I'm > sure you've thought of that. > >>> > >>> I'd experiment with one of the smaller changes you describe, such as > adding a putStrLn, and comparing Core, before and after. Switching off -O > will make a huge difference, so hard to compare. Turning off the state > hack will have a more global effect. But the other changes sound more > pin-point and hence the differences will be smaller. > >>> > >>> Simon > >>> > >>> | -----Original Message----- > >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > Neil > >>> | Mitchell > >>> | Sent: 18 March 2015 15:33 > >>> | To: ghc-devs at haskell.org > >>> | Subject: Shake fails test with GHC 7.10 RC3 > >>> | > >>> | Hi, > >>> | > >>> | Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch the > >>> | wrong exception in the wrong place. It's only hit by one of my > tests, > >>> | and I've managed to isolate it to a fragment of code with no > >>> | unsafePerformIO, that throws exceptions using error (so not in IO), > and > >>> | operates in IO. Turning off the stack hack makes the bug go away, > but > >>> | then so does -O0, marking one of the functions it calls NOINLINE, or > >>> | moving an INLINE function it calls to a different module, or adding > a > >>> | putStrLn under a catch block - it's very sensitive to the exact > >>> | conditions. This test and this exact code worked fine with GHC 7.10 > >>> | RC2. > >>> | > >>> | I was wondering if there have been any state hack related changes or > >>> | other potentially dangerous optimisation changes since RC2? I'll > >>> | continue to try reducing the bug, but it's somewhat difficult as the > >>> | larger system is quite big, and the code is very sensitive. > >>> | > >>> | Thanks, Neil > >>> | _______________________________________________ > >>> | ghc-devs mailing list > >>> | ghc-devs at haskell.org > >>> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > On Thu, Mar 19, 2015 at 11:24 PM, Simon Peyton Jones > > wrote: > >> Thanks! I think a -ddump-simpl before and after the smallest change > the makes the difference would be illuminating. > >> > >> Simon > >> > >> | -----Original Message----- > >> | From: Neil Mitchell [mailto:ndmitchell at gmail.com] > >> | Sent: 19 March 2015 23:07 > >> | To: Simon Peyton Jones > >> | Cc: ghc-devs at haskell.org > >> | Subject: Re: Shake fails test with GHC 7.10 RC3 > >> | > >> | Herbert, thanks for the list of patches, nothing obvious there - my > >> | best guess is it's something incredibly sensitive and it only needs > >> | the tiniest change anywhere to make it happen. Things like moving > >> | NOINLINE monomorphic-type definitions from one module to another are > >> | causing the bug to appear/disappear, which isn't what I'd expect. > >> | > >> | Simon, changing from error to error in IO causes the bug to disappear, > >> | but then so do most things. The error return type is type IO (), so I > >> | suspect that forces it to be raised at the right place - but it's > >> | certainly one of the possibilities for what is going wrong. Diffing > >> | the Core is a great idea. > >> | > >> | I'll keep reducing and see what I get to. Given the sensitivity of the > >> | bug, I'm sure a NOINLINE on an out-of-the-way function will make it go > >> | away, so I can easily fix Shake itself - so I'm more tracking it down > >> | from the point of GHC now. > >> | > >> | Thanks, Neil > >> | > >> | > >> | On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones > >> | wrote: > >> | > I'm really sorry but I can't think of anything. Sounds horrible. > >> | > > >> | > If you throw exceptions using 'error' (not in IO), then you are of > >> | course vulnerable to strictness changes. If the thing isn't actually > >> | evaluated inside the catch block, you won't see the exception. But > I'm > >> | sure you've thought of that. > >> | > > >> | > I'd experiment with one of the smaller changes you describe, such as > >> | adding a putStrLn, and comparing Core, before and after. Switching > off - > >> | O will make a huge difference, so hard to compare. Turning off the > state > >> | hack will have a more global effect. But the other changes sound more > >> | pin-point and hence the differences will be smaller. > >> | > > >> | > Simon > >> | > > >> | > | -----Original Message----- > >> | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf > Of > >> | Neil > >> | > | Mitchell > >> | > | Sent: 18 March 2015 15:33 > >> | > | To: ghc-devs at haskell.org > >> | > | Subject: Shake fails test with GHC 7.10 RC3 > >> | > | > >> | > | Hi, > >> | > | > >> | > | Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch > the > >> | > | wrong exception in the wrong place. It's only hit by one of my > >> | tests, > >> | > | and I've managed to isolate it to a fragment of code with no > >> | > | unsafePerformIO, that throws exceptions using error (so not in > IO), > >> | and > >> | > | operates in IO. Turning off the stack hack makes the bug go away, > >> | but > >> | > | then so does -O0, marking one of the functions it calls > NOINLINE, or > >> | > | moving an INLINE function it calls to a different module, or > adding > >> | a > >> | > | putStrLn under a catch block - it's very sensitive to the exact > >> | > | conditions. This test and this exact code worked fine with GHC > 7.10 > >> | > | RC2. > >> | > | > >> | > | I was wondering if there have been any state hack related > changes or > >> | > | other potentially dangerous optimisation changes since RC2? I'll > >> | > | continue to try reducing the bug, but it's somewhat difficult as > the > >> | > | larger system is quite big, and the code is very sensitive. > >> | > | > >> | > | Thanks, Neil > >> | > | _______________________________________________ > >> | > | ghc-devs mailing list > >> | > | ghc-devs at haskell.org > >> | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndmitchell at gmail.com Fri Mar 20 16:56:51 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri, 20 Mar 2015 16:56:51 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> Message-ID: > do you use a deepSeq when catching errors from a pure computation? Or is it > in a context where you know the value should be treated strictly? The computation is essentially (error "here" :: IO ()), so the IO monadic binding should force the exception. In the full source code to Shake it's actually in ContT/ReaderT/IO, but a modification to insert liftIO (if done in exactly the right way) gives the same result. That simplified code is at http://community.haskell.org/~ndm/temp/src.zip (to run, compile with the logic from https://github.com/ndmitchell/shake/blob/master/.ghci :benchmark, then run "main oracle test"). > https://github.com/ndmitchell/shake/issues/216 seems to be the ticket > in question That is the ticket. The test that is failing is the "oracle" (Test.Oracle) test suite, and you can see full logs of both success and failure at Travis: https://travis-ci.org/ndmitchell/shake/builds/54748475 . Note that it succeeds on GHC 7.2, 7.4, 7.6 and 7.8, but fails on GHC 7.10 RC3 and GHC Head. Alas, the actual error is coming from deep in the middle of Shake, specifically this line: https://github.com/ndmitchell/shake/blob/master/src/Development/Shake/Core.hs#L329 Thinking some more on what I saw, my best guess is that: case (\_ -> ...) of {} Is a fatal error in GHC. I am guessing that {} means there are no alternatives because GHC managed to show that the scrutinee throws an exception. In addition, evaluating a literal lambda to WHNF will not throw an exception, so you have a contradiction. Making increasingly wild speculative guesses, I could imagine this code compiling to CMM that just fell off the end of a basic block, arriving at the next statement of supposedly unconnected code. That actually matches what I'm seeing - I have the exception, using print I can see I am at the line before, and that I never get to the line after, but pop up somewhere nearby and continue onwards seemingly ignoring the exception ever happened. If someone can confirm the above pattern of Core is always illegal and always indicates a GHC error then I can reduce the test case driven purely by the Core, which would be far easier - at the moment Shake passes through these routines several times to set things up, making it harder to simplify them too much without changing the preparation steps. Thanks, Neil >> >> On Fri, Mar 20, 2015 at 12:01 AM, Neil Mitchell >> wrote: >> > More delving later, it seems the incorrect optimized version has been >> > turned into: >> > >> > case (\ _ [Occ=Dead, OS=OneShot] -> error "here") of _ [Occ=Dead] {} >> > >> > While the working one has been turned into: >> > >> > errorFunc argument realWorldToken >> > >> > where errorFunc _ = error "here" >> > >> > I'm not familiar with case ... of _ {} - what does it mean when there >> > are no alternatives to the case? And why isn't case on a literal >> > lambda optimised out? Is it the OneShot annotation (perhaps coming >> > from the state hack?) >> > >> > The full trace is at >> > https://gist.github.com/ndmitchell/b222e04eb0c3a397c758. I've uploaded >> > bad (optimises the error out) and good (works as expected) versions of >> > the Core. The summary files are the subexpression that changed making >> > a single difference (moving a monomorphic NOINLINE function from one >> > module to another) plus the handful of functions they depend on, which >> > I've reformatted/inlined/simplified to produce the expressions above. >> > The full versions are the entire -ddump-simpl output from about >> > halfway through the build, starting when the differences occur - let >> > me know if you need further back. The dodgy function is "exec". >> > >> > Thanks, Neil >> > >> > On Thu, Mar 19, 2015 at 11:07 PM, Neil Mitchell >> > wrote: >> >> Herbert, thanks for the list of patches, nothing obvious there - my >> >> best guess is it's something incredibly sensitive and it only needs >> >> the tiniest change anywhere to make it happen. Things like moving >> >> NOINLINE monomorphic-type definitions from one module to another are >> >> causing the bug to appear/disappear, which isn't what I'd expect. >> >> >> >> Simon, changing from error to error in IO causes the bug to disappear, >> >> but then so do most things. The error return type is type IO (), so I >> >> suspect that forces it to be raised at the right place - but it's >> >> certainly one of the possibilities for what is going wrong. Diffing >> >> the Core is a great idea. >> >> >> >> I'll keep reducing and see what I get to. Given the sensitivity of the >> >> bug, I'm sure a NOINLINE on an out-of-the-way function will make it go >> >> away, so I can easily fix Shake itself - so I'm more tracking it down >> >> from the point of GHC now. >> >> >> >> Thanks, Neil >> >> >> >> >> >> On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones >> >> wrote: >> >>> I'm really sorry but I can't think of anything. Sounds horrible. >> >>> >> >>> If you throw exceptions using 'error' (not in IO), then you are of >> >>> course vulnerable to strictness changes. If the thing isn't actually >> >>> evaluated inside the catch block, you won't see the exception. But I'm sure >> >>> you've thought of that. >> >>> >> >>> I'd experiment with one of the smaller changes you describe, such as >> >>> adding a putStrLn, and comparing Core, before and after. Switching off -O >> >>> will make a huge difference, so hard to compare. Turning off the state hack >> >>> will have a more global effect. But the other changes sound more pin-point >> >>> and hence the differences will be smaller. >> >>> >> >>> Simon >> >>> >> >>> | -----Original Message----- >> >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of >> >>> Neil >> >>> | Mitchell >> >>> | Sent: 18 March 2015 15:33 >> >>> | To: ghc-devs at haskell.org >> >>> | Subject: Shake fails test with GHC 7.10 RC3 >> >>> | >> >>> | Hi, >> >>> | >> >>> | Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch >> >>> the >> >>> | wrong exception in the wrong place. It's only hit by one of my >> >>> tests, >> >>> | and I've managed to isolate it to a fragment of code with no >> >>> | unsafePerformIO, that throws exceptions using error (so not in IO), >> >>> and >> >>> | operates in IO. Turning off the stack hack makes the bug go away, >> >>> but >> >>> | then so does -O0, marking one of the functions it calls NOINLINE, >> >>> or >> >>> | moving an INLINE function it calls to a different module, or adding >> >>> a >> >>> | putStrLn under a catch block - it's very sensitive to the exact >> >>> | conditions. This test and this exact code worked fine with GHC 7.10 >> >>> | RC2. >> >>> | >> >>> | I was wondering if there have been any state hack related changes >> >>> or >> >>> | other potentially dangerous optimisation changes since RC2? I'll >> >>> | continue to try reducing the bug, but it's somewhat difficult as >> >>> the >> >>> | larger system is quite big, and the code is very sensitive. >> >>> | >> >>> | Thanks, Neil >> >>> | _______________________________________________ >> >>> | ghc-devs mailing list >> >>> | ghc-devs at haskell.org >> >>> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> > On Thu, Mar 19, 2015 at 11:24 PM, Simon Peyton Jones >> > wrote: >> >> Thanks! I think a -ddump-simpl before and after the smallest change >> >> the makes the difference would be illuminating. >> >> >> >> Simon >> >> >> >> | -----Original Message----- >> >> | From: Neil Mitchell [mailto:ndmitchell at gmail.com] >> >> | Sent: 19 March 2015 23:07 >> >> | To: Simon Peyton Jones >> >> | Cc: ghc-devs at haskell.org >> >> | Subject: Re: Shake fails test with GHC 7.10 RC3 >> >> | >> >> | Herbert, thanks for the list of patches, nothing obvious there - my >> >> | best guess is it's something incredibly sensitive and it only needs >> >> | the tiniest change anywhere to make it happen. Things like moving >> >> | NOINLINE monomorphic-type definitions from one module to another are >> >> | causing the bug to appear/disappear, which isn't what I'd expect. >> >> | >> >> | Simon, changing from error to error in IO causes the bug to >> >> disappear, >> >> | but then so do most things. The error return type is type IO (), so I >> >> | suspect that forces it to be raised at the right place - but it's >> >> | certainly one of the possibilities for what is going wrong. Diffing >> >> | the Core is a great idea. >> >> | >> >> | I'll keep reducing and see what I get to. Given the sensitivity of >> >> the >> >> | bug, I'm sure a NOINLINE on an out-of-the-way function will make it >> >> go >> >> | away, so I can easily fix Shake itself - so I'm more tracking it down >> >> | from the point of GHC now. >> >> | >> >> | Thanks, Neil >> >> | >> >> | >> >> | On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones >> >> | wrote: >> >> | > I'm really sorry but I can't think of anything. Sounds horrible. >> >> | > >> >> | > If you throw exceptions using 'error' (not in IO), then you are of >> >> | course vulnerable to strictness changes. If the thing isn't actually >> >> | evaluated inside the catch block, you won't see the exception. But >> >> I'm >> >> | sure you've thought of that. >> >> | > >> >> | > I'd experiment with one of the smaller changes you describe, such >> >> as >> >> | adding a putStrLn, and comparing Core, before and after. Switching >> >> off - >> >> | O will make a huge difference, so hard to compare. Turning off the >> >> state >> >> | hack will have a more global effect. But the other changes sound >> >> more >> >> | pin-point and hence the differences will be smaller. >> >> | > >> >> | > Simon >> >> | > >> >> | > | -----Original Message----- >> >> | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf >> >> Of >> >> | Neil >> >> | > | Mitchell >> >> | > | Sent: 18 March 2015 15:33 >> >> | > | To: ghc-devs at haskell.org >> >> | > | Subject: Shake fails test with GHC 7.10 RC3 >> >> | > | >> >> | > | Hi, >> >> | > | >> >> | > | Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch >> >> the >> >> | > | wrong exception in the wrong place. It's only hit by one of my >> >> | tests, >> >> | > | and I've managed to isolate it to a fragment of code with no >> >> | > | unsafePerformIO, that throws exceptions using error (so not in >> >> IO), >> >> | and >> >> | > | operates in IO. Turning off the stack hack makes the bug go >> >> away, >> >> | but >> >> | > | then so does -O0, marking one of the functions it calls >> >> NOINLINE, or >> >> | > | moving an INLINE function it calls to a different module, or >> >> adding >> >> | a >> >> | > | putStrLn under a catch block - it's very sensitive to the exact >> >> | > | conditions. This test and this exact code worked fine with GHC >> >> 7.10 >> >> | > | RC2. >> >> | > | >> >> | > | I was wondering if there have been any state hack related >> >> changes or >> >> | > | other potentially dangerous optimisation changes since RC2? I'll >> >> | > | continue to try reducing the bug, but it's somewhat difficult as >> >> the >> >> | > | larger system is quite big, and the code is very sensitive. >> >> | > | >> >> | > | Thanks, Neil >> >> | > | _______________________________________________ >> >> | > | ghc-devs mailing list >> >> | > | ghc-devs at haskell.org >> >> | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > From simonpj at microsoft.com Fri Mar 20 17:19:09 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 20 Mar 2015 17:19:09 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> Neil Could you open a ticket for this, and attach the info to it? Lots of useful info in this thread, but may get lost. Re empty cases, see Note [Empty case alternatives] in CoreSyn. "A case expression can have empty alternatives if (and only if) the scrutinee is bound to raise an exception or diverge." So yes, case (\_ -> ...) of {} is definitely wrong. Could someone extend Core Lint to check for this? The function to call is exprIsHNF: if we have case e of {} then exprIsHNF should never return True. That is a powerful clue, and adding it to Lint will nail the moment at which it first happens. Good progress. (I'd do it myself but I'm struggling with backlog, and only have 3 days left before going on holiday for 10 days.) Simon | -----Original Message----- | From: Neil Mitchell [mailto:ndmitchell at gmail.com] | Sent: 20 March 2015 16:57 | To: Carter Schonwald | Cc: Simon Peyton Jones; ghc-devs at haskell.org | Subject: Re: Shake fails test with GHC 7.10 RC3 | | > do you use a deepSeq when catching errors from a pure computation? Or | > is it in a context where you know the value should be treated strictly? | | The computation is essentially (error "here" :: IO ()), so the IO monadic | binding should force the exception. In the full source code to Shake it's | actually in ContT/ReaderT/IO, but a modification to insert liftIO (if | done in exactly the right way) gives the same result. That simplified | code is at http://community.haskell.org/~ndm/temp/src.zip | (to run, compile with the logic from | https://github.com/ndmitchell/shake/blob/master/.ghci :benchmark, then | run "main oracle test"). | | > https://github.com/ndmitchell/shake/issues/216 seems to be the ticket | > in question | | That is the ticket. The test that is failing is the "oracle" | (Test.Oracle) test suite, and you can see full logs of both success and | failure at Travis: | https://travis-ci.org/ndmitchell/shake/builds/54748475 . Note that it | succeeds on GHC 7.2, 7.4, 7.6 and 7.8, but fails on GHC 7.10 RC3 and GHC | Head. | | Alas, the actual error is coming from deep in the middle of Shake, | specifically this line: | https://github.com/ndmitchell/shake/blob/master/src/Development/Shake/Cor | e.hs#L329 | | Thinking some more on what I saw, my best guess is that: | | case (\_ -> ...) of {} | | Is a fatal error in GHC. I am guessing that {} means there are no | alternatives because GHC managed to show that the scrutinee throws an | exception. In addition, evaluating a literal lambda to WHNF will not | throw an exception, so you have a contradiction. | | Making increasingly wild speculative guesses, I could imagine this code | compiling to CMM that just fell off the end of a basic block, arriving at | the next statement of supposedly unconnected code. That actually matches | what I'm seeing - I have the exception, using print I can see I am at the | line before, and that I never get to the line after, but pop up somewhere | nearby and continue onwards seemingly ignoring the exception ever | happened. | | If someone can confirm the above pattern of Core is always illegal and | always indicates a GHC error then I can reduce the test case driven | purely by the Core, which would be far easier - at the moment Shake | passes through these routines several times to set things up, making it | harder to simplify them too much without changing the preparation steps. | | Thanks, Neil | | | >> | >> On Fri, Mar 20, 2015 at 12:01 AM, Neil Mitchell | >> | >> wrote: | >> > More delving later, it seems the incorrect optimized version has | >> > been turned into: | >> > | >> > case (\ _ [Occ=Dead, OS=OneShot] -> error "here") of _ [Occ=Dead] | >> > {} | >> > | >> > While the working one has been turned into: | >> > | >> > errorFunc argument realWorldToken | >> > | >> > where errorFunc _ = error "here" | >> > | >> > I'm not familiar with case ... of _ {} - what does it mean when | >> > there are no alternatives to the case? And why isn't case on a | >> > literal lambda optimised out? Is it the OneShot annotation (perhaps | >> > coming from the state hack?) | >> > | >> > The full trace is at | >> > https://gist.github.com/ndmitchell/b222e04eb0c3a397c758. I've | >> > uploaded bad (optimises the error out) and good (works as expected) | >> > versions of the Core. The summary files are the subexpression that | >> > changed making a single difference (moving a monomorphic NOINLINE | >> > function from one module to another) plus the handful of functions | >> > they depend on, which I've reformatted/inlined/simplified to produce | the expressions above. | >> > The full versions are the entire -ddump-simpl output from about | >> > halfway through the build, starting when the differences occur - | >> > let me know if you need further back. The dodgy function is "exec". | >> > | >> > Thanks, Neil | >> > | >> > On Thu, Mar 19, 2015 at 11:07 PM, Neil Mitchell | >> > | >> > wrote: | >> >> Herbert, thanks for the list of patches, nothing obvious there - | >> >> my best guess is it's something incredibly sensitive and it only | >> >> needs the tiniest change anywhere to make it happen. Things like | >> >> moving NOINLINE monomorphic-type definitions from one module to | >> >> another are causing the bug to appear/disappear, which isn't what | I'd expect. | >> >> | >> >> Simon, changing from error to error in IO causes the bug to | >> >> disappear, but then so do most things. The error return type is | >> >> type IO (), so I suspect that forces it to be raised at the right | >> >> place - but it's certainly one of the possibilities for what is | >> >> going wrong. Diffing the Core is a great idea. | >> >> | >> >> I'll keep reducing and see what I get to. Given the sensitivity of | >> >> the bug, I'm sure a NOINLINE on an out-of-the-way function will | >> >> make it go away, so I can easily fix Shake itself - so I'm more | >> >> tracking it down from the point of GHC now. | >> >> | >> >> Thanks, Neil | >> >> | >> >> | >> >> On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones | >> >> wrote: | >> >>> I'm really sorry but I can't think of anything. Sounds horrible. | >> >>> | >> >>> If you throw exceptions using 'error' (not in IO), then you are | >> >>> of course vulnerable to strictness changes. If the thing isn't | >> >>> actually evaluated inside the catch block, you won't see the | >> >>> exception. But I'm sure you've thought of that. | >> >>> | >> >>> I'd experiment with one of the smaller changes you describe, such | >> >>> as adding a putStrLn, and comparing Core, before and after. | >> >>> Switching off -O will make a huge difference, so hard to compare. | >> >>> Turning off the state hack will have a more global effect. But | >> >>> the other changes sound more pin-point and hence the differences | will be smaller. | >> >>> | >> >>> Simon | >> >>> | >> >>> | -----Original Message----- | >> >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf | >> >>> | Of | >> >>> Neil | >> >>> | Mitchell | >> >>> | Sent: 18 March 2015 15:33 | >> >>> | To: ghc-devs at haskell.org | >> >>> | Subject: Shake fails test with GHC 7.10 RC3 | >> >>> | | >> >>> | Hi, | >> >>> | | >> >>> | Testing GHC 7.10 RC3 I've found a bug where Shake seems to | >> >>> | catch | >> >>> the | >> >>> | wrong exception in the wrong place. It's only hit by one of my | >> >>> tests, | >> >>> | and I've managed to isolate it to a fragment of code with no | >> >>> | unsafePerformIO, that throws exceptions using error (so not in | >> >>> | IO), | >> >>> and | >> >>> | operates in IO. Turning off the stack hack makes the bug go | >> >>> | away, | >> >>> but | >> >>> | then so does -O0, marking one of the functions it calls | >> >>> | NOINLINE, | >> >>> or | >> >>> | moving an INLINE function it calls to a different module, or | >> >>> | adding | >> >>> a | >> >>> | putStrLn under a catch block - it's very sensitive to the | >> >>> | exact conditions. This test and this exact code worked fine | >> >>> | with GHC 7.10 RC2. | >> >>> | | >> >>> | I was wondering if there have been any state hack related | >> >>> | changes | >> >>> or | >> >>> | other potentially dangerous optimisation changes since RC2? | >> >>> | I'll continue to try reducing the bug, but it's somewhat | >> >>> | difficult as | >> >>> the | >> >>> | larger system is quite big, and the code is very sensitive. | >> >>> | | >> >>> | Thanks, Neil | >> >>> | _______________________________________________ | >> >>> | ghc-devs mailing list | >> >>> | ghc-devs at haskell.org | >> >>> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >> > | >> > On Thu, Mar 19, 2015 at 11:24 PM, Simon Peyton Jones | >> > wrote: | >> >> Thanks! I think a -ddump-simpl before and after the smallest | >> >> change the makes the difference would be illuminating. | >> >> | >> >> Simon | >> >> | >> >> | -----Original Message----- | >> >> | From: Neil Mitchell [mailto:ndmitchell at gmail.com] | >> >> | Sent: 19 March 2015 23:07 | >> >> | To: Simon Peyton Jones | >> >> | Cc: ghc-devs at haskell.org | >> >> | Subject: Re: Shake fails test with GHC 7.10 RC3 | >> >> | | >> >> | Herbert, thanks for the list of patches, nothing obvious there - | >> >> | my best guess is it's something incredibly sensitive and it only | >> >> | needs the tiniest change anywhere to make it happen. Things like | >> >> | moving NOINLINE monomorphic-type definitions from one module to | >> >> | another are causing the bug to appear/disappear, which isn't what | I'd expect. | >> >> | | >> >> | Simon, changing from error to error in IO causes the bug to | >> >> disappear, | >> >> | but then so do most things. The error return type is type IO (), | >> >> | so I suspect that forces it to be raised at the right place - | >> >> | but it's certainly one of the possibilities for what is going | >> >> | wrong. Diffing the Core is a great idea. | >> >> | | >> >> | I'll keep reducing and see what I get to. Given the sensitivity | >> >> | of | >> >> the | >> >> | bug, I'm sure a NOINLINE on an out-of-the-way function will make | >> >> | it | >> >> go | >> >> | away, so I can easily fix Shake itself - so I'm more tracking it | >> >> | down from the point of GHC now. | >> >> | | >> >> | Thanks, Neil | >> >> | | >> >> | | >> >> | On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones | >> >> | wrote: | >> >> | > I'm really sorry but I can't think of anything. Sounds | horrible. | >> >> | > | >> >> | > If you throw exceptions using 'error' (not in IO), then you | >> >> | > are of | >> >> | course vulnerable to strictness changes. If the thing isn't | >> >> | actually evaluated inside the catch block, you won't see the | >> >> | exception. But | >> >> I'm | >> >> | sure you've thought of that. | >> >> | > | >> >> | > I'd experiment with one of the smaller changes you describe, | >> >> | > such | >> >> as | >> >> | adding a putStrLn, and comparing Core, before and after. | >> >> | Switching | >> >> off - | >> >> | O will make a huge difference, so hard to compare. Turning off | >> >> | the | >> >> state | >> >> | hack will have a more global effect. But the other changes | >> >> | sound | >> >> more | >> >> | pin-point and hence the differences will be smaller. | >> >> | > | >> >> | > Simon | >> >> | > | >> >> | > | -----Original Message----- | >> >> | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On | >> >> | > | Behalf | >> >> Of | >> >> | Neil | >> >> | > | Mitchell | >> >> | > | Sent: 18 March 2015 15:33 | >> >> | > | To: ghc-devs at haskell.org | >> >> | > | Subject: Shake fails test with GHC 7.10 RC3 | >> >> | > | | >> >> | > | Hi, | >> >> | > | | >> >> | > | Testing GHC 7.10 RC3 I've found a bug where Shake seems to | >> >> | > | catch | >> >> the | >> >> | > | wrong exception in the wrong place. It's only hit by one of | >> >> | > | my | >> >> | tests, | >> >> | > | and I've managed to isolate it to a fragment of code with | >> >> | > | no unsafePerformIO, that throws exceptions using error (so | >> >> | > | not in | >> >> IO), | >> >> | and | >> >> | > | operates in IO. Turning off the stack hack makes the bug go | >> >> away, | >> >> | but | >> >> | > | then so does -O0, marking one of the functions it calls | >> >> NOINLINE, or | >> >> | > | moving an INLINE function it calls to a different module, | >> >> | > | or | >> >> adding | >> >> | a | >> >> | > | putStrLn under a catch block - it's very sensitive to the | >> >> | > | exact conditions. This test and this exact code worked fine | >> >> | > | with GHC | >> >> 7.10 | >> >> | > | RC2. | >> >> | > | | >> >> | > | I was wondering if there have been any state hack related | >> >> changes or | >> >> | > | other potentially dangerous optimisation changes since RC2? | >> >> | > | I'll continue to try reducing the bug, but it's somewhat | >> >> | > | difficult as | >> >> the | >> >> | > | larger system is quite big, and the code is very sensitive. | >> >> | > | | >> >> | > | Thanks, Neil | >> >> | > | _______________________________________________ | >> >> | > | ghc-devs mailing list | >> >> | > | ghc-devs at haskell.org | >> >> | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs at haskell.org | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | > From simonpj at microsoft.com Fri Mar 20 23:16:03 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 20 Mar 2015 23:16:03 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> <87k2yb7ep0.fsf@gmail.com> Message-ID: <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> | FWIW, I've been noodling over this today since I saw this email, and | sitting down, I think this may be a blocker worth holding up for after | thinking about it. At least, it is until we can quantify how much it | might bite (can we find a workaround? How often does it hit in | practice?) I'm reluctant to delay 7.10 further. I'm sure there are other bugs, and we'll want 7.10.2 before too long. But we won't find them until we push it out. The danger is that we stay in about-to-release mode for ages, and that holds everyone up. We've had three release candidates out over a period of months and Neil seems to be the only one who has tripped over it. I think it'd be better to push it out. (We planned to do so today!) What do others think? Simon | -----Original Message----- | From: mad.one at gmail.com [mailto:mad.one at gmail.com] On Behalf Of Austin | Seipp | Sent: 20 March 2015 22:48 | To: Herbert Valerio Riedel | Cc: Simon Peyton Jones; Austin Seipp | Subject: Re: Shake fails test with GHC 7.10 RC3 | | FWIW, I've been noodling over this today since I saw this email, and | sitting down, I think this may be a blocker worth holding up for after | thinking about it. At least, it is until we can quantify how much it | might bite (can we find a workaround? How often does it hit in | practice?) | | I'm testing Iavor's patches that he wanted in at the last minute (I'm | really hesitant for that, since we could break something), so we've | got some time, but I'd like to at least narrow this down a bit more. | | On Fri, Mar 20, 2015 at 12:37 PM, Herbert Valerio Riedel | wrote: | > | > ...does this in any way affect today's GHC 7.10.1 release? I.e. is this | > blocking the release? | > | > | > On 2015-03-20 at 18:19:09 +0100, Simon Peyton Jones wrote: | >> Neil | >> | >> Could you open a ticket for this, and attach the info to it? Lots of | useful info in this thread, but may get lost. | >> | >> Re empty cases, see Note [Empty case alternatives] in CoreSyn. "A | >> case expression can have empty alternatives if (and only if) the | >> scrutinee is bound to raise an exception or diverge." | >> | >> So yes, case (\_ -> ...) of {} is definitely wrong. Could someone | >> extend Core Lint to check for this? The function to call is | >> exprIsHNF: if we have | >> case e of {} | >> then exprIsHNF should never return True. | >> | >> That is a powerful clue, and adding it to Lint will nail the moment at | which it first happens. Good progress. | >> | >> (I'd do it myself but I'm struggling with backlog, and only have 3 | days left before going on holiday for 10 days.) | >> | >> Simon | >> | >> | -----Original Message----- | >> | From: Neil Mitchell [mailto:ndmitchell at gmail.com] | >> | Sent: 20 March 2015 16:57 | >> | To: Carter Schonwald | >> | Cc: Simon Peyton Jones; ghc-devs at haskell.org | >> | Subject: Re: Shake fails test with GHC 7.10 RC3 | >> | | >> | > do you use a deepSeq when catching errors from a pure | computation? Or | >> | > is it in a context where you know the value should be treated | strictly? | >> | | >> | The computation is essentially (error "here" :: IO ()), so the IO | monadic | >> | binding should force the exception. In the full source code to | Shake it's | >> | actually in ContT/ReaderT/IO, but a modification to insert liftIO | (if | >> | done in exactly the right way) gives the same result. That | simplified | >> | code is at http://community.haskell.org/~ndm/temp/src.zip | >> | (to run, compile with the logic from | >> | https://github.com/ndmitchell/shake/blob/master/.ghci :benchmark, | then | >> | run "main oracle test"). | >> | | >> | > https://github.com/ndmitchell/shake/issues/216 seems to be the | ticket | >> | > in question | >> | | >> | That is the ticket. The test that is failing is the "oracle" | >> | (Test.Oracle) test suite, and you can see full logs of both success | and | >> | failure at Travis: | >> | https://travis-ci.org/ndmitchell/shake/builds/54748475 . Note that | it | >> | succeeds on GHC 7.2, 7.4, 7.6 and 7.8, but fails on GHC 7.10 RC3 | and GHC | >> | Head. | >> | | >> | Alas, the actual error is coming from deep in the middle of Shake, | >> | specifically this line: | >> | | https://github.com/ndmitchell/shake/blob/master/src/Development/Shake/Cor | >> | e.hs#L329 | >> | | >> | Thinking some more on what I saw, my best guess is that: | >> | | >> | case (\_ -> ...) of {} | >> | | >> | Is a fatal error in GHC. I am guessing that {} means there are no | >> | alternatives because GHC managed to show that the scrutinee throws | an | >> | exception. In addition, evaluating a literal lambda to WHNF will | not | >> | throw an exception, so you have a contradiction. | >> | | >> | Making increasingly wild speculative guesses, I could imagine this | code | >> | compiling to CMM that just fell off the end of a basic block, | arriving at | >> | the next statement of supposedly unconnected code. That actually | matches | >> | what I'm seeing - I have the exception, using print I can see I am | at the | >> | line before, and that I never get to the line after, but pop up | somewhere | >> | nearby and continue onwards seemingly ignoring the exception ever | >> | happened. | >> | | >> | If someone can confirm the above pattern of Core is always illegal | and | >> | always indicates a GHC error then I can reduce the test case driven | >> | purely by the Core, which would be far easier - at the moment Shake | >> | passes through these routines several times to set things up, | making it | >> | harder to simplify them too much without changing the preparation | steps. | >> | | >> | Thanks, Neil | >> | | >> | | >> | >> | >> | >> On Fri, Mar 20, 2015 at 12:01 AM, Neil Mitchell | >> | >> | >> | >> wrote: | >> | >> > More delving later, it seems the incorrect optimized version | has | >> | >> > been turned into: | >> | >> > | >> | >> > case (\ _ [Occ=Dead, OS=OneShot] -> error "here") of _ | [Occ=Dead] | >> | >> > {} | >> | >> > | >> | >> > While the working one has been turned into: | >> | >> > | >> | >> > errorFunc argument realWorldToken | >> | >> > | >> | >> > where errorFunc _ = error "here" | >> | >> > | >> | >> > I'm not familiar with case ... of _ {} - what does it mean | when | >> | >> > there are no alternatives to the case? And why isn't case on a | >> | >> > literal lambda optimised out? Is it the OneShot annotation | (perhaps | >> | >> > coming from the state hack?) | >> | >> > | >> | >> > The full trace is at | >> | >> > https://gist.github.com/ndmitchell/b222e04eb0c3a397c758. I've | >> | >> > uploaded bad (optimises the error out) and good (works as | expected) | >> | >> > versions of the Core. The summary files are the subexpression | that | >> | >> > changed making a single difference (moving a monomorphic | NOINLINE | >> | >> > function from one module to another) plus the handful of | functions | >> | >> > they depend on, which I've reformatted/inlined/simplified to | produce | >> | the expressions above. | >> | >> > The full versions are the entire -ddump-simpl output from | about | >> | >> > halfway through the build, starting when the differences occur | - | >> | >> > let me know if you need further back. The dodgy function is | "exec". | >> | >> > | >> | >> > Thanks, Neil | >> | >> > | >> | >> > On Thu, Mar 19, 2015 at 11:07 PM, Neil Mitchell | >> | >> > | >> | >> > wrote: | >> | >> >> Herbert, thanks for the list of patches, nothing obvious | there - | >> | >> >> my best guess is it's something incredibly sensitive and it | only | >> | >> >> needs the tiniest change anywhere to make it happen. Things | like | >> | >> >> moving NOINLINE monomorphic-type definitions from one module | to | >> | >> >> another are causing the bug to appear/disappear, which isn't | what | >> | I'd expect. | >> | >> >> | >> | >> >> Simon, changing from error to error in IO causes the bug to | >> | >> >> disappear, but then so do most things. The error return type | is | >> | >> >> type IO (), so I suspect that forces it to be raised at the | right | >> | >> >> place - but it's certainly one of the possibilities for what | is | >> | >> >> going wrong. Diffing the Core is a great idea. | >> | >> >> | >> | >> >> I'll keep reducing and see what I get to. Given the | sensitivity of | >> | >> >> the bug, I'm sure a NOINLINE on an out-of-the-way function | will | >> | >> >> make it go away, so I can easily fix Shake itself - so I'm | more | >> | >> >> tracking it down from the point of GHC now. | >> | >> >> | >> | >> >> Thanks, Neil | >> | >> >> | >> | >> >> | >> | >> >> On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones | >> | >> >> wrote: | >> | >> >>> I'm really sorry but I can't think of anything. Sounds | horrible. | >> | >> >>> | >> | >> >>> If you throw exceptions using 'error' (not in IO), then you | are | >> | >> >>> of course vulnerable to strictness changes. If the thing | isn't | >> | >> >>> actually evaluated inside the catch block, you won't see the | >> | >> >>> exception. But I'm sure you've thought of that. | >> | >> >>> | >> | >> >>> I'd experiment with one of the smaller changes you describe, | such | >> | >> >>> as adding a putStrLn, and comparing Core, before and after. | >> | >> >>> Switching off -O will make a huge difference, so hard to | compare. | >> | >> >>> Turning off the state hack will have a more global effect. | But | >> | >> >>> the other changes sound more pin-point and hence the | differences | >> | will be smaller. | >> | >> >>> | >> | >> >>> Simon | >> | >> >>> | >> | >> >>> | -----Original Message----- | >> | >> >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On | Behalf | >> | >> >>> | Of | >> | >> >>> Neil | >> | >> >>> | Mitchell | >> | >> >>> | Sent: 18 March 2015 15:33 | >> | >> >>> | To: ghc-devs at haskell.org | >> | >> >>> | Subject: Shake fails test with GHC 7.10 RC3 | >> | >> >>> | | >> | >> >>> | Hi, | >> | >> >>> | | >> | >> >>> | Testing GHC 7.10 RC3 I've found a bug where Shake seems | to | >> | >> >>> | catch | >> | >> >>> the | >> | >> >>> | wrong exception in the wrong place. It's only hit by one | of my | >> | >> >>> tests, | >> | >> >>> | and I've managed to isolate it to a fragment of code with | no | >> | >> >>> | unsafePerformIO, that throws exceptions using error (so | not in | >> | >> >>> | IO), | >> | >> >>> and | >> | >> >>> | operates in IO. Turning off the stack hack makes the bug | go | >> | >> >>> | away, | >> | >> >>> but | >> | >> >>> | then so does -O0, marking one of the functions it calls | >> | >> >>> | NOINLINE, | >> | >> >>> or | >> | >> >>> | moving an INLINE function it calls to a different module, | or | >> | >> >>> | adding | >> | >> >>> a | >> | >> >>> | putStrLn under a catch block - it's very sensitive to the | >> | >> >>> | exact conditions. This test and this exact code worked | fine | >> | >> >>> | with GHC 7.10 RC2. | >> | >> >>> | | >> | >> >>> | I was wondering if there have been any state hack related | >> | >> >>> | changes | >> | >> >>> or | >> | >> >>> | other potentially dangerous optimisation changes since | RC2? | >> | >> >>> | I'll continue to try reducing the bug, but it's somewhat | >> | >> >>> | difficult as | >> | >> >>> the | >> | >> >>> | larger system is quite big, and the code is very | sensitive. | >> | >> >>> | | >> | >> >>> | Thanks, Neil | >> | >> >>> | _______________________________________________ | >> | >> >>> | ghc-devs mailing list | >> | >> >>> | ghc-devs at haskell.org | >> | >> >>> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >> | >> > | >> | >> > On Thu, Mar 19, 2015 at 11:24 PM, Simon Peyton Jones | >> | >> > wrote: | >> | >> >> Thanks! I think a -ddump-simpl before and after the smallest | >> | >> >> change the makes the difference would be illuminating. | >> | >> >> | >> | >> >> Simon | >> | >> >> | >> | >> >> | -----Original Message----- | >> | >> >> | From: Neil Mitchell [mailto:ndmitchell at gmail.com] | >> | >> >> | Sent: 19 March 2015 23:07 | >> | >> >> | To: Simon Peyton Jones | >> | >> >> | Cc: ghc-devs at haskell.org | >> | >> >> | Subject: Re: Shake fails test with GHC 7.10 RC3 | >> | >> >> | | >> | >> >> | Herbert, thanks for the list of patches, nothing obvious | there - | >> | >> >> | my best guess is it's something incredibly sensitive and it | only | >> | >> >> | needs the tiniest change anywhere to make it happen. Things | like | >> | >> >> | moving NOINLINE monomorphic-type definitions from one | module to | >> | >> >> | another are causing the bug to appear/disappear, which | isn't what | >> | I'd expect. | >> | >> >> | | >> | >> >> | Simon, changing from error to error in IO causes the bug to | >> | >> >> disappear, | >> | >> >> | but then so do most things. The error return type is type | IO (), | >> | >> >> | so I suspect that forces it to be raised at the right place | - | >> | >> >> | but it's certainly one of the possibilities for what is | going | >> | >> >> | wrong. Diffing the Core is a great idea. | >> | >> >> | | >> | >> >> | I'll keep reducing and see what I get to. Given the | sensitivity | >> | >> >> | of | >> | >> >> the | >> | >> >> | bug, I'm sure a NOINLINE on an out-of-the-way function will | make | >> | >> >> | it | >> | >> >> go | >> | >> >> | away, so I can easily fix Shake itself - so I'm more | tracking it | >> | >> >> | down from the point of GHC now. | >> | >> >> | | >> | >> >> | Thanks, Neil | >> | >> >> | | >> | >> >> | | >> | >> >> | On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones | >> | >> >> | wrote: | >> | >> >> | > I'm really sorry but I can't think of anything. Sounds | >> | horrible. | >> | >> >> | > | >> | >> >> | > If you throw exceptions using 'error' (not in IO), then | you | >> | >> >> | > are of | >> | >> >> | course vulnerable to strictness changes. If the thing | isn't | >> | >> >> | actually evaluated inside the catch block, you won't see | the | >> | >> >> | exception. But | >> | >> >> I'm | >> | >> >> | sure you've thought of that. | >> | >> >> | > | >> | >> >> | > I'd experiment with one of the smaller changes you | describe, | >> | >> >> | > such | >> | >> >> as | >> | >> >> | adding a putStrLn, and comparing Core, before and after. | >> | >> >> | Switching | >> | >> >> off - | >> | >> >> | O will make a huge difference, so hard to compare. Turning | off | >> | >> >> | the | >> | >> >> state | >> | >> >> | hack will have a more global effect. But the other changes | >> | >> >> | sound | >> | >> >> more | >> | >> >> | pin-point and hence the differences will be smaller. | >> | >> >> | > | >> | >> >> | > Simon | >> | >> >> | > | >> | >> >> | > | -----Original Message----- | >> | >> >> | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] | On | >> | >> >> | > | Behalf | >> | >> >> Of | >> | >> >> | Neil | >> | >> >> | > | Mitchell | >> | >> >> | > | Sent: 18 March 2015 15:33 | >> | >> >> | > | To: ghc-devs at haskell.org | >> | >> >> | > | Subject: Shake fails test with GHC 7.10 RC3 | >> | >> >> | > | | >> | >> >> | > | Hi, | >> | >> >> | > | | >> | >> >> | > | Testing GHC 7.10 RC3 I've found a bug where Shake | seems to | >> | >> >> | > | catch | >> | >> >> the | >> | >> >> | > | wrong exception in the wrong place. It's only hit by | one of | >> | >> >> | > | my | >> | >> >> | tests, | >> | >> >> | > | and I've managed to isolate it to a fragment of code | with | >> | >> >> | > | no unsafePerformIO, that throws exceptions using error | (so | >> | >> >> | > | not in | >> | >> >> IO), | >> | >> >> | and | >> | >> >> | > | operates in IO. Turning off the stack hack makes the | bug go | >> | >> >> away, | >> | >> >> | but | >> | >> >> | > | then so does -O0, marking one of the functions it | calls | >> | >> >> NOINLINE, or | >> | >> >> | > | moving an INLINE function it calls to a different | module, | >> | >> >> | > | or | >> | >> >> adding | >> | >> >> | a | >> | >> >> | > | putStrLn under a catch block - it's very sensitive to | the | >> | >> >> | > | exact conditions. This test and this exact code worked | fine | >> | >> >> | > | with GHC | >> | >> >> 7.10 | >> | >> >> | > | RC2. | >> | >> >> | > | | >> | >> >> | > | I was wondering if there have been any state hack | related | >> | >> >> changes or | >> | >> >> | > | other potentially dangerous optimisation changes since | RC2? | >> | >> >> | > | I'll continue to try reducing the bug, but it's | somewhat | >> | >> >> | > | difficult as | >> | >> >> the | >> | >> >> | > | larger system is quite big, and the code is very | sensitive. | >> | >> >> | > | | >> | >> >> | > | Thanks, Neil | >> | >> >> | > | _______________________________________________ | >> | >> >> | > | ghc-devs mailing list | >> | >> >> | > | ghc-devs at haskell.org | >> | >> >> | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc- | devs | >> | >> _______________________________________________ | >> | >> ghc-devs mailing list | >> | >> ghc-devs at haskell.org | >> | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >> | > | >> | > | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs at haskell.org | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | > -- | > "Elegance is not optional" -- Richard O'Keefe | > | | | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Fri Mar 20 23:20:44 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 20 Mar 2015 23:20:44 +0000 Subject: GHC Trac Message-ID: Is it just me, or is GHC's Trac super-slow (again)? Actually it's not just slow but offline from where I am. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Fri Mar 20 23:21:19 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Fri, 20 Mar 2015 18:21:19 -0500 Subject: GHC Trac In-Reply-To: References: Message-ID: Yes, has been for a good chunk of the day for myself and others. On Fri, Mar 20, 2015 at 6:20 PM, Simon Peyton Jones wrote: > Is it just me, or is GHC?s Trac super-slow (again)? Actually it?s not > just slow but offline from where I am. > > Simon > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Fri Mar 20 23:22:58 2015 From: austin at well-typed.com (Austin Seipp) Date: Fri, 20 Mar 2015 18:22:58 -0500 Subject: GHC Trac In-Reply-To: References: Message-ID: Should be back online now. I think we're getting hit by bots, and we can't handle the load from some of them as they incur expensive CPU operations on Trac. We really need to fix this... On Fri, Mar 20, 2015 at 6:21 PM, Christopher Allen wrote: > Yes, has been for a good chunk of the day for myself and others. > > On Fri, Mar 20, 2015 at 6:20 PM, Simon Peyton Jones > wrote: >> >> Is it just me, or is GHC?s Trac super-slow (again)? Actually it?s not >> just slow but offline from where I am. >> >> Simon >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Fri Mar 20 23:24:26 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 20 Mar 2015 23:24:26 +0000 Subject: [GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found In-Reply-To: <062.dea08f6cf6e3294f5cd2394e97819edb@haskell.org> References: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> <062.dea08f6cf6e3294f5cd2394e97819edb@haskell.org> Message-ID: <0e6ab64fc896415a9795b40c5fd072ab@DB4PR30MB030.064d.mgd.msft.net> Replying by email since Trac is down. I nailed this one. This diff fixes it. It was a missing 'runFlatten'. However I propose not to commit a fix, because Richard's D653 refactors all that code and, I'm 99% certain, fixes the bug in a better way. I would like D653 to land though. Richard are you doing that, or are you waiting for Austin to? Simon Modified compiler/typecheck/TcInteract.hs diff --git a/compiler/typecheck/TcInteract.hs b/compiler/typecheck/TcInteract.hs index e83709c..4d4b31c 100644 --- a/compiler/typecheck/TcInteract.hs +++ b/compiler/typecheck/TcInteract.hs @@ -1420,6 +1420,7 @@ shortCutReduction old_ev fsk ax_co fam_tc tc_args | otherwise = ASSERT( not (isDerived old_ev) ) -- Caller ensures this ASSERT( ctEvEqRel old_ev == NomEq ) + runFlatten $ do { (xis, cos) <- flattenManyNom old_ev tc_args -- ax_co :: F args ~ G tc_args -- cos :: xis ~ tc_args | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of | GHC | Sent: 14 March 2015 03:07 | Cc: ghc-tickets at haskell.org | Subject: Re: [GHC] #10158: Panic compiling singletons: StgCmmEnv: | variable not found | | #10158: Panic compiling singletons: StgCmmEnv: variable not found | -------------------------------------+----------------------------------- | -- | Reporter: trommler | Owner: | Type: bug | Status: new | Priority: highest | Milestone: | Component: Compiler | Version: 7.11 | (CodeGen) | Keywords: | Resolution: | Architecture: | Operating System: Unknown/Multiple | Unknown/Multiple | Type of failure: None/Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Revisions: | -------------------------------------+----------------------------------- | -- | Changes (by goldfire): | | * priority: normal => highest | | | Comment: | | Yikes! I hope I'm not overstating the importance of my library to GHC, | but | this sounds serious. | | Is this reproducible on the 7.10 branch? If so, please set the milestone | to 7.10.1. | | -- | Ticket URL: | GHC | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets at haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets From eir at cis.upenn.edu Fri Mar 20 23:26:37 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 20 Mar 2015 19:26:37 -0400 Subject: [GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found In-Reply-To: <0e6ab64fc896415a9795b40c5fd072ab@DB4PR30MB030.064d.mgd.msft.net> References: <047.1ab70824b0a85d6eb1627333e676c77f@haskell.org> <062.dea08f6cf6e3294f5cd2394e97819edb@haskell.org> <0e6ab64fc896415a9795b40c5fd072ab@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Will do soon (Monday). It will take some merging, etc., but it shouldn't be a problem. Richard On Mar 20, 2015, at 7:24 PM, Simon Peyton Jones wrote: > Replying by email since Trac is down. > > I nailed this one. This diff fixes it. It was a missing 'runFlatten'. However I propose not to commit a fix, because Richard's D653 refactors all that code and, I'm 99% certain, fixes the bug in a better way. > > I would like D653 to land though. Richard are you doing that, or are you waiting for Austin to? > > Simon > > Modified compiler/typecheck/TcInteract.hs > diff --git a/compiler/typecheck/TcInteract.hs b/compiler/typecheck/TcInteract.hs > index e83709c..4d4b31c 100644 > --- a/compiler/typecheck/TcInteract.hs > +++ b/compiler/typecheck/TcInteract.hs > @@ -1420,6 +1420,7 @@ shortCutReduction old_ev fsk ax_co fam_tc tc_args > | otherwise > = ASSERT( not (isDerived old_ev) ) -- Caller ensures this > ASSERT( ctEvEqRel old_ev == NomEq ) > + runFlatten $ > do { (xis, cos) <- flattenManyNom old_ev tc_args > -- ax_co :: F args ~ G tc_args > -- cos :: xis ~ tc_args > > | -----Original Message----- > | From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of > | GHC > | Sent: 14 March 2015 03:07 > | Cc: ghc-tickets at haskell.org > | Subject: Re: [GHC] #10158: Panic compiling singletons: StgCmmEnv: > | variable not found > | > | #10158: Panic compiling singletons: StgCmmEnv: variable not found > | -------------------------------------+----------------------------------- > | -- > | Reporter: trommler | Owner: > | Type: bug | Status: new > | Priority: highest | Milestone: > | Component: Compiler | Version: 7.11 > | (CodeGen) | Keywords: > | Resolution: | Architecture: > | Operating System: Unknown/Multiple | Unknown/Multiple > | Type of failure: None/Unknown | Test Case: > | Blocked By: | Blocking: > | Related Tickets: | Differential Revisions: > | -------------------------------------+----------------------------------- > | -- > | Changes (by goldfire): > | > | * priority: normal => highest > | > | > | Comment: > | > | Yikes! I hope I'm not overstating the importance of my library to GHC, > | but > | this sounds serious. > | > | Is this reproducible on the 7.10 branch? If so, please set the milestone > | to 7.10.1. > | > | -- > | Ticket URL: > | GHC > | The Glasgow Haskell Compiler > | _______________________________________________ > | ghc-tickets mailing list > | ghc-tickets at haskell.org > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets > From ndmitchell at gmail.com Sat Mar 21 06:56:32 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat, 21 Mar 2015 06:56:32 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> <87k2yb7ep0.fsf@gmail.com> <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I'll raise a bug with all the details when I next get to a computer, probably tonight. A lint extension would be great for tracking this down. I appreciate that there are good reasons for pushing ahead with a release, but there are three reasons that give me a little hesitation. 1) It may well be that this bug has been around for a while, and the trigger conditions are exceptionally difficult to hit, and going ahead seems fine. Or it's a regression introduced recently and Shake is just the tip of the iceberg. I don't think there is any way to tell yet. 2) The failure mode seems to be that programs just do the wrong thing, seemingly an unexpected jump to somewhere else. That can often be incredibly hard to spot - I have one test that catches it, but Shake has more tests than implementation - other programs may suffer and not realise. If the error mode really is "should have thrown an exception but continues somewhere else instead" there is even potential for that to be a security hole. 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The fact no one else hit this with RC2 might just be because its a very recent regression. Thanks, Neil On Friday, 20 March 2015, Simon Peyton Jones wrote: > | FWIW, I've been noodling over this today since I saw this email, and > | sitting down, I think this may be a blocker worth holding up for after > | thinking about it. At least, it is until we can quantify how much it > | might bite (can we find a workaround? How often does it hit in > | practice?) > > I'm reluctant to delay 7.10 further. I'm sure there are other bugs, and > we'll want 7.10.2 before too long. But we won't find them until we push > it out. The danger is that we stay in about-to-release mode for ages, and > that holds everyone up. We've had three release candidates out over a > period of months and Neil seems to be the only one who has tripped over it. > > I think it'd be better to push it out. (We planned to do so today!) What > do others think? > > Simon > > | -----Original Message----- > | From: mad.one at gmail.com [mailto:mad.one at gmail.com] On Behalf Of Austin > | Seipp > | Sent: 20 March 2015 22:48 > | To: Herbert Valerio Riedel > | Cc: Simon Peyton Jones; Austin Seipp > | Subject: Re: Shake fails test with GHC 7.10 RC3 > | > | FWIW, I've been noodling over this today since I saw this email, and > | sitting down, I think this may be a blocker worth holding up for after > | thinking about it. At least, it is until we can quantify how much it > | might bite (can we find a workaround? How often does it hit in > | practice?) > | > | I'm testing Iavor's patches that he wanted in at the last minute (I'm > | really hesitant for that, since we could break something), so we've > | got some time, but I'd like to at least narrow this down a bit more. > | > | On Fri, Mar 20, 2015 at 12:37 PM, Herbert Valerio Riedel > | wrote: > | > > | > ...does this in any way affect today's GHC 7.10.1 release? I.e. is this > | > blocking the release? > | > > | > > | > On 2015-03-20 at 18:19:09 +0100, Simon Peyton Jones wrote: > | >> Neil > | >> > | >> Could you open a ticket for this, and attach the info to it? Lots of > | useful info in this thread, but may get lost. > | >> > | >> Re empty cases, see Note [Empty case alternatives] in CoreSyn. "A > | >> case expression can have empty alternatives if (and only if) the > | >> scrutinee is bound to raise an exception or diverge." > | >> > | >> So yes, case (\_ -> ...) of {} is definitely wrong. Could someone > | >> extend Core Lint to check for this? The function to call is > | >> exprIsHNF: if we have > | >> case e of {} > | >> then exprIsHNF should never return True. > | >> > | >> That is a powerful clue, and adding it to Lint will nail the moment at > | which it first happens. Good progress. > | >> > | >> (I'd do it myself but I'm struggling with backlog, and only have 3 > | days left before going on holiday for 10 days.) > | >> > | >> Simon > | >> > | >> | -----Original Message----- > | >> | From: Neil Mitchell [mailto:ndmitchell at gmail.com] > | >> | Sent: 20 March 2015 16:57 > | >> | To: Carter Schonwald > | >> | Cc: Simon Peyton Jones; ghc-devs at haskell.org > | >> | Subject: Re: Shake fails test with GHC 7.10 RC3 > | >> | > | >> | > do you use a deepSeq when catching errors from a pure > | computation? Or > | >> | > is it in a context where you know the value should be treated > | strictly? > | >> | > | >> | The computation is essentially (error "here" :: IO ()), so the IO > | monadic > | >> | binding should force the exception. In the full source code to > | Shake it's > | >> | actually in ContT/ReaderT/IO, but a modification to insert liftIO > | (if > | >> | done in exactly the right way) gives the same result. That > | simplified > | >> | code is at http://community.haskell.org/~ndm/temp/src.zip > | >> | (to run, compile with the logic from > | >> | https://github.com/ndmitchell/shake/blob/master/.ghci :benchmark, > | then > | >> | run "main oracle test"). > | >> | > | >> | > https://github.com/ndmitchell/shake/issues/216 seems to be the > | ticket > | >> | > in question > | >> | > | >> | That is the ticket. The test that is failing is the "oracle" > | >> | (Test.Oracle) test suite, and you can see full logs of both success > | and > | >> | failure at Travis: > | >> | https://travis-ci.org/ndmitchell/shake/builds/54748475 . Note that > | it > | >> | succeeds on GHC 7.2, 7.4, 7.6 and 7.8, but fails on GHC 7.10 RC3 > | and GHC > | >> | Head. > | >> | > | >> | Alas, the actual error is coming from deep in the middle of Shake, > | >> | specifically this line: > | >> | > | > https://github.com/ndmitchell/shake/blob/master/src/Development/Shake/Cor > | >> | e.hs#L329 > | >> | > | >> | Thinking some more on what I saw, my best guess is that: > | >> | > | >> | case (\_ -> ...) of {} > | >> | > | >> | Is a fatal error in GHC. I am guessing that {} means there are no > | >> | alternatives because GHC managed to show that the scrutinee throws > | an > | >> | exception. In addition, evaluating a literal lambda to WHNF will > | not > | >> | throw an exception, so you have a contradiction. > | >> | > | >> | Making increasingly wild speculative guesses, I could imagine this > | code > | >> | compiling to CMM that just fell off the end of a basic block, > | arriving at > | >> | the next statement of supposedly unconnected code. That actually > | matches > | >> | what I'm seeing - I have the exception, using print I can see I am > | at the > | >> | line before, and that I never get to the line after, but pop up > | somewhere > | >> | nearby and continue onwards seemingly ignoring the exception ever > | >> | happened. > | >> | > | >> | If someone can confirm the above pattern of Core is always illegal > | and > | >> | always indicates a GHC error then I can reduce the test case driven > | >> | purely by the Core, which would be far easier - at the moment Shake > | >> | passes through these routines several times to set things up, > | making it > | >> | harder to simplify them too much without changing the preparation > | steps. > | >> | > | >> | Thanks, Neil > | >> | > | >> | > | >> | >> > | >> | >> On Fri, Mar 20, 2015 at 12:01 AM, Neil Mitchell > | >> | >> > | >> | >> wrote: > | >> | >> > More delving later, it seems the incorrect optimized version > | has > | >> | >> > been turned into: > | >> | >> > > | >> | >> > case (\ _ [Occ=Dead, OS=OneShot] -> error "here") of _ > | [Occ=Dead] > | >> | >> > {} > | >> | >> > > | >> | >> > While the working one has been turned into: > | >> | >> > > | >> | >> > errorFunc argument realWorldToken > | >> | >> > > | >> | >> > where errorFunc _ = error "here" > | >> | >> > > | >> | >> > I'm not familiar with case ... of _ {} - what does it mean > | when > | >> | >> > there are no alternatives to the case? And why isn't case on a > | >> | >> > literal lambda optimised out? Is it the OneShot annotation > | (perhaps > | >> | >> > coming from the state hack?) > | >> | >> > > | >> | >> > The full trace is at > | >> | >> > https://gist.github.com/ndmitchell/b222e04eb0c3a397c758. I've > | >> | >> > uploaded bad (optimises the error out) and good (works as > | expected) > | >> | >> > versions of the Core. The summary files are the subexpression > | that > | >> | >> > changed making a single difference (moving a monomorphic > | NOINLINE > | >> | >> > function from one module to another) plus the handful of > | functions > | >> | >> > they depend on, which I've reformatted/inlined/simplified to > | produce > | >> | the expressions above. > | >> | >> > The full versions are the entire -ddump-simpl output from > | about > | >> | >> > halfway through the build, starting when the differences occur > | - > | >> | >> > let me know if you need further back. The dodgy function is > | "exec". > | >> | >> > > | >> | >> > Thanks, Neil > | >> | >> > > | >> | >> > On Thu, Mar 19, 2015 at 11:07 PM, Neil Mitchell > | >> | >> > > | >> | >> > wrote: > | >> | >> >> Herbert, thanks for the list of patches, nothing obvious > | there - > | >> | >> >> my best guess is it's something incredibly sensitive and it > | only > | >> | >> >> needs the tiniest change anywhere to make it happen. Things > | like > | >> | >> >> moving NOINLINE monomorphic-type definitions from one module > | to > | >> | >> >> another are causing the bug to appear/disappear, which isn't > | what > | >> | I'd expect. > | >> | >> >> > | >> | >> >> Simon, changing from error to error in IO causes the bug to > | >> | >> >> disappear, but then so do most things. The error return type > | is > | >> | >> >> type IO (), so I suspect that forces it to be raised at the > | right > | >> | >> >> place - but it's certainly one of the possibilities for what > | is > | >> | >> >> going wrong. Diffing the Core is a great idea. > | >> | >> >> > | >> | >> >> I'll keep reducing and see what I get to. Given the > | sensitivity of > | >> | >> >> the bug, I'm sure a NOINLINE on an out-of-the-way function > | will > | >> | >> >> make it go away, so I can easily fix Shake itself - so I'm > | more > | >> | >> >> tracking it down from the point of GHC now. > | >> | >> >> > | >> | >> >> Thanks, Neil > | >> | >> >> > | >> | >> >> > | >> | >> >> On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones > | >> | >> >> wrote: > | >> | >> >>> I'm really sorry but I can't think of anything. Sounds > | horrible. > | >> | >> >>> > | >> | >> >>> If you throw exceptions using 'error' (not in IO), then you > | are > | >> | >> >>> of course vulnerable to strictness changes. If the thing > | isn't > | >> | >> >>> actually evaluated inside the catch block, you won't see the > | >> | >> >>> exception. But I'm sure you've thought of that. > | >> | >> >>> > | >> | >> >>> I'd experiment with one of the smaller changes you describe, > | such > | >> | >> >>> as adding a putStrLn, and comparing Core, before and after. > | >> | >> >>> Switching off -O will make a huge difference, so hard to > | compare. > | >> | >> >>> Turning off the state hack will have a more global effect. > | But > | >> | >> >>> the other changes sound more pin-point and hence the > | differences > | >> | will be smaller. > | >> | >> >>> > | >> | >> >>> Simon > | >> | >> >>> > | >> | >> >>> | -----Original Message----- > | >> | >> >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On > | Behalf > | >> | >> >>> | Of > | >> | >> >>> Neil > | >> | >> >>> | Mitchell > | >> | >> >>> | Sent: 18 March 2015 15:33 > | >> | >> >>> | To: ghc-devs at haskell.org > | >> | >> >>> | Subject: Shake fails test with GHC 7.10 RC3 > | >> | >> >>> | > | >> | >> >>> | Hi, > | >> | >> >>> | > | >> | >> >>> | Testing GHC 7.10 RC3 I've found a bug where Shake seems > | to > | >> | >> >>> | catch > | >> | >> >>> the > | >> | >> >>> | wrong exception in the wrong place. It's only hit by one > | of my > | >> | >> >>> tests, > | >> | >> >>> | and I've managed to isolate it to a fragment of code with > | no > | >> | >> >>> | unsafePerformIO, that throws exceptions using error (so > | not in > | >> | >> >>> | IO), > | >> | >> >>> and > | >> | >> >>> | operates in IO. Turning off the stack hack makes the bug > | go > | >> | >> >>> | away, > | >> | >> >>> but > | >> | >> >>> | then so does -O0, marking one of the functions it calls > | >> | >> >>> | NOINLINE, > | >> | >> >>> or > | >> | >> >>> | moving an INLINE function it calls to a different module, > | or > | >> | >> >>> | adding > | >> | >> >>> a > | >> | >> >>> | putStrLn under a catch block - it's very sensitive to the > | >> | >> >>> | exact conditions. This test and this exact code worked > | fine > | >> | >> >>> | with GHC 7.10 RC2. > | >> | >> >>> | > | >> | >> >>> | I was wondering if there have been any state hack related > | >> | >> >>> | changes > | >> | >> >>> or > | >> | >> >>> | other potentially dangerous optimisation changes since > | RC2? > | >> | >> >>> | I'll continue to try reducing the bug, but it's somewhat > | >> | >> >>> | difficult as > | >> | >> >>> the > | >> | >> >>> | larger system is quite big, and the code is very > | sensitive. > | >> | >> >>> | > | >> | >> >>> | Thanks, Neil > | >> | >> >>> | _______________________________________________ > | >> | >> >>> | ghc-devs mailing list > | >> | >> >>> | ghc-devs at haskell.org > | >> | >> >>> | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | >> | >> > > | >> | >> > On Thu, Mar 19, 2015 at 11:24 PM, Simon Peyton Jones > | >> | >> > wrote: > | >> | >> >> Thanks! I think a -ddump-simpl before and after the smallest > | >> | >> >> change the makes the difference would be illuminating. > | >> | >> >> > | >> | >> >> Simon > | >> | >> >> > | >> | >> >> | -----Original Message----- > | >> | >> >> | From: Neil Mitchell [mailto:ndmitchell at gmail.com] > | >> | >> >> | Sent: 19 March 2015 23:07 > | >> | >> >> | To: Simon Peyton Jones > | >> | >> >> | Cc: ghc-devs at haskell.org > | >> | >> >> | Subject: Re: Shake fails test with GHC 7.10 RC3 > | >> | >> >> | > | >> | >> >> | Herbert, thanks for the list of patches, nothing obvious > | there - > | >> | >> >> | my best guess is it's something incredibly sensitive and it > | only > | >> | >> >> | needs the tiniest change anywhere to make it happen. Things > | like > | >> | >> >> | moving NOINLINE monomorphic-type definitions from one > | module to > | >> | >> >> | another are causing the bug to appear/disappear, which > | isn't what > | >> | I'd expect. > | >> | >> >> | > | >> | >> >> | Simon, changing from error to error in IO causes the bug to > | >> | >> >> disappear, > | >> | >> >> | but then so do most things. The error return type is type > | IO (), > | >> | >> >> | so I suspect that forces it to be raised at the right place > | - > | >> | >> >> | but it's certainly one of the possibilities for what is > | going > | >> | >> >> | wrong. Diffing the Core is a great idea. > | >> | >> >> | > | >> | >> >> | I'll keep reducing and see what I get to. Given the > | sensitivity > | >> | >> >> | of > | >> | >> >> the > | >> | >> >> | bug, I'm sure a NOINLINE on an out-of-the-way function will > | make > | >> | >> >> | it > | >> | >> >> go > | >> | >> >> | away, so I can easily fix Shake itself - so I'm more > | tracking it > | >> | >> >> | down from the point of GHC now. > | >> | >> >> | > | >> | >> >> | Thanks, Neil > | >> | >> >> | > | >> | >> >> | > | >> | >> >> | On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones > | >> | >> >> | wrote: > | >> | >> >> | > I'm really sorry but I can't think of anything. Sounds > | >> | horrible. > | >> | >> >> | > > | >> | >> >> | > If you throw exceptions using 'error' (not in IO), then > | you > | >> | >> >> | > are of > | >> | >> >> | course vulnerable to strictness changes. If the thing > | isn't > | >> | >> >> | actually evaluated inside the catch block, you won't see > | the > | >> | >> >> | exception. But > | >> | >> >> I'm > | >> | >> >> | sure you've thought of that. > | >> | >> >> | > > | >> | >> >> | > I'd experiment with one of the smaller changes you > | describe, > | >> | >> >> | > such > | >> | >> >> as > | >> | >> >> | adding a putStrLn, and comparing Core, before and after. > | >> | >> >> | Switching > | >> | >> >> off - > | >> | >> >> | O will make a huge difference, so hard to compare. Turning > | off > | >> | >> >> | the > | >> | >> >> state > | >> | >> >> | hack will have a more global effect. But the other changes > | >> | >> >> | sound > | >> | >> >> more > | >> | >> >> | pin-point and hence the differences will be smaller. > | >> | >> >> | > > | >> | >> >> | > Simon > | >> | >> >> | > > | >> | >> >> | > | -----Original Message----- > | >> | >> >> | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] > | On > | >> | >> >> | > | Behalf > | >> | >> >> Of > | >> | >> >> | Neil > | >> | >> >> | > | Mitchell > | >> | >> >> | > | Sent: 18 March 2015 15:33 > | >> | >> >> | > | To: ghc-devs at haskell.org > | >> | >> >> | > | Subject: Shake fails test with GHC 7.10 RC3 > | >> | >> >> | > | > | >> | >> >> | > | Hi, > | >> | >> >> | > | > | >> | >> >> | > | Testing GHC 7.10 RC3 I've found a bug where Shake > | seems to > | >> | >> >> | > | catch > | >> | >> >> the > | >> | >> >> | > | wrong exception in the wrong place. It's only hit by > | one of > | >> | >> >> | > | my > | >> | >> >> | tests, > | >> | >> >> | > | and I've managed to isolate it to a fragment of code > | with > | >> | >> >> | > | no unsafePerformIO, that throws exceptions using error > | (so > | >> | >> >> | > | not in > | >> | >> >> IO), > | >> | >> >> | and > | >> | >> >> | > | operates in IO. Turning off the stack hack makes the > | bug go > | >> | >> >> away, > | >> | >> >> | but > | >> | >> >> | > | then so does -O0, marking one of the functions it > | calls > | >> | >> >> NOINLINE, or > | >> | >> >> | > | moving an INLINE function it calls to a different > | module, > | >> | >> >> | > | or > | >> | >> >> adding > | >> | >> >> | a > | >> | >> >> | > | putStrLn under a catch block - it's very sensitive to > | the > | >> | >> >> | > | exact conditions. This test and this exact code worked > | fine > | >> | >> >> | > | with GHC > | >> | >> >> 7.10 > | >> | >> >> | > | RC2. > | >> | >> >> | > | > | >> | >> >> | > | I was wondering if there have been any state hack > | related > | >> | >> >> changes or > | >> | >> >> | > | other potentially dangerous optimisation changes since > | RC2? > | >> | >> >> | > | I'll continue to try reducing the bug, but it's > | somewhat > | >> | >> >> | > | difficult as > | >> | >> >> the > | >> | >> >> | > | larger system is quite big, and the code is very > | sensitive. > | >> | >> >> | > | > | >> | >> >> | > | Thanks, Neil > | >> | >> >> | > | _______________________________________________ > | >> | >> >> | > | ghc-devs mailing list > | >> | >> >> | > | ghc-devs at haskell.org > | >> | >> >> | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc- > | devs > | >> | >> _______________________________________________ > | >> | >> ghc-devs mailing list > | >> | >> ghc-devs at haskell.org > | >> | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | >> | > > | >> | > > | >> _______________________________________________ > | >> ghc-devs mailing list > | >> ghc-devs at haskell.org > | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > > | > -- > | > "Elegance is not optional" -- Richard O'Keefe > | > > | > | > | > | -- > | Regards, > | > | Austin Seipp, Haskell Consultant > | Well-Typed LLP, http://www.well-typed.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Sat Mar 21 07:21:20 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 21 Mar 2015 08:21:20 +0100 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: (Neil Mitchell's message of "Sat, 21 Mar 2015 06:56:32 +0000") References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> <87k2yb7ep0.fsf@gmail.com> <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <878ueqyfwv.fsf@gmail.com> On 2015-03-21 at 07:56:32 +0100, Neil Mitchell wrote: [...] > 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The fact no > one else hit this with RC2 might just be because its a very recent > regression. We -- and by that I don't mean myself... :) -- could git-bisect between RC2 and RC3 here (semi-)automatically (i.e. maybe unattended if it's scriptable) if your test-case (even if it's not minimal) reliably triggers the bug... Cheers, hvr From ndmitchell at gmail.com Sat Mar 21 08:10:05 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat, 21 Mar 2015 08:10:05 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: <878ueqyfwv.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> <87k2yb7ep0.fsf@gmail.com> <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> <878ueqyfwv.fsf@gmail.com> Message-ID: A simple test case should be as simple as checkout Shake (https://github.com/ndmitchell/shake.git), cabal build as necessary then cabal test. A shorter (and fractionally more robust) test would be "shake-test oracle test", using the Cabal test suite. Thanks, Neil On Sat, Mar 21, 2015 at 7:21 AM, Herbert Valerio Riedel wrote: > On 2015-03-21 at 07:56:32 +0100, Neil Mitchell wrote: > > [...] > >> 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The fact no >> one else hit this with RC2 might just be because its a very recent >> regression. > > We -- and by that I don't mean myself... :) -- could git-bisect between > RC2 and RC3 here (semi-)automatically (i.e. maybe unattended if it's > scriptable) if your test-case (even if it's not minimal) reliably > triggers the bug... > > Cheers, > hvr From ndmitchell at gmail.com Sat Mar 21 08:36:39 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat, 21 Mar 2015 08:36:39 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> <87k2yb7ep0.fsf@gmail.com> <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> <878ueqyfwv.fsf@gmail.com> Message-ID: I've created a ticket at: https://ghc.haskell.org/trac/ghc/ticket/10176 Now I know what I'm looking for, I'll aim to track down a minimal example over nap time (about 5 hours from now). Thanks, Neil On Sat, Mar 21, 2015 at 8:10 AM, Neil Mitchell wrote: > A simple test case should be as simple as checkout Shake > (https://github.com/ndmitchell/shake.git), cabal build as necessary > then cabal test. A shorter (and fractionally more robust) test would > be "shake-test oracle test", using the Cabal test suite. > > Thanks, Neil > > > On Sat, Mar 21, 2015 at 7:21 AM, Herbert Valerio Riedel > wrote: >> On 2015-03-21 at 07:56:32 +0100, Neil Mitchell wrote: >> >> [...] >> >>> 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The fact no >>> one else hit this with RC2 might just be because its a very recent >>> regression. >> >> We -- and by that I don't mean myself... :) -- could git-bisect between >> RC2 and RC3 here (semi-)automatically (i.e. maybe unattended if it's >> scriptable) if your test-case (even if it's not minimal) reliably >> triggers the bug... >> >> Cheers, >> hvr From hvriedel at gmail.com Sat Mar 21 11:35:34 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 21 Mar 2015 12:35:34 +0100 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: <878ueqyfwv.fsf@gmail.com> (Herbert Valerio Riedel's message of "Sat, 21 Mar 2015 08:21:20 +0100") References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> <87k2yb7ep0.fsf@gmail.com> <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> <878ueqyfwv.fsf@gmail.com> Message-ID: <87r3siwpkp.fsf@gmail.com> On 2015-03-21 at 08:21:20 +0100, Herbert Valerio Riedel wrote: > On 2015-03-21 at 07:56:32 +0100, Neil Mitchell wrote: > > [...] > >> 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The fact no >> one else hit this with RC2 might just be because its a very recent >> regression. > > We -- and by that I don't mean myself... :) -- could git-bisect between > RC2 and RC3 here (semi-)automatically (i.e. maybe unattended if it's > scriptable) if your test-case (even if it's not minimal) reliably > triggers the bug... I scripted up a test and git-bisected between RC2 and RC3, and the following commit is the one where `shake-test oracle test` starts failing http://git.haskell.org/ghc.git/commitdiff/6f46fe15af397d448438c6b93babcdd68dd78df8 ...which sadly is a rather large patch :-/ From ndmitchell at gmail.com Sat Mar 21 11:55:30 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sat, 21 Mar 2015 11:55:30 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: <87r3siwpkp.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> <87k2yb7ep0.fsf@gmail.com> <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> <878ueqyfwv.fsf@gmail.com> <87r3siwpkp.fsf@gmail.com> Message-ID: Interesting result. I've just attached a much smaller test case to the ticket - it would be good to see if that fails or passes with RC2, or breaks at the same point. The fact that there does seem to be a regression between RC2 and RC3 (either a regression itself, or making a previous bug easier to hit) makes me think that a release might not be such a great idea. Thanks, Neil On Sat, Mar 21, 2015 at 11:35 AM, Herbert Valerio Riedel wrote: > On 2015-03-21 at 08:21:20 +0100, Herbert Valerio Riedel wrote: >> On 2015-03-21 at 07:56:32 +0100, Neil Mitchell wrote: >> >> [...] >> >>> 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The fact no >>> one else hit this with RC2 might just be because its a very recent >>> regression. >> >> We -- and by that I don't mean myself... :) -- could git-bisect between >> RC2 and RC3 here (semi-)automatically (i.e. maybe unattended if it's >> scriptable) if your test-case (even if it's not minimal) reliably >> triggers the bug... > > I scripted up a test and git-bisected between RC2 and RC3, and the > following commit is the one where `shake-test oracle test` starts > failing > > http://git.haskell.org/ghc.git/commitdiff/6f46fe15af397d448438c6b93babcdd68dd78df8 > > ...which sadly is a rather large patch :-/ From george.colpitts at gmail.com Sat Mar 21 16:57:50 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 21 Mar 2015 13:57:50 -0300 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> <87k2yb7ep0.fsf@gmail.com> <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> Message-ID: my two cents, FWIW: I'd really like to see a bindist for MacOS before we release it On Fri, Mar 20, 2015 at 8:16 PM, Simon Peyton Jones wrote: > | FWIW, I've been noodling over this today since I saw this email, and > | sitting down, I think this may be a blocker worth holding up for after > | thinking about it. At least, it is until we can quantify how much it > | might bite (can we find a workaround? How often does it hit in > | practice?) > > I'm reluctant to delay 7.10 further. I'm sure there are other bugs, and > we'll want 7.10.2 before too long. But we won't find them until we push > it out. The danger is that we stay in about-to-release mode for ages, and > that holds everyone up. We've had three release candidates out over a > period of months and Neil seems to be the only one who has tripped over it. > > I think it'd be better to push it out. (We planned to do so today!) What > do others think? > > Simon > > | -----Original Message----- > | From: mad.one at gmail.com [mailto:mad.one at gmail.com] On Behalf Of Austin > | Seipp > | Sent: 20 March 2015 22:48 > | To: Herbert Valerio Riedel > | Cc: Simon Peyton Jones; Austin Seipp > | Subject: Re: Shake fails test with GHC 7.10 RC3 > | > | FWIW, I've been noodling over this today since I saw this email, and > | sitting down, I think this may be a blocker worth holding up for after > | thinking about it. At least, it is until we can quantify how much it > | might bite (can we find a workaround? How often does it hit in > | practice?) > | > | I'm testing Iavor's patches that he wanted in at the last minute (I'm > | really hesitant for that, since we could break something), so we've > | got some time, but I'd like to at least narrow this down a bit more. > | > | On Fri, Mar 20, 2015 at 12:37 PM, Herbert Valerio Riedel > | wrote: > | > > | > ...does this in any way affect today's GHC 7.10.1 release? I.e. is this > | > blocking the release? > | > > | > > | > On 2015-03-20 at 18:19:09 +0100, Simon Peyton Jones wrote: > | >> Neil > | >> > | >> Could you open a ticket for this, and attach the info to it? Lots of > | useful info in this thread, but may get lost. > | >> > | >> Re empty cases, see Note [Empty case alternatives] in CoreSyn. "A > | >> case expression can have empty alternatives if (and only if) the > | >> scrutinee is bound to raise an exception or diverge." > | >> > | >> So yes, case (\_ -> ...) of {} is definitely wrong. Could someone > | >> extend Core Lint to check for this? The function to call is > | >> exprIsHNF: if we have > | >> case e of {} > | >> then exprIsHNF should never return True. > | >> > | >> That is a powerful clue, and adding it to Lint will nail the moment at > | which it first happens. Good progress. > | >> > | >> (I'd do it myself but I'm struggling with backlog, and only have 3 > | days left before going on holiday for 10 days.) > | >> > | >> Simon > | >> > | >> | -----Original Message----- > | >> | From: Neil Mitchell [mailto:ndmitchell at gmail.com] > | >> | Sent: 20 March 2015 16:57 > | >> | To: Carter Schonwald > | >> | Cc: Simon Peyton Jones; ghc-devs at haskell.org > | >> | Subject: Re: Shake fails test with GHC 7.10 RC3 > | >> | > | >> | > do you use a deepSeq when catching errors from a pure > | computation? Or > | >> | > is it in a context where you know the value should be treated > | strictly? > | >> | > | >> | The computation is essentially (error "here" :: IO ()), so the IO > | monadic > | >> | binding should force the exception. In the full source code to > | Shake it's > | >> | actually in ContT/ReaderT/IO, but a modification to insert liftIO > | (if > | >> | done in exactly the right way) gives the same result. That > | simplified > | >> | code is at http://community.haskell.org/~ndm/temp/src.zip > | >> | (to run, compile with the logic from > | >> | https://github.com/ndmitchell/shake/blob/master/.ghci :benchmark, > | then > | >> | run "main oracle test"). > | >> | > | >> | > https://github.com/ndmitchell/shake/issues/216 seems to be the > | ticket > | >> | > in question > | >> | > | >> | That is the ticket. The test that is failing is the "oracle" > | >> | (Test.Oracle) test suite, and you can see full logs of both success > | and > | >> | failure at Travis: > | >> | https://travis-ci.org/ndmitchell/shake/builds/54748475 . Note that > | it > | >> | succeeds on GHC 7.2, 7.4, 7.6 and 7.8, but fails on GHC 7.10 RC3 > | and GHC > | >> | Head. > | >> | > | >> | Alas, the actual error is coming from deep in the middle of Shake, > | >> | specifically this line: > | >> | > | > https://github.com/ndmitchell/shake/blob/master/src/Development/Shake/Cor > | >> | e.hs#L329 > | >> | > | >> | Thinking some more on what I saw, my best guess is that: > | >> | > | >> | case (\_ -> ...) of {} > | >> | > | >> | Is a fatal error in GHC. I am guessing that {} means there are no > | >> | alternatives because GHC managed to show that the scrutinee throws > | an > | >> | exception. In addition, evaluating a literal lambda to WHNF will > | not > | >> | throw an exception, so you have a contradiction. > | >> | > | >> | Making increasingly wild speculative guesses, I could imagine this > | code > | >> | compiling to CMM that just fell off the end of a basic block, > | arriving at > | >> | the next statement of supposedly unconnected code. That actually > | matches > | >> | what I'm seeing - I have the exception, using print I can see I am > | at the > | >> | line before, and that I never get to the line after, but pop up > | somewhere > | >> | nearby and continue onwards seemingly ignoring the exception ever > | >> | happened. > | >> | > | >> | If someone can confirm the above pattern of Core is always illegal > | and > | >> | always indicates a GHC error then I can reduce the test case driven > | >> | purely by the Core, which would be far easier - at the moment Shake > | >> | passes through these routines several times to set things up, > | making it > | >> | harder to simplify them too much without changing the preparation > | steps. > | >> | > | >> | Thanks, Neil > | >> | > | >> | > | >> | >> > | >> | >> On Fri, Mar 20, 2015 at 12:01 AM, Neil Mitchell > | >> | >> > | >> | >> wrote: > | >> | >> > More delving later, it seems the incorrect optimized version > | has > | >> | >> > been turned into: > | >> | >> > > | >> | >> > case (\ _ [Occ=Dead, OS=OneShot] -> error "here") of _ > | [Occ=Dead] > | >> | >> > {} > | >> | >> > > | >> | >> > While the working one has been turned into: > | >> | >> > > | >> | >> > errorFunc argument realWorldToken > | >> | >> > > | >> | >> > where errorFunc _ = error "here" > | >> | >> > > | >> | >> > I'm not familiar with case ... of _ {} - what does it mean > | when > | >> | >> > there are no alternatives to the case? And why isn't case on a > | >> | >> > literal lambda optimised out? Is it the OneShot annotation > | (perhaps > | >> | >> > coming from the state hack?) > | >> | >> > > | >> | >> > The full trace is at > | >> | >> > https://gist.github.com/ndmitchell/b222e04eb0c3a397c758. I've > | >> | >> > uploaded bad (optimises the error out) and good (works as > | expected) > | >> | >> > versions of the Core. The summary files are the subexpression > | that > | >> | >> > changed making a single difference (moving a monomorphic > | NOINLINE > | >> | >> > function from one module to another) plus the handful of > | functions > | >> | >> > they depend on, which I've reformatted/inlined/simplified to > | produce > | >> | the expressions above. > | >> | >> > The full versions are the entire -ddump-simpl output from > | about > | >> | >> > halfway through the build, starting when the differences occur > | - > | >> | >> > let me know if you need further back. The dodgy function is > | "exec". > | >> | >> > > | >> | >> > Thanks, Neil > | >> | >> > > | >> | >> > On Thu, Mar 19, 2015 at 11:07 PM, Neil Mitchell > | >> | >> > > | >> | >> > wrote: > | >> | >> >> Herbert, thanks for the list of patches, nothing obvious > | there - > | >> | >> >> my best guess is it's something incredibly sensitive and it > | only > | >> | >> >> needs the tiniest change anywhere to make it happen. Things > | like > | >> | >> >> moving NOINLINE monomorphic-type definitions from one module > | to > | >> | >> >> another are causing the bug to appear/disappear, which isn't > | what > | >> | I'd expect. > | >> | >> >> > | >> | >> >> Simon, changing from error to error in IO causes the bug to > | >> | >> >> disappear, but then so do most things. The error return type > | is > | >> | >> >> type IO (), so I suspect that forces it to be raised at the > | right > | >> | >> >> place - but it's certainly one of the possibilities for what > | is > | >> | >> >> going wrong. Diffing the Core is a great idea. > | >> | >> >> > | >> | >> >> I'll keep reducing and see what I get to. Given the > | sensitivity of > | >> | >> >> the bug, I'm sure a NOINLINE on an out-of-the-way function > | will > | >> | >> >> make it go away, so I can easily fix Shake itself - so I'm > | more > | >> | >> >> tracking it down from the point of GHC now. > | >> | >> >> > | >> | >> >> Thanks, Neil > | >> | >> >> > | >> | >> >> > | >> | >> >> On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones > | >> | >> >> wrote: > | >> | >> >>> I'm really sorry but I can't think of anything. Sounds > | horrible. > | >> | >> >>> > | >> | >> >>> If you throw exceptions using 'error' (not in IO), then you > | are > | >> | >> >>> of course vulnerable to strictness changes. If the thing > | isn't > | >> | >> >>> actually evaluated inside the catch block, you won't see the > | >> | >> >>> exception. But I'm sure you've thought of that. > | >> | >> >>> > | >> | >> >>> I'd experiment with one of the smaller changes you describe, > | such > | >> | >> >>> as adding a putStrLn, and comparing Core, before and after. > | >> | >> >>> Switching off -O will make a huge difference, so hard to > | compare. > | >> | >> >>> Turning off the state hack will have a more global effect. > | But > | >> | >> >>> the other changes sound more pin-point and hence the > | differences > | >> | will be smaller. > | >> | >> >>> > | >> | >> >>> Simon > | >> | >> >>> > | >> | >> >>> | -----Original Message----- > | >> | >> >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On > | Behalf > | >> | >> >>> | Of > | >> | >> >>> Neil > | >> | >> >>> | Mitchell > | >> | >> >>> | Sent: 18 March 2015 15:33 > | >> | >> >>> | To: ghc-devs at haskell.org > | >> | >> >>> | Subject: Shake fails test with GHC 7.10 RC3 > | >> | >> >>> | > | >> | >> >>> | Hi, > | >> | >> >>> | > | >> | >> >>> | Testing GHC 7.10 RC3 I've found a bug where Shake seems > | to > | >> | >> >>> | catch > | >> | >> >>> the > | >> | >> >>> | wrong exception in the wrong place. It's only hit by one > | of my > | >> | >> >>> tests, > | >> | >> >>> | and I've managed to isolate it to a fragment of code with > | no > | >> | >> >>> | unsafePerformIO, that throws exceptions using error (so > | not in > | >> | >> >>> | IO), > | >> | >> >>> and > | >> | >> >>> | operates in IO. Turning off the stack hack makes the bug > | go > | >> | >> >>> | away, > | >> | >> >>> but > | >> | >> >>> | then so does -O0, marking one of the functions it calls > | >> | >> >>> | NOINLINE, > | >> | >> >>> or > | >> | >> >>> | moving an INLINE function it calls to a different module, > | or > | >> | >> >>> | adding > | >> | >> >>> a > | >> | >> >>> | putStrLn under a catch block - it's very sensitive to the > | >> | >> >>> | exact conditions. This test and this exact code worked > | fine > | >> | >> >>> | with GHC 7.10 RC2. > | >> | >> >>> | > | >> | >> >>> | I was wondering if there have been any state hack related > | >> | >> >>> | changes > | >> | >> >>> or > | >> | >> >>> | other potentially dangerous optimisation changes since > | RC2? > | >> | >> >>> | I'll continue to try reducing the bug, but it's somewhat > | >> | >> >>> | difficult as > | >> | >> >>> the > | >> | >> >>> | larger system is quite big, and the code is very > | sensitive. > | >> | >> >>> | > | >> | >> >>> | Thanks, Neil > | >> | >> >>> | _______________________________________________ > | >> | >> >>> | ghc-devs mailing list > | >> | >> >>> | ghc-devs at haskell.org > | >> | >> >>> | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | >> | >> > > | >> | >> > On Thu, Mar 19, 2015 at 11:24 PM, Simon Peyton Jones > | >> | >> > wrote: > | >> | >> >> Thanks! I think a -ddump-simpl before and after the smallest > | >> | >> >> change the makes the difference would be illuminating. > | >> | >> >> > | >> | >> >> Simon > | >> | >> >> > | >> | >> >> | -----Original Message----- > | >> | >> >> | From: Neil Mitchell [mailto:ndmitchell at gmail.com] > | >> | >> >> | Sent: 19 March 2015 23:07 > | >> | >> >> | To: Simon Peyton Jones > | >> | >> >> | Cc: ghc-devs at haskell.org > | >> | >> >> | Subject: Re: Shake fails test with GHC 7.10 RC3 > | >> | >> >> | > | >> | >> >> | Herbert, thanks for the list of patches, nothing obvious > | there - > | >> | >> >> | my best guess is it's something incredibly sensitive and it > | only > | >> | >> >> | needs the tiniest change anywhere to make it happen. Things > | like > | >> | >> >> | moving NOINLINE monomorphic-type definitions from one > | module to > | >> | >> >> | another are causing the bug to appear/disappear, which > | isn't what > | >> | I'd expect. > | >> | >> >> | > | >> | >> >> | Simon, changing from error to error in IO causes the bug to > | >> | >> >> disappear, > | >> | >> >> | but then so do most things. The error return type is type > | IO (), > | >> | >> >> | so I suspect that forces it to be raised at the right place > | - > | >> | >> >> | but it's certainly one of the possibilities for what is > | going > | >> | >> >> | wrong. Diffing the Core is a great idea. > | >> | >> >> | > | >> | >> >> | I'll keep reducing and see what I get to. Given the > | sensitivity > | >> | >> >> | of > | >> | >> >> the > | >> | >> >> | bug, I'm sure a NOINLINE on an out-of-the-way function will > | make > | >> | >> >> | it > | >> | >> >> go > | >> | >> >> | away, so I can easily fix Shake itself - so I'm more > | tracking it > | >> | >> >> | down from the point of GHC now. > | >> | >> >> | > | >> | >> >> | Thanks, Neil > | >> | >> >> | > | >> | >> >> | > | >> | >> >> | On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones > | >> | >> >> | wrote: > | >> | >> >> | > I'm really sorry but I can't think of anything. Sounds > | >> | horrible. > | >> | >> >> | > > | >> | >> >> | > If you throw exceptions using 'error' (not in IO), then > | you > | >> | >> >> | > are of > | >> | >> >> | course vulnerable to strictness changes. If the thing > | isn't > | >> | >> >> | actually evaluated inside the catch block, you won't see > | the > | >> | >> >> | exception. But > | >> | >> >> I'm > | >> | >> >> | sure you've thought of that. > | >> | >> >> | > > | >> | >> >> | > I'd experiment with one of the smaller changes you > | describe, > | >> | >> >> | > such > | >> | >> >> as > | >> | >> >> | adding a putStrLn, and comparing Core, before and after. > | >> | >> >> | Switching > | >> | >> >> off - > | >> | >> >> | O will make a huge difference, so hard to compare. Turning > | off > | >> | >> >> | the > | >> | >> >> state > | >> | >> >> | hack will have a more global effect. But the other changes > | >> | >> >> | sound > | >> | >> >> more > | >> | >> >> | pin-point and hence the differences will be smaller. > | >> | >> >> | > > | >> | >> >> | > Simon > | >> | >> >> | > > | >> | >> >> | > | -----Original Message----- > | >> | >> >> | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] > | On > | >> | >> >> | > | Behalf > | >> | >> >> Of > | >> | >> >> | Neil > | >> | >> >> | > | Mitchell > | >> | >> >> | > | Sent: 18 March 2015 15:33 > | >> | >> >> | > | To: ghc-devs at haskell.org > | >> | >> >> | > | Subject: Shake fails test with GHC 7.10 RC3 > | >> | >> >> | > | > | >> | >> >> | > | Hi, > | >> | >> >> | > | > | >> | >> >> | > | Testing GHC 7.10 RC3 I've found a bug where Shake > | seems to > | >> | >> >> | > | catch > | >> | >> >> the > | >> | >> >> | > | wrong exception in the wrong place. It's only hit by > | one of > | >> | >> >> | > | my > | >> | >> >> | tests, > | >> | >> >> | > | and I've managed to isolate it to a fragment of code > | with > | >> | >> >> | > | no unsafePerformIO, that throws exceptions using error > | (so > | >> | >> >> | > | not in > | >> | >> >> IO), > | >> | >> >> | and > | >> | >> >> | > | operates in IO. Turning off the stack hack makes the > | bug go > | >> | >> >> away, > | >> | >> >> | but > | >> | >> >> | > | then so does -O0, marking one of the functions it > | calls > | >> | >> >> NOINLINE, or > | >> | >> >> | > | moving an INLINE function it calls to a different > | module, > | >> | >> >> | > | or > | >> | >> >> adding > | >> | >> >> | a > | >> | >> >> | > | putStrLn under a catch block - it's very sensitive to > | the > | >> | >> >> | > | exact conditions. This test and this exact code worked > | fine > | >> | >> >> | > | with GHC > | >> | >> >> 7.10 > | >> | >> >> | > | RC2. > | >> | >> >> | > | > | >> | >> >> | > | I was wondering if there have been any state hack > | related > | >> | >> >> changes or > | >> | >> >> | > | other potentially dangerous optimisation changes since > | RC2? > | >> | >> >> | > | I'll continue to try reducing the bug, but it's > | somewhat > | >> | >> >> | > | difficult as > | >> | >> >> the > | >> | >> >> | > | larger system is quite big, and the code is very > | sensitive. > | >> | >> >> | > | > | >> | >> >> | > | Thanks, Neil > | >> | >> >> | > | _______________________________________________ > | >> | >> >> | > | ghc-devs mailing list > | >> | >> >> | > | ghc-devs at haskell.org > | >> | >> >> | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc- > | devs > | >> | >> _______________________________________________ > | >> | >> ghc-devs mailing list > | >> | >> ghc-devs at haskell.org > | >> | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | >> | > > | >> | > > | >> _______________________________________________ > | >> ghc-devs mailing list > | >> ghc-devs at haskell.org > | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > | > > | > -- > | > "Elegance is not optional" -- Richard O'Keefe > | > > | > | > | > | -- > | Regards, > | > | Austin Seipp, Haskell Consultant > | Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sat Mar 21 17:54:26 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 21 Mar 2015 10:54:26 -0700 Subject: wither the Platform Message-ID: I'm wondering how we are all feeling about the platform these days.... I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it. Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it. That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell. The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do. I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed: *1) Abandon the Platform.* GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes. *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell. *3) Re-conceive the Platform.* Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction. Thoughts? ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Sat Mar 21 18:31:33 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat, 21 Mar 2015 11:31:33 -0700 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: <87r3siwpkp.fsf@gmail.com> References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> <87k2yb7ep0.fsf@gmail.com> <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> <878ueqyfwv.fsf@gmail.com> <87r3siwpkp.fsf@gmail.com> Message-ID: This is very odd---the example on the ticket does not use `Typeable` at all. I looked through the diffs of the patch and I can't see anything obviously wrong. Also, the `Typeable` code only touches modules that are in the front-end, and when I compile without optimizations, the example looks reasonable. I wonder if the problem is related to some odd interaction between simplification rules and representational equities? On Sat, Mar 21, 2015 at 4:35 AM, Herbert Valerio Riedel wrote: > On 2015-03-21 at 08:21:20 +0100, Herbert Valerio Riedel wrote: > > On 2015-03-21 at 07:56:32 +0100, Neil Mitchell wrote: > > > > [...] > > > >> 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The fact > no > >> one else hit this with RC2 might just be because its a very recent > >> regression. > > > > We -- and by that I don't mean myself... :) -- could git-bisect between > > RC2 and RC3 here (semi-)automatically (i.e. maybe unattended if it's > > scriptable) if your test-case (even if it's not minimal) reliably > > triggers the bug... > > I scripted up a test and git-bisected between RC2 and RC3, and the > following commit is the one where `shake-test oracle test` starts > failing > > > http://git.haskell.org/ghc.git/commitdiff/6f46fe15af397d448438c6b93babcdd68dd78df8 > > ...which sadly is a rather large patch :-/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Sat Mar 21 20:45:04 2015 From: austin at well-typed.com (Austin Seipp) Date: Sat, 21 Mar 2015 15:45:04 -0500 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> <87k2yb7ep0.fsf@gmail.com> <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> <878ueqyfwv.fsf@gmail.com> <87r3siwpkp.fsf@gmail.com> Message-ID: Yes, this was what I was afraid of; an introduced regression in the RC 2-to-3 period, which IMO makes the bug a bit more serious. Also, this bug in particular looks like it manifests in a fairly nasty way, and having it catch people for the final release seems a bit worrisome. I also just remembered that the Haddock documentation for 7.10.1 is still broken; I've been tracking the bug today, but I need to sync up with the Haddock maintainers to discuss more. I really think this one needs to be fixed. So I also suggest we postpone for a few days to fix these two things, if possible. On Sat, Mar 21, 2015 at 6:55 AM, Neil Mitchell wrote: > Interesting result. I've just attached a much smaller test case to the > ticket - it would be good to see if that fails or passes with RC2, or > breaks at the same point. > > The fact that there does seem to be a regression between RC2 and RC3 > (either a regression itself, or making a previous bug easier to hit) > makes me think that a release might not be such a great idea. > > Thanks, Neil > > > On Sat, Mar 21, 2015 at 11:35 AM, Herbert Valerio Riedel > wrote: >> On 2015-03-21 at 08:21:20 +0100, Herbert Valerio Riedel wrote: >>> On 2015-03-21 at 07:56:32 +0100, Neil Mitchell wrote: >>> >>> [...] >>> >>>> 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The fact no >>>> one else hit this with RC2 might just be because its a very recent >>>> regression. >>> >>> We -- and by that I don't mean myself... :) -- could git-bisect between >>> RC2 and RC3 here (semi-)automatically (i.e. maybe unattended if it's >>> scriptable) if your test-case (even if it's not minimal) reliably >>> triggers the bug... >> >> I scripted up a test and git-bisected between RC2 and RC3, and the >> following commit is the one where `shake-test oracle test` starts >> failing >> >> http://git.haskell.org/ghc.git/commitdiff/6f46fe15af397d448438c6b93babcdd68dd78df8 >> >> ...which sadly is a rather large patch :-/ > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Sat Mar 21 21:28:56 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 21 Mar 2015 21:28:56 +0000 Subject: Shake fails test with GHC 7.10 RC3 In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7C042928@DBXPRD3001MB024.064d.mgd.msft.net> <9c35501898054539b12136cf96e8d767@DB4PR30MB030.064d.mgd.msft.net> <48ab96d9af3e494caed932e61c56de26@DB4PR30MB030.064d.mgd.msft.net> <87k2yb7ep0.fsf@gmail.com> <1baf6c455ece4513aad2d3c7bf8d89de@DB4PR30MB030.064d.mgd.msft.net> <878ueqyfwv.fsf@gmail.com> <87r3siwpkp.fsf@gmail.com> Message-ID: <7f9bf0a8260440e8af0941f9dc9a798e@DB4PR30MB030.064d.mgd.msft.net> OK | -----Original Message----- | From: mad.one at gmail.com [mailto:mad.one at gmail.com] On Behalf Of Austin | Seipp | Sent: 21 March 2015 20:45 | To: Neil Mitchell | Cc: Herbert Valerio Riedel; Simon Peyton Jones; Austin Seipp; ghc- | devs at haskell.org; ShanaTsunTsunLove | Subject: Re: Shake fails test with GHC 7.10 RC3 | | Yes, this was what I was afraid of; an introduced regression in the RC | 2-to-3 period, which IMO makes the bug a bit more serious. Also, this | bug in particular looks like it manifests in a fairly nasty way, and | having it catch people for the final release seems a bit worrisome. | | I also just remembered that the Haddock documentation for 7.10.1 is | still broken; I've been tracking the bug today, but I need to sync up | with the Haddock maintainers to discuss more. I really think this one | needs to be fixed. | | So I also suggest we postpone for a few days to fix these two things, | if possible. | | On Sat, Mar 21, 2015 at 6:55 AM, Neil Mitchell | wrote: | > Interesting result. I've just attached a much smaller test case to the | > ticket - it would be good to see if that fails or passes with RC2, or | > breaks at the same point. | > | > The fact that there does seem to be a regression between RC2 and RC3 | > (either a regression itself, or making a previous bug easier to hit) | > makes me think that a release might not be such a great idea. | > | > Thanks, Neil | > | > | > On Sat, Mar 21, 2015 at 11:35 AM, Herbert Valerio Riedel | > wrote: | >> On 2015-03-21 at 08:21:20 +0100, Herbert Valerio Riedel wrote: | >>> On 2015-03-21 at 07:56:32 +0100, Neil Mitchell wrote: | >>> | >>> [...] | >>> | >>>> 3) I tested with GHC RC1 and GHC RC2, both of which were fine. The | fact no | >>>> one else hit this with RC2 might just be because its a very recent | >>>> regression. | >>> | >>> We -- and by that I don't mean myself... :) -- could git-bisect | between | >>> RC2 and RC3 here (semi-)automatically (i.e. maybe unattended if it's | >>> scriptable) if your test-case (even if it's not minimal) reliably | >>> triggers the bug... | >> | >> I scripted up a test and git-bisected between RC2 and RC3, and the | >> following commit is the one where `shake-test oracle test` starts | >> failing | >> | >> | http://git.haskell.org/ghc.git/commitdiff/6f46fe15af397d448438c6b93babcdd | 68dd78df8 | >> | >> ...which sadly is a rather large patch :-/ | > | | | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ From simonpj at microsoft.com Sat Mar 21 21:51:37 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 21 Mar 2015 21:51:37 +0000 Subject: GHC Trac In-Reply-To: References: Message-ID: <99e1f8d3754d4fceb63b905b9281ff6d@DB4PR30MB030.064d.mgd.msft.net> | We really need to fix this... +100 Simon | -----Original Message----- | From: mad.one at gmail.com [mailto:mad.one at gmail.com] On Behalf Of Austin | Seipp | Sent: 20 March 2015 23:23 | To: Christopher Allen | Cc: Simon Peyton Jones; ghc-devs at haskell.org | Subject: Re: GHC Trac | | Should be back online now. | | I think we're getting hit by bots, and we can't handle the load from | some of them as they incur expensive CPU operations on Trac. | | We really need to fix this... | | On Fri, Mar 20, 2015 at 6:21 PM, Christopher Allen | wrote: | > Yes, has been for a good chunk of the day for myself and others. | > | > On Fri, Mar 20, 2015 at 6:20 PM, Simon Peyton Jones | | > wrote: | >> | >> Is it just me, or is GHC?s Trac super-slow (again)? Actually it?s not | >> just slow but offline from where I am. | >> | >> Simon | >> | >> | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs at haskell.org | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >> | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | | | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ From mark.lentczner at gmail.com Sat Mar 21 22:32:51 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 21 Mar 2015 15:32:51 -0700 Subject: wither the Platform In-Reply-To: <488486214.2564190.1426965010068.JavaMail.yahoo@mail.yahoo.com> References: <488486214.2564190.1426965010068.JavaMail.yahoo@mail.yahoo.com> Message-ID: Eeek! I really really did mean to make the subject *whither*, not *wither!*? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhoermann at gmail.com Sat Mar 21 23:21:38 2015 From: mhoermann at gmail.com (=?UTF-8?Q?Matthias_H=C3=B6rmann?=) Date: Sun, 22 Mar 2015 00:21:38 +0100 Subject: wither the Platform In-Reply-To: References: <488486214.2564190.1426965010068.JavaMail.yahoo@mail.yahoo.com> Message-ID: I can't speak for others but as a regular but enthusiastic Haskell user the platform always (not just since sandboxes) felt outdated and limited to the included packages since the rest of the Haskell ecosystem rapidly moved on after a platform release (or even during its stabilization freeze phase before a release). The platform is quite similar to Linux distributions like Debian stable or RedHat Enterprise Linux in that sense. Running software not in their repositories on one of those is a bit of a pain and not for the beginner too, just as running packages outside the HP can be when you start out with it. The majority of the Haskell power users (library authors, people interested in the language development itself,...) on the other hand run Haskell more like a rolling release Linux distribution, dealing with problems due to cutting edge versions as they arise which means cutting Hackage versions do not build on the HP. On the other hand new versions that do compile very rarely seem to cause major issues, offering little incentive to use older versions for power users outside enterprise support environments. Perhaps Haskell does need some kind of multi-tier system as those Linux distributions use? LTS and Stackage seem to be attempts to do just that. In any case, I do not think the HP is the best environment for the new Haskell user. Perhaps listing the possible types of users and their requirements and limitations would be helpful to decide what, if anything, should replace the HP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Mar 21 23:52:23 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 21 Mar 2015 19:52:23 -0400 Subject: can't run validate on OS X for 7.10 head branch! Message-ID: hey everyone! error: unknown warning option '-Werror=unused-but-set-variable'; did you mean '-Werror=unused-const-variable'? [-Werror,-Wunknown-warning-option] is the key bit, seems like apple clang bundled with xcode 6 doesn't have that option thoughts? (do we need to do some auto conf magic to support more clang variants?) this gist provides a bit more context https://gist.github.com/cartazio/ac04ab8048c9f7577d3d thanks! -Carter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rf at rufflewind.com Sun Mar 22 02:43:32 2015 From: rf at rufflewind.com (Phil Ruffwind) Date: Sat, 21 Mar 2015 22:43:32 -0400 Subject: can't run validate on OS X for 7.10 head branch! In-Reply-To: References: Message-ID: > is the key bit, seems like apple clang bundled with xcode 6 doesn't have > that option Does not work on mine either (clang 3.6.0). This might be a gcc-only flag. From ndmitchell at gmail.com Sun Mar 22 09:17:54 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Sun, 22 Mar 2015 09:17:54 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: On Windows, the reason I used to use the Platform was that it came with an installed network library, and installing the network library on Windows is a real pain (and often fails). Unfortunately it was incredibly brittle, a single attempt at upgrading network from some newer package usually trashed my Haskell install and required a wipe and restart. Nowadays I use https://github.com/fpco/minghc which can actually install network, and I've had zero problems. I can get up to the platform with one invoke of cabal, and if someone decides to require a new network, it just works. I think the Platform now gives a worse user experience on Windows, so the ideas (or names) probably need migrating around. Thanks, Neil On Sun, Mar 22, 2015 at 8:47 AM, Heinrich Apfelmus wrote: > Mark Lentczner wrote: >> >> I'm wondering how we are all feeling about the platform these days.... >> >> I notice that in the new Haskell pages, the Platform is definitely not the >> recommended way to go: The main download pages suggests the compiler and >> base libraries as the first option - and the text for the Platform (second >> option) pretty much steers folks away from it. Of the per-OS download >> pages, only the Windows version even mentions it. >> >> Does this mean that we don't want to consider continuing with it? It is a >> lot of community effort to put out a Platform release - we shouldn't do it >> if we don't really want it. >> >> That said, I note that the other ways to "officially get" Haskell look, to >> my eye, very ad hoc. Many of the options involve multiple steps, and >> exactly what one is getting isn't clear. It hardly looks like there is now >> an "official, correct" way to setup Haskell. >> >> The Platform arose in an era before sandboxes and before curated library >> sets like Stackage and LTS. Last time we set direction was several years >> ago. These new features and development have clearly changed the landscape >> for use to reconsider what to do. >> >> >> I don't think the status quo for the Platform is now viable - mostly as >> evidenced by waning interest in maintaining it. I offer several ways we >> could proceed: >> >> *1) Abandon the Platform.* GHC is release in source and binary form. Other >> package various installers, with more or less things, for various OSes. >> >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of >> "essential" libs + tools. Keeps a consistent build layout and installation >> mechanism for Haskell. >> >> *3) Re-conceive the Platform.* Take a very minimal install approach, >> coupled with close integration with a curated library set that makes it >> easy to have a rich canonical, stable environment. This was the core idea >> around my "GPS Haskell" thoughts from last September - but there would be >> much to work out in this direction. >> >> Thoughts? > > > Thanks a lot for your hard work on the platform! > > I myself am an avid user of the platform (OS X), because for me, it's the > easiest way to install Haskell on a new machine; I just did so the other > day. > > The only time when the platform seems to be a handicap is when a new version > of GHC is being released and I would have to update my packages. Usually, I > don't test them with the new version and rely on pull requests instead. > > > Best regards, > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.com > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From benno.fuenfstueck at gmail.com Sun Mar 22 09:43:15 2015 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Sun, 22 Mar 2015 09:43:15 +0000 Subject: wither the Platform References: Message-ID: I'd like the haskell platform to include all of LTS haskell. That includes a very broad set of packages so you don't need to install many other packages even as an advanced user. Maybe there could also be a nightly release which includes stackage instead? It would save a lot of time even for experienced users, since they get stackage precompiled. However, such a distribution should be designed such that cabal install just works, so it should probably be based on winghc on Windows. The only problem I can see with this is the size of such a package, not sure if it would be acceptable? Neil Mitchell schrieb am So., 22. M?r. 2015 10:18: > On Windows, the reason I used to use the Platform was that it came > with an installed network library, and installing the network library > on Windows is a real pain (and often fails). Unfortunately it was > incredibly brittle, a single attempt at upgrading network from some > newer package usually trashed my Haskell install and required a wipe > and restart. > > Nowadays I use https://github.com/fpco/minghc which can actually > install network, and I've had zero problems. I can get up to the > platform with one invoke of cabal, and if someone decides to require a > new network, it just works. > > I think the Platform now gives a worse user experience on Windows, so > the ideas (or names) probably need migrating around. > > Thanks, Neil > > > On Sun, Mar 22, 2015 at 8:47 AM, Heinrich Apfelmus > wrote: > > Mark Lentczner wrote: > >> > >> I'm wondering how we are all feeling about the platform these days.... > >> > >> I notice that in the new Haskell pages, the Platform is definitely not > the > >> recommended way to go: The main download pages suggests the compiler and > >> base libraries as the first option - and the text for the Platform > (second > >> option) pretty much steers folks away from it. Of the per-OS download > >> pages, only the Windows version even mentions it. > >> > >> Does this mean that we don't want to consider continuing with it? It is > a > >> lot of community effort to put out a Platform release - we shouldn't do > it > >> if we don't really want it. > >> > >> That said, I note that the other ways to "officially get" Haskell look, > to > >> my eye, very ad hoc. Many of the options involve multiple steps, and > >> exactly what one is getting isn't clear. It hardly looks like there is > now > >> an "official, correct" way to setup Haskell. > >> > >> The Platform arose in an era before sandboxes and before curated library > >> sets like Stackage and LTS. Last time we set direction was several years > >> ago. These new features and development have clearly changed the > landscape > >> for use to reconsider what to do. > >> > >> > >> I don't think the status quo for the Platform is now viable - mostly as > >> evidenced by waning interest in maintaining it. I offer several ways we > >> could proceed: > >> > >> *1) Abandon the Platform.* GHC is release in source and binary form. > Other > >> package various installers, with more or less things, for various OSes. > >> > >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > >> "essential" libs + tools. Keeps a consistent build layout and > installation > >> mechanism for Haskell. > >> > >> *3) Re-conceive the Platform.* Take a very minimal install approach, > >> coupled with close integration with a curated library set that makes it > >> easy to have a rich canonical, stable environment. This was the core > idea > >> around my "GPS Haskell" thoughts from last September - but there would > be > >> much to work out in this direction. > >> > >> Thoughts? > > > > > > Thanks a lot for your hard work on the platform! > > > > I myself am an avid user of the platform (OS X), because for me, it's the > > easiest way to install Haskell on a new machine; I just did so the other > > day. > > > > The only time when the platform seems to be a handicap is when a new > version > > of GHC is being released and I would have to update my packages. > Usually, I > > don't test them with the new version and rely on pull requests instead. > > > > > > Best regards, > > Heinrich Apfelmus > > > > -- > > http://apfelmus.nfshost.com > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Sun Mar 22 09:52:28 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 22 Mar 2015 10:52:28 +0100 Subject: wither the Platform In-Reply-To: (Mark Lentczner's message of "Sat, 21 Mar 2015 10:54:26 -0700") References: Message-ID: <87h9tdpder.fsf@gnu.org> On 2015-03-21 at 18:54:26 +0100, Mark Lentczner wrote: [...] > The Platform arose in an era before sandboxes and before curated library > sets like Stackage and LTS. Last time we set direction was several years > ago. These new features and development have clearly changed the landscape > for use to reconsider what to do. [...] > Thoughts? My biggest complaint about the current HP is that it pollutes the global package database with additional packages which leak into `cabal sandbox`es. This causes `cabal sandbox` to provide quite different sandbox environments for HP environments compared to a non-HP environment without those additional packages pre-installed. Currently GHC/Cabal knows about a global package db and a user package db (the user pkg db is is what gets replaced/shadowed by cabal sandboxes). Maybe we need a 3rd package db sitting between the global and the user package db that interacts better with cabal sandboxes? Cheers, hvr From roma at ro-che.info Sun Mar 22 10:00:43 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 22 Mar 2015 12:00:43 +0200 Subject: wither the Platform In-Reply-To: <87h9tdpder.fsf@gnu.org> References: <87h9tdpder.fsf@gnu.org> Message-ID: <550E92CB.2020205@ro-che.info> I also thought about it recently. IIRC ghc can already deal with any number of stacked package dbs; we only need to expose this somehow through cabal. On 22/03/15 11:52, Herbert Valerio Riedel wrote: > On 2015-03-21 at 18:54:26 +0100, Mark Lentczner wrote: > > [...] > >> The Platform arose in an era before sandboxes and before curated library >> sets like Stackage and LTS. Last time we set direction was several years >> ago. These new features and development have clearly changed the landscape >> for use to reconsider what to do. > > [...] > >> Thoughts? > > My biggest complaint about the current HP is that it pollutes the global > package database with additional packages which leak into `cabal > sandbox`es. This causes `cabal sandbox` to provide quite different > sandbox environments for HP environments compared to a non-HP > environment without those additional packages pre-installed. > > Currently GHC/Cabal knows about a global package db and a user package > db (the user pkg db is is what gets replaced/shadowed by cabal > sandboxes). Maybe we need a 3rd package db sitting between the global > and the user package db that interacts better with cabal sandboxes? > > Cheers, > hvr > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From hesselink at gmail.com Sun Mar 22 10:17:21 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Sun, 22 Mar 2015 11:17:21 +0100 Subject: wither the Platform In-Reply-To: References: Message-ID: On Sun, Mar 22, 2015 at 10:17 AM, Neil Mitchell wrote: > On Windows, the reason I used to use the Platform was that it came > with an installed network library, and installing the network library > on Windows is a real pain (and often fails). Unfortunately it was > incredibly brittle, a single attempt at upgrading network from some > newer package usually trashed my Haskell install and required a wipe > and restart. Slightly OT: If you ever want to prevent cabal from trying to install a different version of a package (since you know it won't work, or will break things) you can put something like this in your cabal config: constraint: network installed I do this for template-haskell, since it's not possible to reinstall but cabal would occasionally try it. I can imagine it would work well to prevent the scenario you describe with network. Erik From hvr at gnu.org Sun Mar 22 10:24:00 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 22 Mar 2015 11:24:00 +0100 Subject: wither the Platform In-Reply-To: (Erik Hesselink's message of "Sun, 22 Mar 2015 11:17:21 +0100") References: Message-ID: <87d241pby7.fsf@gnu.org> On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote: [...] > I do this for template-haskell, since it's not possible to reinstall > but cabal would occasionally try it. I can imagine it would work well > to prevent the scenario you describe with network. Why isn't it possible to reinstall TH (unless you also need to depend on the `ghc` package)? We even explicitly allowed template-haskell to be reinstallable again in Cabal as there didn't seem any reason to forbid it anymore (it's no different than e.g. `bytestring` which is reinstallable as well): https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f739150 Cheers, hvr From hesselink at gmail.com Sun Mar 22 10:48:40 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Sun, 22 Mar 2015 11:48:40 +0100 Subject: wither the Platform In-Reply-To: <87d241pby7.fsf@gnu.org> References: <87d241pby7.fsf@gnu.org> Message-ID: On Sun, Mar 22, 2015 at 11:24 AM, Herbert Valerio Riedel wrote: > On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote: > > [...] > >> I do this for template-haskell, since it's not possible to reinstall >> but cabal would occasionally try it. I can imagine it would work well >> to prevent the scenario you describe with network. > > Why isn't it possible to reinstall TH (unless you also need to depend on > the `ghc` package)? We even explicitly allowed template-haskell to be > reinstallable again in Cabal as there didn't seem any reason to forbid > it anymore (it's no different than e.g. `bytestring` which is > reinstallable as well): > > https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f739150 This was based on my experiences from some time ago. Looking at it now, I think it was just that the dependencies for template-haskell were too loose, i.e. it allowed different major versions of base. When a new version of GHC was released and I was trying it out, it would always try to install the older version, and this never worked. Now that you fixed these constraints (thanks!) it seems you can reinstall, as long as it's the same (major) version. It still prints this ominous warning even in a sandbox: Warning: The following packages are likely to be broken by the reinstalls: ghc-7.8.3 But everything seems to be fine when passing --force. So I guess I can remove the constraint... Erik From ekmett at gmail.com Sun Mar 22 13:06:07 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 22 Mar 2015 09:06:07 -0400 Subject: wither the Platform In-Reply-To: <87d241pby7.fsf@gnu.org> References: <87d241pby7.fsf@gnu.org> Message-ID: The original reason for the cabal hack that prevented it from trying to reinstall template-haskell is that almost every time someone did this it broke, silently. Then five packages later something would use template haskell, and you'd get completely nonsensical error messages, and someone _else_ would get the bug report. Sure there might have been a scenario in which an expert who is working on ghc may want to reinstall the template-haskell to get a new point release, but TH has never worked across multiple GHC versions, and old versions shipped with very wide bounds. Now, of course, maintainers and the trustees have the ability to retroactively narrow bounds (and you've already done so for template-haskell), so this view is dated. template-haskell should just be reinstallable like everything else now. -Edward On Sun, Mar 22, 2015 at 6:24 AM, Herbert Valerio Riedel wrote: > On 2015-03-22 at 11:17:21 +0100, Erik Hesselink wrote: > > [...] > > > I do this for template-haskell, since it's not possible to reinstall > > but cabal would occasionally try it. I can imagine it would work well > > to prevent the scenario you describe with network. > > Why isn't it possible to reinstall TH (unless you also need to depend on > the `ghc` package)? We even explicitly allowed template-haskell to be > reinstallable again in Cabal as there didn't seem any reason to forbid > it anymore (it's no different than e.g. `bytestring` which is > reinstallable as well): > > > https://github.com/haskell/cabal/commit/ffd67e5e630766906e6f4c6655c067a79f739150 > > Cheers, > hvr > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Sun Mar 22 13:53:48 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Sun, 22 Mar 2015 08:53:48 -0500 Subject: wither the Platform In-Reply-To: References: Message-ID: On 21/03/2015, Mark Lentczner wrote: > I'm wondering how we are all feeling about the platform these days.... I say leave it to the operating system distributions. From gale at sefer.org Sun Mar 22 14:23:23 2015 From: gale at sefer.org (Yitzchak Gale) Date: Sun, 22 Mar 2015 16:23:23 +0200 Subject: wither the Platform In-Reply-To: References: Message-ID: Mark Lentczner wrote: > 1) Abandon the Platform? > > 2) Slim the Platform. Pare it back to GHC + base + a smaller set of > "essential" libs + tools. Keeps a consistent build layout and installation > mechanism for Haskell. > > 3) Re-conceive the Platform. Take a very minimal install approach, coupled > with close integration with a curated library set that makes it easy to have > a rich canonical, stable environment. This was the core idea around my "GPS > Haskell" thoughts from last September - but there would be much to work out > in this direction. I vote for (3) but in a way that it would *not* be much work. We should definitely do the Platform, but with much *less* work. The most important reason we need the Platform is as a default selection of quality basic libraries. We should not abandon that concept. Curated package sets do not replace that - the Platform is not just packages that build together. Nor do OS packagers. The platform is a community-wide set of basic default packages that are mature, well tested, all work together well, and stable. The second most important role of the Platform is a web site where you can get a clear picture of how to download and install a default Haskell installation for your platform, and a simple view of where we are in the parade of releases. That should also continue. The hardest work of the Platform was its role as a way to bootstrap a Haskell installation. That is what made it so hard for HP to keep up with GHC releases, and what consequently gave people the impression that HP is always old. That work doesn't need to be done as part of the Platform anymore. We should leverage other good work people are doing to create installers, and stop doing it as part of the HP process. The most important part of an HP release should be a cabal package that provides the packages in the platform, at the right versions, with a specification of the recommended GHC version as a pre-requisite. Perhaps we can also provide an HP-branded slick installer for some platforms that does everything in one click, built as a thin wrapper of some existing installer. But that should not delay the official release of an HP version. It's just a nice-to-have extra. Once we pare down the work needed for an HP release, we should release new versions of HP quite often - *more* often than GHC releases, not less often. Another thing we should fix is the (now false) impression that HP gets in the way of installing other packages and versions due to cabal hell. We should make "require-sandbox" the default setting in the cabal config file. I would go further - I would add a cabal feature to create a sandbox automatically unless "--user" or "--global" is specified explicitly. I would make "foo installed" a default constraint (that is easy to override) for all platform packages, which solves virtually all cabal hell problems (assuming you are using a sandbox) and will not keep things old if we release often. Thanks, Yitz From michael at snoyman.com Sun Mar 22 15:59:35 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sun, 22 Mar 2015 15:59:35 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: It should go without saying that the first sentiment we all likely have is gratitude for all the work Mark has put into the platform, as well as all of the other contributors and maintainers the platform has had over the years. It hasn't just been work on producing the platform itself, but also for setting up an expectation in the Haskell world for high quality, reliable libraries. Even if the current incarnation of the platform is in jeopardy, I hope that we continue with that attitude going forward. I spend a lot of time working on Stackage, and obviously there's quite a bit of overlap between Stackage, Haskell Platform, and LTS Haskell. For purposes of this discussion, I think it's important to separate out different features of the platform, and see how we may continue or discontinue each individually: 1. A quality-approved set of libraries. As I see it, the process of coming up with recommended libraries can continue completely independently of any other work. 2. A method for installing GHC and build tools. I personally think that it makes sense to separate out this aspect of the platform from all others. MinGHC is an example of such a project: a minimal set of functionality for bootstrapping a more complete Haskell development environment. 3. Prebuilt binary package databases. As I've mentioned in the past, and others have here, there are problems with the current approach of putting the packages in the global package database. I'd personally rather see this aspect of the platform give way to more robust solutions. And as we've already discussed in the past regarding GPS, there's definitely room to add *more* to the platform with better build dependency solving. LTS Haskell was specifically an effort to try to advance that aspect of GPS. Putting this together, I think it leads to a new approach for the platform: minimalistic installers, curated package sets (ala LTS), recommended packages (ala the current platform set), and a robust means for installing these (e.g., cabal sandboxes). The Haskell world has advanced since the initial HP work, maybe all that's needed now is upgrading to the newest tooling available. I realize I haven't put down any concrete "next steps" here. I definitely have more ideas than I could put into this (already quite long) email. I think a smaller task force dedicated to improving the tooling situation is the best next step, and I'd be happy to kick off such an effort with other interested individuals. On Sat, Mar 21, 2015 at 7:54 PM Mark Lentczner wrote: > I'm wondering how we are all feeling about the platform these days.... > > I notice that in the new Haskell pages, the Platform is definitely not the > recommended way to go: The main download pages suggests the compiler and > base libraries as the first option - and the text for the Platform (second > option) pretty much steers folks away from it. Of the per-OS download > pages, only the Windows version even mentions it. > > Does this mean that we don't want to consider continuing with it? It is a > lot of community effort to put out a Platform release - we shouldn't do it > if we don't really want it. > > That said, I note that the other ways to "officially get" Haskell look, to > my eye, very ad hoc. Many of the options involve multiple steps, and > exactly what one is getting isn't clear. It hardly looks like there is now > an "official, correct" way to setup Haskell. > > The Platform arose in an era before sandboxes and before curated library > sets like Stackage and LTS. Last time we set direction was several years > ago. These new features and development have clearly changed the landscape > for use to reconsider what to do. > > > I don't think the status quo for the Platform is now viable - mostly as > evidenced by waning interest in maintaining it. I offer several ways we > could proceed: > > *1) Abandon the Platform.* GHC is release in source and binary form. > Other package various installers, with more or less things, for various > OSes. > > *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > "essential" libs + tools. Keeps a consistent build layout and installation > mechanism for Haskell. > > *3) Re-conceive the Platform.* Take a very minimal install approach, > coupled with close integration with a curated library set that makes it > easy to have a rich canonical, stable environment. This was the core idea > around my "GPS Haskell" thoughts from last September - but there would be > much to work out in this direction. > > Thoughts? > > ? Mark > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Mar 22 16:08:31 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 22 Mar 2015 17:08:31 +0100 Subject: wither the Platform In-Reply-To: <87h9tdpder.fsf@gnu.org> References: <87h9tdpder.fsf@gnu.org> Message-ID: <1427040511.2205.4.camel@joachim-breitner.de> Hi, Am Sonntag, den 22.03.2015, 10:52 +0100 schrieb Herbert Valerio Riedel: > Currently GHC/Cabal knows about a global package db and a user package > db (the user pkg db is is what gets replaced/shadowed by cabal > sandboxes). Maybe we need a 3rd package db sitting between the global > and the user package db that interacts better with cabal sandboxes? this would also be great for distributions, which also provide packages that should not (necessarily) in sandboxes, but are installed system wide. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gershomb at gmail.com Sun Mar 22 17:24:55 2015 From: gershomb at gmail.com (Gershom B) Date: Sun, 22 Mar 2015 13:24:55 -0400 Subject: [haskell-infrastructure] wither the Platform Message-ID: Thanks for kicking this off Mark. Here is what I think happened. We fragmented along two lines. A) Users that sandbox and users that do not. B) Libraries that maintain HP compatibility and libraries that do not. The growth of non HP-compat libs is clearly what has driven the growth in sandboxing users. That brings us to the current situation where new users who install the platform then run into the issue hvr describes ? platform-installed packages being available in sandboxes and causing trouble. However, the current solution we push to new users is lacking in certain ways. In particular, I really don?t like not providing standard binary/installers from a _single source_ across all platforms. Instead, we have installers from three sources, with the minimal windows and mac ones being from small strikeforces or individuals, but not necessarily a team where everything is documented so others can step in if someone decides to go off and surf for the rest of their life in an area with poor wi-fi, etc. Furthermore, it is _very_ important to have some community process to ?bless? or suggest some set of packages from the zoo of hackage as the ?typical? way to accomplish certain tasks, and I think we have been overly conservative in adding packages to the platform, probably due to the problem of pulling in unrelated dependencies, etc. This blessed set serves, among other things, as a core set of packages to advise distro managers on the baseline they should package, etc. Finally, while sandboxes seem necessary, sandboxes are a _hack_ and it would be good to provide a way for users to maintain a local db that they like and trust of a set of baseline libs while making it _easy_ to override these in individual sandboxes. Overall I tend to agree with dons? comments on the reddit thread (http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmy54n) and think the key idea is to preserve _both_ the ?one stop installer? aspect of the platform and the ?blessed package set? element, but to decouple them from one another. This leads to the following proposals: 1) Reboot the HP installers for windows and mac as effectively the MinGHC and GHC For Mac OS X, working with those teams but centralizing the build/packaging knowledge and provide them all from one place. 2) For generic linux point to both ghc and cabal binaries from the core teams. 3) Continue to pick out and list a compatible, ?blessed? set of libraries under the platform umbrella, but do not necessarily package them with installers. Reboot interest in expanding and curating further the list of libraries across a wider range of application domains. 4) Improve sandbox tooling so that it is easy to exclude packages from the main database when building within sandboxes. And of these I have one outstanding question ? while MinGHC makes it easy to install network directly on windows machines, what does it do about the GL libraries? Or for getting a windows GHC with graphics, does the current platform build remain a better solution? If we can?t solve that, then the MinGHC approach doesn?t yet provide a strictly better solution. Cheers, Gershom On March 22, 2015 at 10:24:09 AM, Yitzchak Gale (gale at sefer.org) wrote: > Mark Lentczner wrote: > > 1) Abandon the Platform? > > > > 2) Slim the Platform. Pare it back to GHC + base + a smaller set of > > "essential" libs + tools. Keeps a consistent build layout and installation > > mechanism for Haskell. > > > > 3) Re-conceive the Platform. Take a very minimal install approach, coupled > > with close integration with a curated library set that makes it easy to have > > a rich canonical, stable environment. This was the core idea around my "GPS > > Haskell" thoughts from last September - but there would be much to work out > > in this direction. > > I vote for (3) but in a way that it would *not* be much work. > We should definitely do the Platform, but with much *less* work. > > The most important reason we need the Platform is as > a default selection of quality basic libraries. We should not abandon > that concept. Curated package sets do not replace that - the > Platform is not just packages that build together. Nor do OS > packagers. The platform is a community-wide set of basic default > packages that are mature, well tested, all work together well, > and stable. > > The second most important role of the Platform is a web site > where you can get a clear picture of how to download and install > a default Haskell installation for your platform, and a simple view > of where we are in the parade of releases. That should also continue. > > The hardest work of the Platform was its role as a way to bootstrap a > Haskell installation. That is what made it so hard for HP to keep up > with GHC releases, and what consequently gave people the impression > that HP is always old. That work doesn't need to be done as part of the > Platform anymore. We should leverage other good work people are > doing to create installers, and stop doing it as part of the HP process. > > The most important part of an HP release should be a cabal package > that provides the packages in the platform, at the right versions, with > a specification of the recommended GHC version as a pre-requisite. > > Perhaps we can also provide an HP-branded slick installer for some > platforms that does everything in one click, built as a thin wrapper of > some existing installer. But that should not delay the official release > of an HP version. It's just a nice-to-have extra. > > Once we pare down the work needed for an HP release, we should > release new versions of HP quite often - *more* often than GHC > releases, not less often. > > Another thing we should fix is the (now false) impression that HP > gets in the way of installing other packages and versions due to > cabal hell. We should make "require-sandbox" the default setting > in the cabal config file. I would go further - I would add a cabal > feature to create a sandbox automatically unless "--user" or > "--global" is specified explicitly. I would make "foo installed" a > default constraint (that is easy to override) for all platform packages, > which solves virtually all cabal hell problems (assuming you are > using a sandbox) and will not keep things old if we release often. > > Thanks, > Yitz > _______________________________________________ > haskell-infrastructure mailing list > haskell-infrastructure at community.galois.com > http://community.galois.com/mailman/listinfo/haskell-infrastructure > From mhoermann at gmail.com Sun Mar 22 17:33:42 2015 From: mhoermann at gmail.com (=?UTF-8?Q?Matthias_H=C3=B6rmann?=) Date: Sun, 22 Mar 2015 18:33:42 +0100 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: References: Message-ID: The sandboxes vs. non-sandboxed install issues are closely related to the whole issue of not being able to easily update a package once it is installed. Perhaps some effort should be invested in solving that problem instead as it seems to be the core cause for the reinstallations which are so much harder for global packages than for sandboxes. On 22 Mar 2015 18:25, "Gershom B" wrote: > Thanks for kicking this off Mark. Here is what I think happened. We > fragmented along two lines. > > A) Users that sandbox and users that do not. > B) Libraries that maintain HP compatibility and libraries that do not. > > The growth of non HP-compat libs is clearly what has driven the growth in > sandboxing users. That brings us to the current situation where new users > who install the platform then run into the issue hvr describes ? > platform-installed packages being available in sandboxes and causing > trouble. > > However, the current solution we push to new users is lacking in certain > ways. In particular, I really don?t like not providing standard > binary/installers from a _single source_ across all platforms. Instead, we > have installers from three sources, with the minimal windows and mac ones > being from small strikeforces or individuals, but not necessarily a team > where everything is documented so others can step in if someone decides to > go off and surf for the rest of their life in an area with poor wi-fi, etc. > > Furthermore, it is _very_ important to have some community process to > ?bless? or suggest some set of packages from the zoo of hackage as the > ?typical? way to accomplish certain tasks, and I think we have been overly > conservative in adding packages to the platform, probably due to the > problem of pulling in unrelated dependencies, etc. This blessed set serves, > among other things, as a core set of packages to advise distro managers on > the baseline they should package, etc. > > Finally, while sandboxes seem necessary, sandboxes are a _hack_ and it > would be good to provide a way for users to maintain a local db that they > like and trust of a set of baseline libs while making it _easy_ to override > these in individual sandboxes. > > Overall I tend to agree with dons? comments on the reddit thread ( > http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmy54n) > and think the key idea is to preserve _both_ the ?one stop installer? > aspect of the platform and the ?blessed package set? element, but to > decouple them from one another. > > This leads to the following proposals: > > 1) Reboot the HP installers for windows and mac as effectively the MinGHC > and GHC For Mac OS X, working with those teams but centralizing the > build/packaging knowledge and provide them all from one place. > 2) For generic linux point to both ghc and cabal binaries from the core > teams. > 3) Continue to pick out and list a compatible, ?blessed? set of libraries > under the platform umbrella, but do not necessarily package them with > installers. Reboot interest in expanding and curating further the list of > libraries across a wider range of application domains. > 4) Improve sandbox tooling so that it is easy to exclude packages from the > main database when building within sandboxes. > > And of these I have one outstanding question ? while MinGHC makes it easy > to install network directly on windows machines, what does it do about the > GL libraries? Or for getting a windows GHC with graphics, does the current > platform build remain a better solution? If we can?t solve that, then the > MinGHC approach doesn?t yet provide a strictly better solution. > > Cheers, > Gershom > > On March 22, 2015 at 10:24:09 AM, Yitzchak Gale (gale at sefer.org) wrote: > > Mark Lentczner wrote: > > > 1) Abandon the Platform? > > > > > > 2) Slim the Platform. Pare it back to GHC + base + a smaller set of > > > "essential" libs + tools. Keeps a consistent build layout and > installation > > > mechanism for Haskell. > > > > > > 3) Re-conceive the Platform. Take a very minimal install approach, > coupled > > > with close integration with a curated library set that makes it easy > to have > > > a rich canonical, stable environment. This was the core idea around my > "GPS > > > Haskell" thoughts from last September - but there would be much to > work out > > > in this direction. > > > > I vote for (3) but in a way that it would *not* be much work. > > We should definitely do the Platform, but with much *less* work. > > > > The most important reason we need the Platform is as > > a default selection of quality basic libraries. We should not abandon > > that concept. Curated package sets do not replace that - the > > Platform is not just packages that build together. Nor do OS > > packagers. The platform is a community-wide set of basic default > > packages that are mature, well tested, all work together well, > > and stable. > > > > The second most important role of the Platform is a web site > > where you can get a clear picture of how to download and install > > a default Haskell installation for your platform, and a simple view > > of where we are in the parade of releases. That should also continue. > > > > The hardest work of the Platform was its role as a way to bootstrap a > > Haskell installation. That is what made it so hard for HP to keep up > > with GHC releases, and what consequently gave people the impression > > that HP is always old. That work doesn't need to be done as part of the > > Platform anymore. We should leverage other good work people are > > doing to create installers, and stop doing it as part of the HP process. > > > > The most important part of an HP release should be a cabal package > > that provides the packages in the platform, at the right versions, with > > a specification of the recommended GHC version as a pre-requisite. > > > > Perhaps we can also provide an HP-branded slick installer for some > > platforms that does everything in one click, built as a thin wrapper of > > some existing installer. But that should not delay the official release > > of an HP version. It's just a nice-to-have extra. > > > > Once we pare down the work needed for an HP release, we should > > release new versions of HP quite often - *more* often than GHC > > releases, not less often. > > > > Another thing we should fix is the (now false) impression that HP > > gets in the way of installing other packages and versions due to > > cabal hell. We should make "require-sandbox" the default setting > > in the cabal config file. I would go further - I would add a cabal > > feature to create a sandbox automatically unless "--user" or > > "--global" is specified explicitly. I would make "foo installed" a > > default constraint (that is easy to override) for all platform packages, > > which solves virtually all cabal hell problems (assuming you are > > using a sandbox) and will not keep things old if we release often. > > > > Thanks, > > Yitz > > _______________________________________________ > > haskell-infrastructure mailing list > > haskell-infrastructure at community.galois.com > > http://community.galois.com/mailman/listinfo/haskell-infrastructure > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Mar 22 19:40:56 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 22 Mar 2015 15:40:56 -0400 Subject: fast test suite failures on OS X with 7.10 RC head Message-ID: hey all heres the results from the test suite run on a build of 7.10 head on OS X i believe that some of the test suite failures are because I set the min OS X version to 10.6 rather than 10.7, and that some are because GCC (unlike clang) doesn't support certain OS X specific things like objective C or related header files. I'll add more information as I have the time, but figured I should share this for now Unexpected results from: TEST="T10019 sigcabal01 objc-hi objcpp-hi retc001 linker_unload debug T2276_ghci T9203 T1969 T9675 T783 T5642 T6048" OVERALL SUMMARY for test run started at Sun Mar 22 14:58:07 2015 EDT 0:31:34 spent to go through 4405 total tests, which gave rise to 18027 test cases, of which 13966 were skipped 52 had missing libraries 3950 expected passes 45 expected failures 0 caused framework failures 0 unexpected passes 8 unexpected failures 6 unexpected stat failures Unexpected failures: cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_compile debug [bad stderr] (normal) driver/objc objc-hi [exit code non-0] (normal) driver/objc objcpp-hi [exit code non-0] (normal) driver/retc001 retc001 [bad stderr] (normal) ffi/should_run T2276_ghci [bad exit code] (ghci) rts linker_unload [bad exit code] (normal) th T10019 [bad stdout] (ghci) Unexpected stat failures: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9675 [stat not good enough] (optasm) perf/should_run T9203 [stat too good] (normal) ~/D/r/g/testsuite (ghc-7.10|?) $ echo $MACOSX_DEPLOYMENT_TARGET 10.6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Sun Mar 22 20:24:19 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Sun, 22 Mar 2015 21:24:19 +0100 Subject: fast test suite failures on OS X with 7.10 RC head In-Reply-To: References: Message-ID: Maybe it's time for a Mac OS X taskforce? All these unexpected test failures on OS X (see also https://ghc.haskell.org/trac/ghc/ticket/9389), and OS X specific tickets in general, could get some more attention: https://ghc.haskell.org/trac/ghc/query?status=!closed&os=MacOS+X -Thomas (who, like most ghc developers it seems, doesn't work on a Mac) On Sun, Mar 22, 2015 at 8:40 PM, Carter Schonwald wrote: > hey all > > heres the results from the test suite run on a build of 7.10 head on OS X > > i believe that some of the test suite failures are because I set the min OS > X version to 10.6 rather than 10.7, and that some are because GCC (unlike > clang) doesn't support certain OS X specific things like objective C or > related header files. I'll add more information as I have the time, but > figured I should share this for now > > Unexpected results from: > TEST="T10019 sigcabal01 objc-hi objcpp-hi retc001 linker_unload debug > T2276_ghci T9203 T1969 T9675 T783 T5642 T6048" > > OVERALL SUMMARY for test run started at Sun Mar 22 14:58:07 2015 EDT > 0:31:34 spent to go through > 4405 total tests, which gave rise to > 18027 test cases, of which > 13966 were skipped > > 52 had missing libraries > 3950 expected passes > 45 expected failures > > 0 caused framework failures > 0 unexpected passes > 8 unexpected failures > 6 unexpected stat failures > > Unexpected failures: > cabal/sigcabal01 sigcabal01 [bad stderr] (normal) > codeGen/should_compile debug [bad stderr] (normal) > driver/objc objc-hi [exit code non-0] (normal) > driver/objc objcpp-hi [exit code non-0] (normal) > driver/retc001 retc001 [bad stderr] (normal) > ffi/should_run T2276_ghci [bad exit code] (ghci) > rts linker_unload [bad exit code] (normal) > th T10019 [bad stdout] (ghci) > > Unexpected stat failures: > perf/compiler T1969 [stat not good enough] (normal) > perf/compiler T5642 [stat not good enough] (normal) > perf/compiler T6048 [stat not good enough] (optasm) > perf/compiler T783 [stat not good enough] (normal) > perf/compiler T9675 [stat not good enough] (optasm) > perf/should_run T9203 [stat too good] (normal) > > ~/D/r/g/testsuite (ghc-7.10|?) $ echo $MACOSX_DEPLOYMENT_TARGET > 10.6 > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From eir at cis.upenn.edu Mon Mar 23 01:35:45 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 22 Mar 2015 21:35:45 -0400 Subject: wither the Platform In-Reply-To: <1427040511.2205.4.camel@joachim-breitner.de> References: <87h9tdpder.fsf@gnu.org> <1427040511.2205.4.camel@joachim-breitner.de> Message-ID: I have to say that I'm quite surprised this conversation is happening at all. As far as I knew before doing some research in advance of this post, the Haskell Platform is *the* way to install Haskell on a fresh machine. It's certainly what I've relied on in getting Haskell on my machines (both MacOS 10.8). While I personally don't feel the need for the HP to have some curated set of libraries (especially now that there are other curated sets available), I do feel a strong need to have it be nice, shiny, and easy to install. At least for Mac, I don't know of a suitable replacement. I feel like we, as a community, ask a tremendous amount from our users.* By eliminating the HP, we'll be asking more from users before they're even a proper part of community. This seems like a step in the wrong direction, to me. Richard * Here are a few ways in which we ask a ton from users: - Users have to figure out which libraries to use. Many basic tasks (e.g. parsing, regular expressions) have competing packages, and it's hard to know which is appropriate. - Users have to deal with a very intricate type system. Basic libraries (like the new Prelude, `vector`, `lens`) use this complexity to their advantage, but perhaps to newcomers' disadvantage. (I'm well aware I'm, in some degree, to blame here!) - Users have to deal with long, intricate error messages. This comes hand-in-hand with the previous point. We GHC hackers try our best, but I know we fall short of the mark here. - Once a year, when the new GHC comes out, everything breaks. - Cabal hell. In return, the community gives and gives and is ever patient with newcomers. This is wonderful, and I attribute Haskell's growth to the friendliness of the community. But we should be aware of just how steep the curve is. On Mar 22, 2015, at 12:08 PM, Joachim Breitner wrote: > Hi, > > > Am Sonntag, den 22.03.2015, 10:52 +0100 schrieb Herbert Valerio Riedel: >> Currently GHC/Cabal knows about a global package db and a user package >> db (the user pkg db is is what gets replaced/shadowed by cabal >> sandboxes). Maybe we need a 3rd package db sitting between the global >> and the user package db that interacts better with cabal sandboxes? > > this would also be great for distributions, which also provide packages > that should not (necessarily) in sandboxes, but are installed system > wide. > > Greetings, > Joachim > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From allbery.b at gmail.com Mon Mar 23 01:40:31 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 22 Mar 2015 21:40:31 -0400 Subject: wither the Platform In-Reply-To: References: <87h9tdpder.fsf@gnu.org> <1427040511.2205.4.camel@joachim-breitner.de> Message-ID: On Sun, Mar 22, 2015 at 9:35 PM, Richard Eisenberg wrote: > I have to say that I'm quite surprised this conversation is happening at > all. As far as I knew before doing some research in advance of this post, > the Haskell Platform is *the* way to install Haskell on a fresh machine. > It's certainly what I've relied on in getting Haskell on my machines (both > MacOS 10.8). While I personally don't feel the need for the HP to have some > curated set of libraries (especially now that there are other curated sets > available), I do feel a strong need to have it be nice, shiny, and easy to > install. At least for Mac, I don't know of a suitable replacement. > That's interesting, because http://ghcformacosx.github.io is pretty much the only thing anyone recommends to Mac users any more, and in #haskell people seem to actively steer everyone away from the Platform in all its incarnations. I think the time when the Platform release got held up for over a year waiting for "important ghc fixes" pretty much killed all relevance for the Platform as it currently exists. Maybe a reformulation and relaunch will help, but from here it looks pretty doomed/dead. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Mar 23 01:55:26 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 22 Mar 2015 21:55:26 -0400 Subject: wither the Platform In-Reply-To: References: <87h9tdpder.fsf@gnu.org> <1427040511.2205.4.camel@joachim-breitner.de> Message-ID: On Mar 22, 2015, at 9:40 PM, Brandon Allbery wrote: > That's interesting, because http://ghcformacosx.github.io is pretty much the only thing anyone recommends to Mac users any more, and in #haskell people seem to actively steer everyone away from the Platform in all its incarnations. I do indeed think that this is interesting, because this thread is the first time I had ever heard of ghcformacosx. I've used Haskell on a Mac daily for several years now. I subscribe to (and read at least subject lines from) Haskell-cafe and Haskell mailing lists -- including Haskell Weekly News and HCAR -- though I'm only occasionally on reddit and very rarely look at #haskell. Besides, I run MacOS 10.8, and so ghcformacosx doesn't help me, anyway. (I installed 10.9 once upon a time. It slowed down my machine so much I preferred to reformat and roll back to 10.8, even though I was facing down a nasty deadline.) At the least, this end of the debate shows me that the community has some disagreement about what today's status quo is, an important fact to settle on before charting a course for the future. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Mar 23 03:38:45 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 22 Mar 2015 23:38:45 -0400 Subject: wither the Platform In-Reply-To: References: <87h9tdpder.fsf@gnu.org> <1427040511.2205.4.camel@joachim-breitner.de> Message-ID: richarch, you should *still* be able to use the ghc-for-osx bundle, just not launch the "help setup your path" app eg, if you donwlaod the current release from https://ghcformacosx.github.io/ and add /Applications/ghc-7.8.4.app/Contents/bin/ to your path, you should be able to use the included ghc et al on any >= 10.7 system. a simple test would be to launch ghci as follows /Applications/ghc-7.8.4.app/Contents/bin/ghci ghc for osx USES the same GHC build that OS X haskell platform uses. that said, mark HAS been the general custodian of official OS X builds because he's been the only person who seems to be able to get docbook working properly on osx On Sun, Mar 22, 2015 at 9:55 PM, Richard Eisenberg wrote: > > On Mar 22, 2015, at 9:40 PM, Brandon Allbery wrote: > > That's interesting, because http://ghcformacosx.github.io is pretty much > the only thing anyone recommends to Mac users any more, and in #haskell > people seem to actively steer everyone away from the Platform in all its > incarnations. > > > I do indeed think that this is interesting, because this thread is the > first time I had ever heard of ghcformacosx. I've used Haskell on a Mac > daily for several years now. I subscribe to (and read at least subject > lines from) Haskell-cafe and Haskell mailing lists -- including Haskell > Weekly News and HCAR -- though I'm only occasionally on reddit and very > rarely look at #haskell. Besides, I run MacOS 10.8, and so ghcformacosx > doesn't help me, anyway. (I installed 10.9 once upon a time. It slowed down > my machine so much I preferred to reformat and roll back to 10.8, even > though I was facing down a nasty deadline.) > > At the least, this end of the debate shows me that the community has some > disagreement about what today's status quo is, an important fact to settle > on before charting a course for the future. > > Richard > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acowley at gmail.com Mon Mar 23 03:42:27 2015 From: acowley at gmail.com (Anthony Cowley) Date: Sun, 22 Mar 2015 23:42:27 -0400 Subject: wither the Platform In-Reply-To: References: <87h9tdpder.fsf@gnu.org> <1427040511.2205.4.camel@joachim-breitner.de> Message-ID: I'm sure we could do better at publicity, but your email made me wonder, so the first thing I tried was a search on haskell-caf? that brings up several threads with relevant subjects that mention ghcformacosx, including an HWN. http://search.gmane.org/search.php?group=gmane.comp.lang.haskell.cafe&query=ghcformacosx I believe that you haven't heard of it, but, if somebody asks about GHC on OS X, the advice is pretty consistent. It is pretty well the single-step, OS X-focused installer people ask for. All that's missing is more unified branding across different operating systems. Anthony On Sunday, March 22, 2015, Richard Eisenberg wrote: > > On Mar 22, 2015, at 9:40 PM, Brandon Allbery > wrote: > > That's interesting, because http://ghcformacosx.github.io is pretty much > the only thing anyone recommends to Mac users any more, and in #haskell > people seem to actively steer everyone away from the Platform in all its > incarnations. > > > I do indeed think that this is interesting, because this thread is the > first time I had ever heard of ghcformacosx. I've used Haskell on a Mac > daily for several years now. I subscribe to (and read at least subject > lines from) Haskell-cafe and Haskell mailing lists -- including Haskell > Weekly News and HCAR -- though I'm only occasionally on reddit and very > rarely look at #haskell. Besides, I run MacOS 10.8, and so ghcformacosx > doesn't help me, anyway. (I installed 10.9 once upon a time. It slowed down > my machine so much I preferred to reformat and roll back to 10.8, even > though I was facing down a nasty deadline.) > > At the least, this end of the debate shows me that the community has some > disagreement about what today's status quo is, an important fact to settle > on before charting a course for the future. > > Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 23 05:13:13 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 22 Mar 2015 22:13:13 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 Message-ID: I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 using GHC 7.10 RC3. I bumped all the GHC libs to the versions in 7.10, and bumped all the Platform libs to the latest versions I could find on Hackage. There were a few issues: - *old-locale and old-time* - no longer part of GHC, but cabal-install, cgi & HTTP need them - and they are part of the platform - so included now as added packages. Not sure this is a great idea, since they are now very deprecated... but until cabal-install, cgi, & HTTP update, not sure what else to do. - *tf-random* - is now required by alex and QuickCheck - seems a shame to add this, as now we're going to have two random packages - *network-uri *- was split out of network, and needed by cabal-install, cgi, & HTTP. I suppose we should include it, as it was functionality and API that was part of the platform - *exceptions* & *multipart* - needed by cgi - is exceptions now subsumed by something in transformers? and... multipart? maybe time to drop cgi? We didn't have it last time anyway as it wouldn't compile! - *scientific* - needed by attoparsec - debated in detail last time ... and we're still here! The Platform is significantly larger now: On OS X it has gone from 316M to 499M! Most of this is due to new OpenGL libs which are now huge (went from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole installed magilla is 1.5G! Even the compressed installer is now 250M! If you want to poke at it, the source is in the pre-release branch at GitHub , and the OS X builds are at my usual platform staging area: Index of /mark/platform Remember, it already includes GHC, so no need to download the GHC binary for OS X that is there, too. I'll try to get a generic linux build up soonish... but my VM now runs out of memory trying to build OpenGL - and adding more only makes my machine thrash to death! - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 23 05:44:41 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 22 Mar 2015 22:44:41 -0700 Subject: quick report using GHC 7.10 RC3 Message-ID: I built up a provisional HP 2015.2.0.0 based on GHC 7.10 RC3, and then when testing it, built my medium-ish project Plush with it all. This is my first brush with 7.10 and the new base libs, Applicative, FTP and all. For the most part, it all worked, but here are some observations: *1. Cabal-1.22.1.2 isn't on Hackage* Boot strapping HP now needs to bootstrap cabal-install in order to be able to build with 7.10. My fancy-pants build system for HP doesn't do that (yet), so I did it by hand. Only hitch: Cabal 1.22.1.2 isn't on hackage, so I had to build with 1.22.1.1 - so the bootstrap wasn't perfect, but good enough to work. *2. Still need old-local and old-time* Because....wait for it... cabal-install needs them! So do cgi and HTTP packages. *3. Slower compilation* The platform used to take about 20min. to compile. Now it takes a full hour. Did GHC really slow down that much? The newer OpenGL and OpenGLRaw packages are significantly larger and slower, and that might account for about half the extra time... but still GHC seems much slower. *4. GHC is a disk monster* Now weighing in at 900+MB! That is 100MB over 7.8! *5. Warnings Galore* Of course most of the packages compile with tons of warnings. I mean tons! Looking at my own packages, since I usually compile -Wall, I will need tons of work to remove these. The saddness is that if I want my package to continue to work on 7.8 I'll have to put in tons of CPP statements. *6. Bit by additions to the Prelude* In particular, Word, since I had a data type named that. (It was in a grammar for the shell, and since Data.Word was no where near this, I claim it was a reasonable choice of name.) I had to add tons of import Prelude hiding (Word) statements. Adding common words as new exports from the Prelude is a real pain! *7. Cabal incompatible API change* In particular, the api that a custom Setup.hs uses. Distribution.Simple.UserHooks changed the type of a hook. It should not, it should have added another to do what it wanted. The poblem is you can't use CPP in Setup.hs. And so now anyone using the testHook hook is in a pickle: Your Setup.hs can't work in both 7.10 and 7.8! *8. Haddock messaging* What has gotten into Haddock? There is so much terminal output now - I just have to ignore it all. It spews more than the compiler does. *9. Library divergence* We have random... and now we'll have to have tf-random, too, because alex and QuickCheck both need it. So now we'll have two random libraries. Couldn't we have folded tf-random into random? On a similar front, we've got attoparsec, pulling in scientific. Couldn't that have gone somewhere? I realize that the trend is for many small minimal libs... but for the core that is going to all be there always anyway - and more closed set works better I think. Summary: 1, 2 & 8 are minor, 3 & 4 are sad. 5 ~ 7 will make the job of anyone who wants their code to work with even one prior major GHC rev. hard, and ugly. 9 is what makes me worry most... ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Mon Mar 23 07:04:36 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 23 Mar 2015 08:04:36 +0100 Subject: quick report using GHC 7.10 RC3 In-Reply-To: (Mark Lentczner's message of "Sun, 22 Mar 2015 22:44:41 -0700") References: Message-ID: <87vbhsmby3.fsf@gmail.com> Hello Mark, Here's just two minor notes about the first two items: On 2015-03-23 at 06:44:41 +0100, Mark Lentczner wrote: [...] > *1. Cabal-1.22.1.2 isn't on Hackage* > Boot strapping HP now needs to bootstrap cabal-install in order to be able > to build with 7.10. My fancy-pants build system for HP doesn't do that > (yet), so I did it by hand. Only hitch: Cabal 1.22.1.2 isn't on hackage, so > I had to build with 1.22.1.1 - so the bootstrap wasn't perfect, but good > enough to work. That's because RC3 happened shortly before Cabal got properly tagged, and 1.22.1.2 was rather an internal transitional versioning to make sure RC3 clearly marked that it didn't ship with what was available on Hackage as 1.22.1.1 (fwiw, if you build with the current ghc-7.10 branch tip you'll end up with the uploaded http://hackage.haskell.org/package/Cabal-1.22.2.0 release) > *2. Still need old-local and old-time* > Because....wait for it... cabal-install needs them! So do cgi and HTTP > packages. I'm sure cabal-install can be modified to build-depend on those conditionally (via cabal conditionals)... From svenpanne at gmail.com Mon Mar 23 08:20:54 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 23 Mar 2015 09:20:54 +0100 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: 2015-03-23 6:13 GMT+01:00 Mark Lentczner : > [...] I'll try to get a generic linux build up soonish... but my VM now runs out > of memory trying to build OpenGL - and adding more only makes my machine > thrash to death! On Travis CI and the hackage build server, I have problems regarding memory, too, see e.g. https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/55308553 and http://hackage.haskell.org/package/OpenGLRaw-2.4.0.0/reports/1. Sometimes things go smoothly on Travis CI, sometimes they don't, but if things fail, it's always haddock running out of memory when generating the documentation for Graphics.Rendering.OpenGL.Raw.Functions. The resulting web page is not that small (roughly 5.5 MB), but it's not really huge, either. Travis CI VMs have 3 GB memory available IIRC, and requiring >3 GB for 5.5 MB output seems to be a bit high. Furthermore, this seems to be a regression in Haddock: The Travis CI builds for older versions always work fine. I think this needs to be fixed in Haddock... From svenpanne at gmail.com Mon Mar 23 08:35:29 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 23 Mar 2015 09:35:29 +0100 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: 2015-03-23 6:13 GMT+01:00 Mark Lentczner : > [...] exceptions & multipart - needed by cgi - is exceptions now subsumed by > something in transformers? [...] Coincidentally, Edward Kmett pointed me to the exceptions package while I was trying to generalize some of my packages from using plain IO to MonadIO. Alas, the transformers package still doesn't subsume the exceptions package, but IMHO it really should. Looking at the import list of e.g. Control.Monad.Catch alone is already indicating that. :-) BTW: System.Console.Haskeline.MonadException has something similar, but far less complete, too, but that's really a strange place for such a feature. How did it end up there? From simonpj at microsoft.com Mon Mar 23 08:45:48 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 08:45:48 +0000 Subject: Cabal and simultaneous installations of the same package Message-ID: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon From michael at snoyman.com Mon Mar 23 08:52:31 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 23 Mar 2015 08:52:31 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I'm in favor of adding support to Cabal to allow for this situation. However: I highly doubt this will be the panacea as predicted. It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString." In fact, this confusion is so prevalent that I wrote a blog post about it in September[1]. I strongly believe that the best end-user experience comes from having a single mapping from package name to actually installed package/version/dependencies. I'd go even farther and say that users would be well served by having a single mapping from module name to installed module. In fact, Adam Bergmark even created an issue[2] to look into adding support to Stackage to start enforcing this situation, though the response to a blog post I wrote on that[3] implies that people are not so interested in addressing that problem. So my word of warning here is: if we simply throw multiple package/version/dependency combinations at users via cabal, there's a good chance that we'll do more harm than good. [1] http://www.yesodweb.com/blog/2014/09/woes-multiple-package-versions [2] https://github.com/fpco/stackage/issues/416 [3] http://www.yesodweb.com/blog/2014/02/module-name-conflicts On Mon, Mar 23, 2015 at 10:45 AM Simon Peyton Jones wrote: > Dear Cabal developers > > You'll probably have seen the thread about the Haskell Platform. > > Among other things, this point arose: > > | Another thing we should fix is the (now false) impression that HP gets > in > | the way of installing other packages and versions due to cabal hell. > > People mean different things by "cabal hell", but the inability to > simultaneously install multiple versions of the same package, > compiled against different dependencies > is certainly one of them, and I think it is the one that Yitzchak is > referring to here. > > But some time now GHC has allowed multiple versions of the same package > (compiled against different dependencies) to be installed simultaneously. > So all we need to do is to fix Cabal to allow it too, and thereby kill of a > huge class of cabal-hell problems at one blow. > > But time has passed and it hasn't happened. Is this because I'm > misunderstanding? Or because it is harder than I think? Or because there > are much bigger problems? Or because there is insufficient effort > available? Or what? > > Unless I'm way off beam, this "multiple installations of the same package" > thing has been a huge pain forever, and the solution is within our grasp. > What's stopping us grasping it? > > Simon > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Mon Mar 23 09:17:07 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 23 Mar 2015 10:17:07 +0100 Subject: Cabal and simultaneous installations of the same package In-Reply-To: (Michael Snoyman's message of "Mon, 23 Mar 2015 08:52:31 +0000") References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87r3sgm5t8.fsf@gmail.com> On 2015-03-23 at 09:52:31 +0100, Michael Snoyman wrote: [...] > So my word of warning here is: if we simply throw multiple > package/version/dependency combinations at users via cabal, there's a good > chance that we'll do more harm than good. Nevertheless, the best way to find out is to actually try it by implementing it... if in fact it doesn't work out as well as expected, we don't have to ship it :-) From hesselink at gmail.com Mon Mar 23 09:49:25 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 23 Mar 2015 10:49:25 +0100 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On Mon, Mar 23, 2015 at 6:13 AM, Mark Lentczner wrote: > exceptions & multipart - needed by cgi - is exceptions now subsumed by > something in transformers? and... multipart? maybe time to drop cgi? We > didn't have it last time anyway as it wouldn't compile! Multipart was pulled out of cgi just to get access to it, so if you want, you can include it by the same logic as network-uri (except that it wasn't exposed before). Erik From simonpj at microsoft.com Mon Mar 23 09:52:55 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 09:52:55 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net> It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString." Reading your blog post [1] it seems that we are addressing different questions: ? My proposal is only that the act of *installing* a package does not break existing installed package, and is not rejected because it risks doing so. ? You agree that the confusing behaviour you describe can?t happen with Cabal. In any one build, Cabal can ensure that only one version of each package is used in the build, so such a message could never show up. ? What you want is for the confusing behaviour to be true of GHCi too. Well that?s simple enough: ensure that the set of exposed packages (ie the ones you say ?import M? for), is consistent in the same way. The point is that I may need to install a bunch of packages to build a program. If I?m using Cabal, none of those newly installed packages need be exposed; I simply need them there so I can compile my program (using Cabal). But at the moment I can?t do that. That leaves open the following question. Suppose ? I want to install and expose package P and Q ? But alas, P depends on containers 2.9 and Q depends on containers 3.1 Now I?m stuck. But there is a good reason for being stuck, and one that is explicable. Simon From: Michael Snoyman [mailto:michael at snoyman.com] Sent: 23 March 2015 08:53 To: Simon Peyton Jones; cabal-devel at haskell.org Cc: haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org Subject: Re: Cabal and simultaneous installations of the same package I'm in favor of adding support to Cabal to allow for this situation. However: I highly doubt this will be the panacea as predicted. It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString." In fact, this confusion is so prevalent that I wrote a blog post about it in September[1]. I strongly believe that the best end-user experience comes from having a single mapping from package name to actually installed package/version/dependencies. I'd go even farther and say that users would be well served by having a single mapping from module name to installed module. In fact, Adam Bergmark even created an issue[2] to look into adding support to Stackage to start enforcing this situation, though the response to a blog post I wrote on that[3] implies that people are not so interested in addressing that problem. So my word of warning here is: if we simply throw multiple package/version/dependency combinations at users via cabal, there's a good chance that we'll do more harm than good. [1] http://www.yesodweb.com/blog/2014/09/woes-multiple-package-versions [2] https://github.com/fpco/stackage/issues/416 [3] http://www.yesodweb.com/blog/2014/02/module-name-conflicts On Mon, Mar 23, 2015 at 10:45 AM Simon Peyton Jones > wrote: Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Mar 23 09:58:29 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 23 Mar 2015 09:58:29 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones wrote: > It's already a huge source of confusion for people using GHCi what they > get messages about "ByteString is not ByteString." > > > > Reading your blog post [1] it seems that we are addressing different > questions: > > ? My proposal is only that the act of **installing** a package > does not break existing installed package, and is not rejected because it > risks doing so. > Thank you for the clarification, I had misread that. On that front: I agree. > ? You agree that the confusing behaviour you describe can?t > happen with Cabal. In any one build, Cabal can ensure that only one > version of each package is used in the build, so such a message could never > show up. > I've seen people discussing exactly such a change to Cabal's behavior, so I mistakenly took your comments to be heading in that direction. While I think there *might* be some future where we could expose that functionality, it could be incredibly confusing. I'd feel much better starting off with simply the act of installing. > ? What you want is for the confusing behaviour to be true of > GHCi too. Well that?s simple enough: ensure that the set of *exposed* > packages (ie the ones you say ?import M? for), is consistent in the same > way. The point is that I may need to install a bunch of packages to build > a program. If I?m using Cabal, none of those newly installed packages need > be exposed; I simply need them there so I can compile my program (using > Cabal). But at the moment I can?t do that. > > > > That leaves open the following question. Suppose > > ? I want to install *and expose* package P and Q > > ? But alas, P depends on containers 2.9 and Q depends on > containers 3.1 > > Now I?m stuck. But there is a good reason for being stuck, and one that is > explicable. > > > If I'm reading this correctly, the proposal then would be to have cabal automatically hide packages (as oppose to unregister them) to arrive at a world where all exposed packages are consistent. Extrapolating for the case you mention above * if I installed P and then Q, I'd end up with containers-3.1 and Q exposed, and containers-2.9 and P hidden * if I installed Q and then P, I'd end up with containers-2.9 and P exposed, and containers-3.1 and Q hidden But either way, all four package/versions would be available, and cabal would be able to select an appropriate subset of packages when configuring. Does that sound about right? Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 23 10:01:32 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 10:01:32 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: Like Richard, I was astonished by this. I always thought that the Haskell Platform was the route of choice to install GHC, together with a respectable set of libraries. It?s certainly what I install on a new machine! Let?s not forget the large but non-vocal set of ill-informed and/or would-be users, who want a simple answer to ?How do I install GHC??. It may be that the HP formula needs re-visiting, but I think it?s very important that we continue to give a very simple (click here) answer to that question. Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Mark Lentczner Sent: 21 March 2015 17:54 To: ghc-devs at haskell.org; Haskell Libraries; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com Subject: wither the Platform I'm wondering how we are all feeling about the platform these days.... I notice that in the new Haskell pages, the Platform is definitely not the recommended way to go: The main download pages suggests the compiler and base libraries as the first option - and the text for the Platform (second option) pretty much steers folks away from it. Of the per-OS download pages, only the Windows version even mentions it. Does this mean that we don't want to consider continuing with it? It is a lot of community effort to put out a Platform release - we shouldn't do it if we don't really want it. That said, I note that the other ways to "officially get" Haskell look, to my eye, very ad hoc. Many of the options involve multiple steps, and exactly what one is getting isn't clear. It hardly looks like there is now an "official, correct" way to setup Haskell. The Platform arose in an era before sandboxes and before curated library sets like Stackage and LTS. Last time we set direction was several years ago. These new features and development have clearly changed the landscape for use to reconsider what to do. I don't think the status quo for the Platform is now viable - mostly as evidenced by waning interest in maintaining it. I offer several ways we could proceed: 1) Abandon the Platform. GHC is release in source and binary form. Other package various installers, with more or less things, for various OSes. 2) Slim the Platform. Pare it back to GHC + base + a smaller set of "essential" libs + tools. Keeps a consistent build layout and installation mechanism for Haskell. 3) Re-conceive the Platform. Take a very minimal install approach, coupled with close integration with a curated library set that makes it easy to have a rich canonical, stable environment. This was the core idea around my "GPS Haskell" thoughts from last September - but there would be much to work out in this direction. Thoughts? ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 23 10:05:56 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 10:05:56 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net> Message-ID: If I'm reading this correctly, the proposal then would be to have cabal automatically hide packages (as oppose to unregister them) to arrive at a world where all exposed packages are consistent. Extrapolating for the case you mention above * if I installed P and then Q, I'd end up with containers-3.1 and Q exposed, and containers-2.9 and P hidden * if I installed Q and then P, I'd end up with containers-2.9 and P exposed, and containers-3.1 and Q hidden But either way, all four package/versions would be available, and cabal would be able to select an appropriate subset of packages when configuring. Does that sound about right? Correct, esp the bit that I have emboldened. For the former bullets, perhaps Cabal might ask you want you want to do. That still leaves open questions. What happens if you say ?ghc ?package P ?package Q Foo.hs?? Should GHC complain that you?ve chosen an inconsistent set? Perhaps! (NB if P and Q use containers only internally, and do not expose any types from containers, then arguably it?s ok; but I?d argue for jumping that bridge when we come to it.) Simon From: Michael Snoyman [mailto:michael at snoyman.com] Sent: 23 March 2015 09:58 To: Simon Peyton Jones; cabal-devel at haskell.org Cc: haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org Subject: Re: Cabal and simultaneous installations of the same package On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones > wrote: It's already a huge source of confusion for people using GHCi what they get messages about "ByteString is not ByteString." Reading your blog post [1] it seems that we are addressing different questions: ? My proposal is only that the act of *installing* a package does not break existing installed package, and is not rejected because it risks doing so. Thank you for the clarification, I had misread that. On that front: I agree. ? You agree that the confusing behaviour you describe can?t happen with Cabal. In any one build, Cabal can ensure that only one version of each package is used in the build, so such a message could never show up. I've seen people discussing exactly such a change to Cabal's behavior, so I mistakenly took your comments to be heading in that direction. While I think there *might* be some future where we could expose that functionality, it could be incredibly confusing. I'd feel much better starting off with simply the act of installing. ? What you want is for the confusing behaviour to be true of GHCi too. Well that?s simple enough: ensure that the set of exposed packages (ie the ones you say ?import M? for), is consistent in the same way. The point is that I may need to install a bunch of packages to build a program. If I?m using Cabal, none of those newly installed packages need be exposed; I simply need them there so I can compile my program (using Cabal). But at the moment I can?t do that. That leaves open the following question. Suppose ? I want to install and expose package P and Q ? But alas, P depends on containers 2.9 and Q depends on containers 3.1 Now I?m stuck. But there is a good reason for being stuck, and one that is explicable. If I'm reading this correctly, the proposal then would be to have cabal automatically hide packages (as oppose to unregister them) to arrive at a world where all exposed packages are consistent. Extrapolating for the case you mention above * if I installed P and then Q, I'd end up with containers-3.1 and Q exposed, and containers-2.9 and P hidden * if I installed Q and then P, I'd end up with containers-2.9 and P exposed, and containers-3.1 and Q hidden But either way, all four package/versions would be available, and cabal would be able to select an appropriate subset of packages when configuring. Does that sound about right? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Mon Mar 23 10:20:36 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Mon, 23 Mar 2015 11:20:36 +0100 Subject: wither the Platform In-Reply-To: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: >From the downloads page on the GHC homepage: Version 7.8.4 (released December 23rd 2014) Stop! For most users, we recommend installing the Haskell Platform instead of GHC. The current Haskell Platform release includes a recent GHC release as well as some other tools (such as cabal), and a larger set of libraries that are known to work together. On Mon, Mar 23, 2015 at 11:01 AM, Simon Peyton Jones wrote: > I notice that in the new Haskell pages, the Platform is definitely not > the recommended way to go: > > > > Like Richard, I was astonished by this. I always thought that the Haskell > Platform was *the* route of choice to install GHC, together with a > respectable set of libraries. It?s certainly what I install on a new > machine! > > > > Let?s not forget the large but non-vocal set of ill-informed and/or > would-be users, who want a simple answer to ?How do I install GHC??. It > may be that the HP formula needs re-visiting, but I think it?s very > important that we continue to give a very simple (click here) answer to > that question. > > > > Simon > > > > *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of *Mark > Lentczner > *Sent:* 21 March 2015 17:54 > *To:* ghc-devs at haskell.org; Haskell Libraries; > haskell-platform at projects.haskell.org; > haskell-infrastructure at community.galois.com > *Subject:* wither the Platform > > > > I'm wondering how we are all feeling about the platform these days.... > > > > I notice that in the new Haskell pages, the Platform is definitely not the > recommended way to go: The main download pages suggests the compiler and > base libraries as the first option - and the text for the Platform (second > option) pretty much steers folks away from it. Of the per-OS download > pages, only the Windows version even mentions it. > > > > Does this mean that we don't want to consider continuing with it? It is a > lot of community effort to put out a Platform release - we shouldn't do it > if we don't really want it. > > > > That said, I note that the other ways to "officially get" Haskell look, to > my eye, very ad hoc. Many of the options involve multiple steps, and > exactly what one is getting isn't clear. It hardly looks like there is now > an "official, correct" way to setup Haskell. > > > > The Platform arose in an era before sandboxes and before curated library > sets like Stackage and LTS. Last time we set direction was several years > ago. These new features and development have clearly changed the landscape > for use to reconsider what to do. > > > > > > I don't think the status quo for the Platform is now viable - mostly as > evidenced by waning interest in maintaining it. I offer several ways we > could proceed: > > > > *1) Abandon the Platform.* GHC is release in source and binary form. > Other package various installers, with more or less things, for various > OSes. > > > > *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > "essential" libs + tools. Keeps a consistent build layout and installation > mechanism for Haskell. > > > > *3) Re-conceive the Platform.* Take a very minimal install approach, > coupled with close integration with a curated library set that makes it > easy to have a rich canonical, stable environment. This was the core idea > around my "GPS Haskell" thoughts from last September - but there would be > much to work out in this direction. > > > > Thoughts? > > > > ? Mark > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Mon Mar 23 10:47:48 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 23 Mar 2015 11:47:48 +0100 Subject: wither the Platform In-Reply-To: (Thomas Miedema's message of "Mon, 23 Mar 2015 11:20:36 +0100") References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87mw34m1m3.fsf@gnu.org> On 2015-03-23 at 11:20:36 +0100, Thomas Miedema wrote: [...] > For most users, we recommend installing the Haskell Platform > instead of GHC. The current Haskell > Platform release includes a recent GHC release as well as some other tools > (such as cabal), and a larger set of libraries that are known to work > together. Btw, I've always wondered a little bit about the last part, namely "set of libraries that are known to work together"... what is actually meant by that? Does it simply refer to providing a selection of package-versions that form a valid coherent/simultaneous Cabal install plan? Cheers, hvr From michael at snoyman.com Mon Mar 23 11:49:28 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 23 Mar 2015 11:49:28 +0000 Subject: Backporting srcLoc to the GHC 7.10 branch Message-ID: It looks like the srcLoc change[1] is something that some of our (FP Complete's) customers would be quite interested in getting access to sooner rather than later. Would there be any possibility of getting that patch merged into the 7.10 branch of GHC? I'm not sure if I'd try my luck at actually including it in 7.10.1, but would it be on the table for 7.10.2? We do of course have the option of backporting it ourselves and including it in a custom GHC we provide customers, but we generally try to stay as close to upstream as possible. [1] https://ghc.haskell.org/trac/ghc/ticket/9049 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 23 11:52:33 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 11:52:33 +0000 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: References: Message-ID: <08cabb056a1e4d24b43ef5ae7e4dec5c@DB4PR30MB030.064d.mgd.msft.net> We don?t put API changes in minor releases, only bugfixes. I think you?d be better arguing for an early release of 7.12. Which might be a fine thing Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Michael Snoyman Sent: 23 March 2015 11:49 To: ghc-devs at haskell.org Subject: Backporting srcLoc to the GHC 7.10 branch It looks like the srcLoc change[1] is something that some of our (FP Complete's) customers would be quite interested in getting access to sooner rather than later. Would there be any possibility of getting that patch merged into the 7.10 branch of GHC? I'm not sure if I'd try my luck at actually including it in 7.10.1, but would it be on the table for 7.10.2? We do of course have the option of backporting it ourselves and including it in a custom GHC we provide customers, but we generally try to stay as close to upstream as possible. [1] https://ghc.haskell.org/trac/ghc/ticket/9049 -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Mon Mar 23 12:03:22 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 23 Mar 2015 09:03:22 -0300 Subject: wither the Platform In-Reply-To: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: +1 An important example of the last point is an introductory programming course using Haskell. The students will mostly have Windows and Mac laptops. Having a very simple (click here) way to get students set up with Haskell is important for such a course. On Mon, Mar 23, 2015 at 7:01 AM, Simon Peyton Jones wrote: > I notice that in the new Haskell pages, the Platform is definitely not > the recommended way to go: > > > > Like Richard, I was astonished by this. I always thought that the Haskell > Platform was *the* route of choice to install GHC, together with a > respectable set of libraries. It?s certainly what I install on a new > machine! > > > > Let?s not forget the large but non-vocal set of ill-informed and/or > would-be users, who want a simple answer to ?How do I install GHC??. It > may be that the HP formula needs re-visiting, but I think it?s very > important that we continue to give a very simple (click here) answer to > that question. > > > > Simon > > > > *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of *Mark > Lentczner > *Sent:* 21 March 2015 17:54 > *To:* ghc-devs at haskell.org; Haskell Libraries; > haskell-platform at projects.haskell.org; > haskell-infrastructure at community.galois.com > *Subject:* wither the Platform > > > > I'm wondering how we are all feeling about the platform these days.... > > > > I notice that in the new Haskell pages, the Platform is definitely not the > recommended way to go: The main download pages suggests the compiler and > base libraries as the first option - and the text for the Platform (second > option) pretty much steers folks away from it. Of the per-OS download > pages, only the Windows version even mentions it. > > > > Does this mean that we don't want to consider continuing with it? It is a > lot of community effort to put out a Platform release - we shouldn't do it > if we don't really want it. > > > > That said, I note that the other ways to "officially get" Haskell look, to > my eye, very ad hoc. Many of the options involve multiple steps, and > exactly what one is getting isn't clear. It hardly looks like there is now > an "official, correct" way to setup Haskell. > > > > The Platform arose in an era before sandboxes and before curated library > sets like Stackage and LTS. Last time we set direction was several years > ago. These new features and development have clearly changed the landscape > for use to reconsider what to do. > > > > > > I don't think the status quo for the Platform is now viable - mostly as > evidenced by waning interest in maintaining it. I offer several ways we > could proceed: > > > > *1) Abandon the Platform.* GHC is release in source and binary form. > Other package various installers, with more or less things, for various > OSes. > > > > *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > "essential" libs + tools. Keeps a consistent build layout and installation > mechanism for Haskell. > > > > *3) Re-conceive the Platform.* Take a very minimal install approach, > coupled with close integration with a curated library set that makes it > easy to have a rich canonical, stable environment. This was the core idea > around my "GPS Haskell" thoughts from last September - but there would be > much to work out in this direction. > > > > Thoughts? > > > > ? Mark > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mietek at bak.io Mon Mar 23 12:22:02 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Mon, 23 Mar 2015 12:22:02 +0000 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Thanks, Mark. Could you restore the OS X GHC 7.10.1-rc2 bindist? It was available at: http://www.ozonehouse.com/mark/platform/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 I have it mirrored and CDN-ified at: https://s3.halcyon.sh/original/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 -- Mi?tek https://mietek.io On 2015-03-23, at 05:13, Mark Lentczner wrote: > I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 using GHC 7.10 RC3. > > I bumped all the GHC libs to the versions in 7.10, and bumped all the Platform libs to the latest versions I could find on Hackage. There were a few issues: > ? old-locale and old-time - no longer part of GHC, but cabal-install, cgi & HTTP need them - and they are part of the platform - so included now as added packages. Not sure this is a great idea, since they are now very deprecated... but until cabal-install, cgi, & HTTP update, not sure what else to do. > ? tf-random - is now required by alex and QuickCheck - seems a shame to add this, as now we're going to have two random packages > ? network-uri - was split out of network, and needed by cabal-install, cgi, & HTTP. I suppose we should include it, as it was functionality and API that was part of the platform > ? exceptions & multipart - needed by cgi - is exceptions now subsumed by something in transformers? and... multipart? maybe time to drop cgi? We didn't have it last time anyway as it wouldn't compile! > ? scientific - needed by attoparsec - debated in detail last time ... and we're still here! > The Platform is significantly larger now: On OS X it has gone from 316M to 499M! Most of this is due to new OpenGL libs which are now huge (went from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole installed magilla is 1.5G! Even the compressed installer is now 250M! > > If you want to poke at it, the source is in the pre-release branch at GitHub, and the OS X builds are at my usual platform staging area: > > Index of /mark/platform > > Remember, it already includes GHC, so no need to download the GHC binary for OS X that is there, too. > > I'll try to get a generic linux build up soonish... but my VM now runs out of memory trying to build OpenGL - and adding more only makes my machine thrash to death! > > - Mark > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From eir at cis.upenn.edu Mon Mar 23 12:42:53 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 23 Mar 2015 08:42:53 -0400 Subject: fast test suite failures on OS X with 7.10 RC head In-Reply-To: References: Message-ID: <3F176170-1DBE-4FE4-92B0-C866FF3E8EE4@cis.upenn.edu> I work exclusively on Mac and have been seeing those errors for months. I'll admit to not having looked into them, as I was fairly sure they Weren't My Fault. However, I'd be willing to be a supportive member of a Mac taskforce, reporting what I see and running experiments as requested. I'm afraid I can't volunteer to be a primary member of such a taskforce, as I know very little about the sorts of things that cause platform-specific failures. Do let me know if anyone out there wants more information (dumps, other experiments) related to the failures above. Thanks! Richard On Mar 22, 2015, at 4:24 PM, Thomas Miedema wrote: > Maybe it's time for a Mac OS X taskforce? > > All these unexpected test failures on OS X (see also > https://ghc.haskell.org/trac/ghc/ticket/9389), and OS X specific > tickets in general, could get some more attention: > https://ghc.haskell.org/trac/ghc/query?status=!closed&os=MacOS+X > > -Thomas (who, like most ghc developers it seems, doesn't work on a Mac) > > On Sun, Mar 22, 2015 at 8:40 PM, Carter Schonwald > wrote: >> hey all >> >> heres the results from the test suite run on a build of 7.10 head on OS X >> >> i believe that some of the test suite failures are because I set the min OS >> X version to 10.6 rather than 10.7, and that some are because GCC (unlike >> clang) doesn't support certain OS X specific things like objective C or >> related header files. I'll add more information as I have the time, but >> figured I should share this for now >> >> Unexpected results from: >> TEST="T10019 sigcabal01 objc-hi objcpp-hi retc001 linker_unload debug >> T2276_ghci T9203 T1969 T9675 T783 T5642 T6048" >> >> OVERALL SUMMARY for test run started at Sun Mar 22 14:58:07 2015 EDT >> 0:31:34 spent to go through >> 4405 total tests, which gave rise to >> 18027 test cases, of which >> 13966 were skipped >> >> 52 had missing libraries >> 3950 expected passes >> 45 expected failures >> >> 0 caused framework failures >> 0 unexpected passes >> 8 unexpected failures >> 6 unexpected stat failures >> >> Unexpected failures: >> cabal/sigcabal01 sigcabal01 [bad stderr] (normal) >> codeGen/should_compile debug [bad stderr] (normal) >> driver/objc objc-hi [exit code non-0] (normal) >> driver/objc objcpp-hi [exit code non-0] (normal) >> driver/retc001 retc001 [bad stderr] (normal) >> ffi/should_run T2276_ghci [bad exit code] (ghci) >> rts linker_unload [bad exit code] (normal) >> th T10019 [bad stdout] (ghci) >> >> Unexpected stat failures: >> perf/compiler T1969 [stat not good enough] (normal) >> perf/compiler T5642 [stat not good enough] (normal) >> perf/compiler T6048 [stat not good enough] (optasm) >> perf/compiler T783 [stat not good enough] (normal) >> perf/compiler T9675 [stat not good enough] (optasm) >> perf/should_run T9203 [stat too good] (normal) >> >> ~/D/r/g/testsuite (ghc-7.10|?) $ echo $MACOSX_DEPLOYMENT_TARGET >> 10.6 >> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From mietek at bak.io Mon Mar 23 12:42:57 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Mon, 23 Mar 2015 12:42:57 +0000 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Hi Austin, Can you add Mark?s OS X bindists to https://downloads.haskell.org/~ghc/, please? 7.10.1-rc2: http://www.ozonehouse.com/mark/platform/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 (404) https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 (my mirror) 7.10.1-rc3: http://www.ozonehouse.com/mark/platform/ghc-7.10.0.20150316-x86_64-apple-darwin.tar.bz2 https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150316-x86_64-apple-darwin.tar.bz2 (my mirror) -- Mi?tek https://mietek.io On 2015-03-23, at 12:22, Mi?tek Bak wrote: > Thanks, Mark. > > Could you restore the OS X GHC 7.10.1-rc2 bindist? > > It was available at: > http://www.ozonehouse.com/mark/platform/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 > > I have it mirrored and CDN-ified at: > https://s3.halcyon.sh/original/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 > https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 > > > -- > Mi?tek > https://mietek.io > > > > > On 2015-03-23, at 05:13, Mark Lentczner wrote: > >> I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 using GHC 7.10 RC3. >> >> I bumped all the GHC libs to the versions in 7.10, and bumped all the Platform libs to the latest versions I could find on Hackage. There were a few issues: >> ? old-locale and old-time - no longer part of GHC, but cabal-install, cgi & HTTP need them - and they are part of the platform - so included now as added packages. Not sure this is a great idea, since they are now very deprecated... but until cabal-install, cgi, & HTTP update, not sure what else to do. >> ? tf-random - is now required by alex and QuickCheck - seems a shame to add this, as now we're going to have two random packages >> ? network-uri - was split out of network, and needed by cabal-install, cgi, & HTTP. I suppose we should include it, as it was functionality and API that was part of the platform >> ? exceptions & multipart - needed by cgi - is exceptions now subsumed by something in transformers? and... multipart? maybe time to drop cgi? We didn't have it last time anyway as it wouldn't compile! >> ? scientific - needed by attoparsec - debated in detail last time ... and we're still here! >> The Platform is significantly larger now: On OS X it has gone from 316M to 499M! Most of this is due to new OpenGL libs which are now huge (went from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole installed magilla is 1.5G! Even the compressed installer is now 250M! >> >> If you want to poke at it, the source is in the pre-release branch at GitHub, and the OS X builds are at my usual platform staging area: >> >> Index of /mark/platform >> >> Remember, it already includes GHC, so no need to download the GHC binary for OS X that is there, too. >> >> I'll try to get a generic linux build up soonish... but my VM now runs out of memory trying to build OpenGL - and adding more only makes my machine thrash to death! >> >> - Mark >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From mark.lentczner at gmail.com Mon Mar 23 14:01:23 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 23 Mar 2015 07:01:23 -0700 Subject: wither the Platform In-Reply-To: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 3:01 AM, Simon Peyton Jones wrote: > I notice that in the new Haskell pages, the Platform is definitely not > the recommended way to go: > > > > Like Richard, I was astonished by this. I always thought that the Haskell > Platform was *the* route of choice to install GHC, together with a > respectable set of libraries. It?s certainly what I install on a new > machine! > I do too...! But follow the new Haskell.org pages like you are a user "just want to install Haskell"... you'll never end up with the Platform. It looks like the Platform deprecated on the Haskell.org site for Linux and OS X in June , and for Windows in Jan . *Infrastructure team:* Was there a discussion and decision to do that somewhere? Let?s not forget the large but non-vocal set of ill-informed and/or > would-be users, who want a simple answer to ?How do I install GHC??. It > may be that the HP formula needs re-visiting, but I think it?s very > important that we continue to give a very simple (click here) answer to > that question. > As evidenced by yourself, and those that spoke up here, there is also a vocal, well-informed set of users who want such a thing as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 23 14:02:51 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 23 Mar 2015 07:02:51 -0700 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 3:20 AM, Thomas Miedema wrote: > From the downloads page > on the GHC homepage: > Alas, that warning has never been effective. But it is moot anyway: Start from the shiny Haskell.org page and see where you land! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 23 14:21:07 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 23 Mar 2015 07:21:07 -0700 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: A common sentiment I see here is that the Platform always seems out of date. That has always been true, and to a degree by design: It is the stable set, not the wild west. Historically, the first release of a major new GHC was seen as needing a bit of a trial period before we enshrined it in a Platform release. Hence, they lagged. There are also other concerns like stable release schedule (which the Platform has been poor at, but has always been a goal). GHC has made great strides in being much more stable out of the gate. And the Platform has been significantly automated recently. For example, there is already an Alpha of the Platform for 7.10 RC3. But it still takes person-power to run it, test it, and get it out. And there is still the issue of stable release times. If you want latest GHC, and latest libs - then Platform is not the way to go. A solid question is: Where do we want to direct the mass of the community? At head? At latest release? At some older, but now stabilized point? What do we want their experience to be? We will best served if the answer is pretty much right for the bulk of the community: not just newcomers, not just people doing production work, not just hobbiests... all of them. Most other language systems manage to have a single distribution that works for the majority of the community, and most of them are content to have much better stability and support. Python put out 2.7.0 in 2010, and 2.7.9 last Dec. It is still supporting 2.7 line (with source and library compatibility) while it is off releasing 3.3 line. This would be for us like deciding to support and update 7.8, and the pre-FTP Prelude for another four years. Which wouldn't be so bad... ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 23 14:24:10 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 23 Mar 2015 07:24:10 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On Mon, Mar 23, 2015 at 5:22 AM, Mi?tek Bak wrote: > Could you restore the OS X GHC 7.10.1-rc2 bindist? > Didn't think anyone would want it now that we have RC3... I don't have it on the server anymore, but see you have it mirrored. Hashes are: e3d160e853b549cab64726c204655a5979e6c345 ghc/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 dc2526687a51288dcd157be07ee1452ddfe7be34 ghc/ghc-7.10.0.20150316-x86_64-apple-darwin.tar.bz2 - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Mon Mar 23 14:27:32 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 23 Mar 2015 10:27:32 -0400 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On March 23, 2015 at 10:02:11 AM, Mark Lentczner (mark.lentczner at gmail.com) wrote: > I do too...! But follow the new Haskell.org pages like you are a user "just > want to install Haskell"... you'll never end up with the Platform. > > It looks like the Platform deprecated on the Haskell.org site for Linux and > OS X in June > , > and for Windows in Jan > > . > *Infrastructure team:* Was there a discussion and decision to do that > somewhere? > I thought the current language on the page was rather balanced? That said, the initial people working on the site strongly leaned towards recommending minimal downloads over the platform in general, and as OS X and Windows developed good minimal installers the site was updated to point to them. In the editorial process on the site we, actually worked to make sure the platform _was_ highlighted more than it had been. And every time the site has come under public review (three times thus far, at least) the issue of minimal installers vs. platform was contentious, but with the former voice dominating. Note that there remains an issue under discussion about making the presentation of the two alternatives more balanced yet:?https://github.com/haskell-infra/hl/issues/55 (patches and pull requests welcome!). In any case, here is my problem. I would like us to be in a situation where we can always say ?use the platform? to new users. I don?t think we are there, because new users will insist on using whatever libraries they read about as the latest and greatest, and those libraries do necessarily take care to ensure platform-compatability. (And if you tell them that straying from the platform is not for the inexperienced, they will snap at you and call you condescending, and insist they know what they are doing? shrug). Since we cannot mass-alter this sort of attitude among new users, then the next best thing would be to mass-alter the attitude among people who write not-platform-compatible libraries. But that is hard to do as well! (A ?badge? on hackage for platform-compatible packages would do wonders, I think). So, in the meantime, we need to get the centralized, uniform platform installers into a shape where we _can_ uniformly recommend them. And, as I suggested, it seems to me the way to go about doing that is decoupling the ?library curation? element of the platform from the ?installing haskell? element. That, or ruthlessly marking packages on hackage that do not work with the current platform with a big red X :-) Cheers, Gershom From mietek at bak.io Mon Mar 23 14:28:33 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Mon, 23 Mar 2015 14:28:33 +0000 Subject: OS X builds of GHC 7.8.4, 7.10.1-rc2, and 7.10.1-rc3 Message-ID: An OS X build of GHC 7.10.1-rc3 is now available, courtesy of Mark Lentczner. This is in addition to the GHC 7.8.4 and 7.10.1-rc2 builds Mark has made available on February 2. Thanks, Mark. GHC 7.8.4 for OS X can already be downloaded from haskell.org, even though it?s not mentioned on the GHC 7.8.4 webpage: https://downloads.haskell.org/~ghc/7.8.4/ghc-7.8.4-x86_64-apple-darwin.tar.xz To avoid running up Mark?s bandwidth bill, I?m omitting the URL to his staging area. I?ve mirrored all three builds in Halcyon public storage: 7.8.4: https://halcyon.global.ssl.fastly.net/original/ghc-7.8.4-x86_64-apple-darwin.tar.xz 7.10.1-rc2: https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 7.10.1-rc3: https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150316-x86_64-apple-darwin.tar.bz2 Binary builds of GHC, repackaged with documentation removed, are also available in Halcyon ? on OS X 10.10, 10.9, 10.8, and a considerable number of Linux distributions. This includes GHC 7.10.1-rc3, 7.10.1-rc2, 7.8.4, 7.8.3, 7.8.2, 7.6.3, 7.6.1, 7.4.2, 7.2.2, and 7.0.4. Using Halcyon, installing GHC together with cabal-install is expected to take 20-30 seconds: https://halcyon.sh/tutorial/#install-ghc-and-cabal -- Mi?tek https://mietek.io -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From mietek at bak.io Mon Mar 23 14:48:37 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Mon, 23 Mar 2015 14:48:37 +0000 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: I?m asking because until these archives appear on haskell.org, your server is the closest to a canonical location. Halcyon references the canonical locations of GHC and cabal-install archives, in case a cautious user doesn?t want to use the builds I?ve prepared: https://github.com/mietek/halcyon/blob/master/src/ghc.sh#L175 -- Mi?tek https://mietek.io On 2015-03-23, at 14:24, Mark Lentczner wrote: > Didn't think anyone would want it now that we have RC3... > I don't have it on the server anymore, but see you have it mirrored. > Hashes are: > e3d160e853b549cab64726c204655a5979e6c345 ghc/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 > dc2526687a51288dcd157be07ee1452ddfe7be34 ghc/ghc-7.10.0.20150316-x86_64-apple-darwin.tar.bz2 > > - Mark > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From mark.lentczner at gmail.com Mon Mar 23 14:57:06 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Mon, 23 Mar 2015 07:57:06 -0700 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 7:27 AM, Gershom B wrote: > I thought the current language on the page was rather balanced? > It leads any user away from the Platfrom: - From the homepage - "Downloads" from the top bar - First links are three OS links, click any one.... - The Windows one has one link the Platform at bottom after giving you a different way to install - The OS X only mentions the Platform if you have an older OS - The Linux page doesn't mention the Platform at all. - If you read the paragraph on Platform - it basically says don't use it. Personally, I think multiple options in this regard is a failure. We aught to have one path that works for the vast majority of use cases. The reason is that there are many build and packaging choices in getting from source to installed tool chain, and each of these paths makes them differently... which leads to just tons of incompatibility and confusion. If the community wants minimal installers - fine - I wish we had one way not two or three. The Platform has a very complete and automated build - and installers tested on a wide variety of OS versions - it could easily be adapted to a more minimal approach (as per my GPS proposal a way back) if that's what we want. I'd really like to invite folks creating minimal installers to rally around the large body of work, experience, and code in building the Haskell Platform installers. They could easily fashion minimal builds from it (with the Shake build system this is now like a single .hs file of work...)... then perhaps we could have Platform "minimal" and "full" releases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Mon Mar 23 14:58:48 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 23 Mar 2015 10:58:48 -0400 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Hey mark, How do you get the ghc docs built successfully on os x? I've tried to replicate you buildsteps but docbook hits a failure when tryingto download some remote file. Many thanks On Mar 22, 2015 10:13 PM, "Mark Lentczner" wrote: > I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 > using GHC 7.10 RC3. > > I bumped all the GHC libs to the versions in 7.10, and bumped all the > Platform libs to the latest versions I could find on Hackage. There were a > few issues: > > - *old-locale and old-time* - no longer part of GHC, but > cabal-install, cgi & HTTP need them - and they are part of the platform - > so included now as added packages. Not sure this is a great idea, since > they are now very deprecated... but until cabal-install, cgi, & HTTP > update, not sure what else to do. > - *tf-random* - is now required by alex and QuickCheck - seems a shame > to add this, as now we're going to have two random packages > - *network-uri *- was split out of network, and needed by > cabal-install, cgi, & HTTP. I suppose we should include it, as it was > functionality and API that was part of the platform > - *exceptions* & *multipart* - needed by cgi - is exceptions now > subsumed by something in transformers? and... multipart? maybe time to drop > cgi? We didn't have it last time anyway as it wouldn't compile! > - *scientific* - needed by attoparsec - debated in detail last time > ... and we're still here! > > The Platform is significantly larger now: On OS X it has gone from 316M to > 499M! Most of this is due to new OpenGL libs which are now huge (went from > 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole > installed magilla is 1.5G! Even the compressed installer is now 250M! > > If you want to poke at it, the source is in the pre-release branch at > GitHub , > and the OS X builds are at my usual platform staging area: > > Index of /mark/platform > > > Remember, it already includes GHC, so no need to download the GHC binary > for OS X that is there, too. > > I'll try to get a generic linux build up soonish... but my VM now runs out > of memory trying to build OpenGL - and adding more only makes my machine > thrash to death! > > - Mark > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Mon Mar 23 14:58:32 2015 From: chrisdone at gmail.com (Christopher Done) Date: Mon, 23 Mar 2015 15:58:32 +0100 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On 23 March 2015 at 15:01, Mark Lentczner wrote: > On Mon, Mar 23, 2015 at 3:01 AM, Simon Peyton Jones wrote: > > Like Richard, I was astonished by this. I always thought that the > > Haskell Platform was the route of choice to install GHC, together > > with a respectable set of libraries. It?s certainly what I install > > on a new machine! > > I do too...! But follow the new Haskell.org pages like you are a user > "just want to install Haskell"... you'll never end up with the > Platform. Separate from any opinions about what's best going forward, chiming in on a bit of history for the new homepage, my motivations were: I wanted newbies to come to the site and find a download page *within the Haskell.org site* (not going to another site with a different design) that gives them something current and usable. I added the manual GHC install guide (now gone) because that is the method I was most familiar with. I've never used a HP release. So I surveyed the current crop of handy installers and judged community use of these things from mailing lists, reddit, IRC, etc. I saw enough interactions with newbies that the HP was not being recommended anymore due to its old GHC version and old packages (at the time of making that change on the page, the current HP release was very old), and the problem of the global database and installing new things. I'm not really familiar with the user experience of this, but people don't seem to like it. So the Linux install became recommendations of OS-specific installers (e.g. the Ubuntu and Arch repos are often recommended), and Windows remained HP coupled with the new MinGHC (which I also saw being recommended), and OS X became linked to the GHC for Mac OS X project (again, I saw people were using that), each of which claim superiority for various platform-specific reasons over the HP releases. So that's the decision-making process that went into making the page flow like it is. Someone added this text: > Many now recommend just using a bare compiler combined with sandboxed > dependencies, especially for new users. However, others prefer to > start with the curated blessed set of packages in the Haskell > Platform, which is available for Windows, OS X, and Linux. Which adds choice to users ill-equipped to make choice. I didn't add it (although I understand the motivation behind it). From a web site perspective, I'd prefer the download pages just be on the site. If it's these platform-specific installers, the HP, or some new helpful installer + LTS or whatever, it should be just there under /downloads, /downloads/windows, etc. and there should ideally be one, good, current choice. The current page is a compromise, not the final product. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Mon Mar 23 15:05:28 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 23 Mar 2015 16:05:28 +0100 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 9:45 AM, Simon Peyton Jones wrote: > But time has passed and it hasn't happened. Is this because I'm > misunderstanding? Or because it is harder than I think? Or because there > are much bigger problems? Or because there is insufficient effort > available? Or what? I have no idea what the status of this is or if GHC indeed has all the things we need. Perhaps Edward could comment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Mar 23 15:10:19 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 23 Mar 2015 11:10:19 -0400 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <8259E963-9441-4E13-8F9F-E84E024EDE65@cis.upenn.edu> On Mar 23, 2015, at 10:58 AM, Christopher Done wrote: > > Someone added this text: > > > Many now recommend just using a bare compiler combined with sandboxed > > dependencies, especially for new users. However, others prefer to > > start with the curated blessed set of packages in the Haskell > > Platform, which is available for Windows, OS X, and Linux. > > Which adds choice to users ill-equipped to make choice. Your point here is a good one. I have to confess I'm not even sure, exactly, what "combined with sandboxed dependencies" means. (Use a sandbox for every package I wish to install, bypassing `cabal install`? Use a sandbox for every package I write? Use a sandbox to write "Hello, world!"? And what about GHCi?) And I'm not a newcomer to Haskell! This is not welcoming, in my opinion. If the recommended installation mentions sandboxes, it's the wrong recommendation, and we should aim for better. Richard From chrisdone at gmail.com Mon Mar 23 15:11:24 2015 From: chrisdone at gmail.com (Christopher Done) Date: Mon, 23 Mar 2015 16:11:24 +0100 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I suppose ironically the page does a good job of representing community opinion; i.e. there is still debate on this issue. Even though ideally the vision was for the site to be as clear as possible, I saw no uncontentious choice here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Mar 23 15:19:14 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 23 Mar 2015 11:19:14 -0400 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Forgive me, all, for asking what many may think a silly question, but I must ask: What's wrong with the platform? One non-answer to this question: - "It's always out-of-date." This statement, while true, isn't a direct indication that something is wrong. How does its age bite? Is the GHC version too old, meaning that users can't install the packages they want? (Are there an older versions of those packages available that *do* work? If so, does cabal find them?) Or, are the packages that ship with the platform out-of-date, causing installation trouble because of high lower-bounds on other packages? My question here hints at the fact that I'm a bit old-fashioned. I generally don't mind when things are out of date, provided that I don't need the new features. Maybe I'm in the minority here, and that the majority of newcomers to Haskell feel the burning need to have the very latest release of everything. But I, personally, would rather have ease of installation and be able to get moving forward without a headache than to have the new, shiny -- especially if I know how to get the new, shiny later if I should need it. Thanks, Richard From acowley at gmail.com Mon Mar 23 15:20:54 2015 From: acowley at gmail.com (Anthony Cowley) Date: Mon, 23 Mar 2015 11:20:54 -0400 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <71766C8F-2325-4752-8C24-F7CFB461FB85@gmail.com> > On Mar 23, 2015, at 10:27 AM, Gershom B wrote: > >> On March 23, 2015 at 10:02:11 AM, Mark Lentczner (mark.lentczner at gmail.com) wrote: >> I do too...! But follow the new Haskell.org pages like you are a user "just >> want to install Haskell"... you'll never end up with the Platform. >> >> It looks like the Platform deprecated on the Haskell.org site for Linux and >> OS X in June >> , >> and for Windows in Jan >> >> . >> *Infrastructure team:* Was there a discussion and decision to do that >> somewhere? >> > > I thought the current language on the page was rather balanced? > > That said, the initial people working on the site strongly leaned towards recommending minimal downloads over the platform in general, and as OS X and Windows developed good minimal installers the site was updated to point to them. In the editorial process on the site we, actually worked to make sure the platform _was_ highlighted more than it had been. And every time the site has come under public review (three times thus far, at least) the issue of minimal installers vs. platform was contentious, but with the former voice dominating. Note that there remains an issue under discussion about making the presentation of the two alternatives more balanced yet: https://github.com/haskell-infra/hl/issues/55 (patches and pull requests welcome!). > > In any case, here is my problem. I would like us to be in a situation where we can always say ?use the platform? to new users. I don?t think we are there, because new users will insist on using whatever libraries they read about as the latest and greatest, and those libraries do necessarily take care to ensure platform-compatability. (And if you tell them that straying from the platform is not for the inexperienced, they will snap at you and call you condescending, and insist they know what they are doing? shrug). Since we cannot mass-alter this sort of attitude among new users, then the next best thing would be to mass-alter the attitude among people who write not-platform-compatible libraries. But that is hard to do as well! (A ?badge? on hackage for platform-compatible packages would do wonders, I think). I don't understand this attitude. You say that neither new users nor package authors agree with your stance on the HP, so you want to force their hands. Presumably package authors know what they're doing for themselves, and the majority of evidence we have is that new users who stick with the language do not like the way the HP works . I understand this is not your personal preference, but is there any group whose vote would count here? The community has responded to the reality of the situation by having easy minimal installers for OS X, Windows, and Ubuntu. What is coming down the pike is integration between Stackage LTS and isolated build environments that support building programs that need specific versions of dependencies. We're not there yet, but it's coming. The common pieces needed for all concerned parties are: GHC and isolated build environments. Cabal developers, Mietek (of Halcyon), and myself (tying Nix to Cabal) are all rapidly converging on similar designs (which is very encouraging!). The shake out here will likely be cabal-install gaining some Nix-like tricks while supporting tools focus on deployment to servers. This will give us per-package build caching with the opportunity to serve binaries for everything in Stackage, without any headaches of old versions interfering with builds, and a local binary cache that fills up between LTS releases. If the question then becomes, "What's the holdup?" the answer is lack of developer hours. Finally, just to clarify, the goals of the HP, broadly stated as an installer for essential tools and a good starter set of libraries, are not in dispute. Haskellers rely on a vast number of small, focused libraries, and our compile times are nothing to brag about. The combination of those two present a challenge, so now we are tuning how something like the HP ought to be implemented. Anthony > > So, in the meantime, we need to get the centralized, uniform platform installers into a shape where we _can_ uniformly recommend them. And, as I suggested, it seems to me the way to go about doing that is decoupling the ?library curation? element of the platform from the ?installing haskell? element. That, or ruthlessly marking packages on hackage that do not work with the current platform with a big red X :-) > > Cheers, > Gershom > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Mar 23 15:21:33 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 23 Mar 2015 11:21:33 -0400 Subject: wither the Platform In-Reply-To: <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Message-ID: On Mon, Mar 23, 2015 at 11:19 AM, Richard Eisenberg wrote: > - "It's always out-of-date." This statement, while true, isn't a direct > indication that something is wrong. "Perception is reality". The period when the Platform went without an update for over a year because we were waiting on ghc 6.8.3 did a lot to ruin the Platform's reputation. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mietek at bak.io Mon Mar 23 15:28:14 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Mon, 23 Mar 2015 15:28:14 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> <81a93763b0e544ba906087d93494c4aa@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On 2015-03-23, at 09:52, Simon Peyton Jones wrote: > The point is that I may need to install a bunch of packages to build a program. If I?m using Cabal, none of those newly installed packages need be exposed; I simply need them there so I can compile my program (using Cabal). But at the moment I can?t do that. Do you mean that you may need to install a bunch of packages to build a _build-tool_ (such as alex, happy, c2hs, cpps?), in order to compile your program? If yes, then one way to avoid having these packages pollute your build environment is building each Haskell program in a separate sandbox. There are some tools which attempt to simplify this process. Halcyon goes a bit further ? Halcyon allows you to declare other Haskell programs to be installed as build-time (or run-time!) dependencies for your program. If needed, they will be built on-the-fly; otherwise, they will be restored from previously-built archives. This works around long-standing cabal-install issues: https://github.com/haskell/cabal/issues/220 https://github.com/haskell/cabal/issues/779 See the Haskell Language source code for an example: https://halcyon.sh/examples/#haskell-language See the Halcyon reference for details: https://halcyon.sh/reference/#halcyon_sandbox_extra_apps https://halcyon.sh/reference/#halcyon_extra_apps -- Mi?tek https://mietek.io -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From simonpj at microsoft.com Mon Mar 23 15:32:39 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 15:32:39 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <91d2cf5191134135b65cd6d2ae889422@DB4PR30MB030.064d.mgd.msft.net> I have no idea what the status of this is or if GHC indeed has all the things we need. Perhaps Edward could comment. I?m pretty confident that GHC has all the things needed, and has done since last summer. It?s Cabal that doesn?t! But as you say, Edward Y can confirm. Simon From: Johan Tibell [mailto:johan.tibell at gmail.com] Sent: 23 March 2015 15:05 To: Simon Peyton Jones Cc: cabal-devel at haskell.org; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org; Edward Yang Subject: Re: Cabal and simultaneous installations of the same package On Mon, Mar 23, 2015 at 9:45 AM, Simon Peyton Jones > wrote: But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? I have no idea what the status of this is or if GHC indeed has all the things we need. Perhaps Edward could comment. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Mar 23 15:54:55 2015 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 23 Mar 2015 15:54:55 +0000 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Message-ID: On Mon, Mar 23, 2015 at 5:21 PM Brandon Allbery wrote: > On Mon, Mar 23, 2015 at 11:19 AM, Richard Eisenberg > wrote: > >> - "It's always out-of-date." This statement, while true, isn't a direct >> indication that something is wrong. > > > "Perception is reality". The period when the Platform went without an > update for over a year because we were waiting on ghc 6.8.3 did a lot to > ruin the Platform's reputation. > > > I hate to bring this up, but it's not just a historical issue. The version of attoparsec used by the platform today forces an old version of aeson to be used (0.6.2.1). The combination of that aeson and attoparsec version is vulnerable to an incredibly severe DoS attack for specially crafted JSON strings (e.g., {"foo":1e100000000000000000000000}). In fact, just a few weeks ago I sent a private email to someone about a massive vulnerability in a service (obviously not going to point out which one). Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Mon Mar 23 16:30:50 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 23 Mar 2015 18:30:50 +0200 Subject: wither the Platform In-Reply-To: <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Message-ID: <55103FBA.7050807@ro-che.info> On 23/03/15 17:19, Richard Eisenberg wrote: > Forgive me, all, for asking what many may think a silly question, but I must ask: > > What's wrong with the platform? It solves a problem few people seem to have. Most people want a compiler (ghc), a package manager (cabal), and libraries they can install (hackage/stackage). Instead, they are being sold HP which has its own versioning, releases on its own irregular schedule, and brings a small arbitrary set of packages frozen at an arbitrary point in time. These packages often interfere with users' desire to install their own packages. Roman From mietek at bak.io Mon Mar 23 16:32:42 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Mon, 23 Mar 2015 16:32:42 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: <4881437D-8D98-49FA-B4A6-CDE6A2A5DA76@bak.io> On 2015-03-22, at 15:59, Michael Snoyman wrote: > 2. A method for installing GHC and build tools. I personally think that it makes sense to separate out this aspect of the platform from all others. MinGHC is an example of such a project: a minimal set of functionality for bootstrapping a more complete Haskell development environment. > 3. Prebuilt binary package databases. As I've mentioned in the past, and others have here, there are problems with the current approach of putting the packages in the global package database. I'd personally rather see this aspect of the platform give way to more robust solutions. > I think a smaller task force dedicated to improving the tooling situation is the best next step, and I'd be happy to kick off such an effort with other interested individuals. I?d be very happy to contribute to this effort. In fact, I?ve already spent some of time addressing these issues. Halcyon already provides a method for installing GHC, cabal-install, build-tools, and other Haskell programs ? on OS X, and many Linux distributions. FreeBSD and Windows are on the roadmap. Additionally, Halcyon allows you to declare native OS libraries as build-time (or run-time?) dependencies for Haskell programs. They will be installed into a user-controlled directory, by wrapping around the native OS package manager. Currently, this is supported on Debian-based and RedHat-based Linux distributions, which partially implements a long-standing cabal-install feature request: https://github.com/mietek/halcyon/issues/38 https://github.com/haskell/cabal/issues/571 See the Haskell Language source code for an example: https://halcyon.sh/examples/#haskell-language See the Halcyon reference for details: https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages https://halcyon.sh/reference/#halcyon_extra_os_packages -- Mi?tek https://mietek.io -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From nbouscal at gmail.com Mon Mar 23 17:06:21 2015 From: nbouscal at gmail.com (Nathan Bouscal) Date: Mon, 23 Mar 2015 10:06:21 -0700 Subject: wither the Platform In-Reply-To: <4881437D-8D98-49FA-B4A6-CDE6A2A5DA76@bak.io> References: <4881437D-8D98-49FA-B4A6-CDE6A2A5DA76@bak.io> Message-ID: Richard: The problem isn't the age itself, but rather the compatibility problems that age introduces. It can be quite difficult as a new user to get all of the libraries you want to use to play well with the platform. There's usually a way to make it work if you know what you're doing, but the platform is largely targeted at those who don't. This is particularly bad because library compatibility problems are inherently annoying to solve, or at least they feel that way to me. I think Gershom framed the problem well. From the discussion, it sounds like there are a lot of potential solutions, mostly in the category of "re-conceive the platform". On Mon, Mar 23, 2015 at 9:32 AM, Mi?tek Bak wrote: > On 2015-03-22, at 15:59, Michael Snoyman wrote: > > > 2. A method for installing GHC and build tools. I personally think that > it makes sense to separate out this aspect of the platform from all others. > MinGHC is an example of such a project: a minimal set of functionality for > bootstrapping a more complete Haskell development environment. > > 3. Prebuilt binary package databases. As I've mentioned in the past, and > others have here, there are problems with the current approach of putting > the packages in the global package database. I'd personally rather see this > aspect of the platform give way to more robust solutions. > > > > I think a smaller task force dedicated to improving the tooling > situation is the best next step, and I'd be happy to kick off such an > effort with other interested individuals. > > I?d be very happy to contribute to this effort. In fact, I?ve already > spent some of time addressing these issues. > > Halcyon already provides a method for installing GHC, cabal-install, > build-tools, and other Haskell programs ? on OS X, and many Linux > distributions. FreeBSD and Windows are on the roadmap. > > Additionally, Halcyon allows you to declare native OS libraries as > build-time (or run-time?) dependencies for Haskell programs. They will be > installed into a user-controlled directory, by wrapping around the native > OS package manager. > > Currently, this is supported on Debian-based and RedHat-based Linux > distributions, which partially implements a long-standing cabal-install > feature request: > https://github.com/mietek/halcyon/issues/38 > https://github.com/haskell/cabal/issues/571 > > See the Haskell Language source code for an example: > https://halcyon.sh/examples/#haskell-language > > See the Halcyon reference for details: > https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages > https://halcyon.sh/reference/#halcyon_extra_os_packages > > > -- > Mi?tek > https://mietek.io > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Mon Mar 23 17:19:34 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 23 Mar 2015 13:19:34 -0400 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: <71766C8F-2325-4752-8C24-F7CFB461FB85@gmail.com> References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <71766C8F-2325-4752-8C24-F7CFB461FB85@gmail.com> Message-ID: On Mon, Mar 23, 2015 at 11:20 AM, Anthony Cowley wrote: > > I don't understand this attitude. You say that neither new users nor package > authors agree with your stance on the HP, so you want to force their hands. > Presumably package authors know what they're doing for themselves, and the > majority of evidence we have is that new users who stick with the language > do not like the way the HP works > . No, this is not what I said. I was explaining that it rather difficult, even if we wanted to force their hands, to imagine that we could do so. I will say that I do not share your belief that package authors know what they are doing, in general. If they did, I would imagine that nearly all packages would ensure they would work with the current platform. But getting programmers to all agree on something like that is herding cats, and all it takes is a few people saying "feh on the platform" but nonetheless producing otherwise good packages that come into widespread use to _in general_ mean that many packages which directly or indirectly want to use those dependencies must also now split off from support for the platform. So I agree that people have voted with their feet, and we need to catch up to that. In fact, it seems to me from this discussion that there are only _two_ things we need to do to make the platform the recommended install path for all platforms again: 1) Incorporate the improvements to windows builds that have been pioneered by the MinGHC project (in particular so that platform-installed windows ghc can build the network package properly, and perhaps even the GL stuff). 2) Address the problem that in a sandbox you will get a different install plan depending on your global package db. I would suggest this be done by setting a default preference of the sandbox to ignore global packages, and allow that to be overridden with an easily configurable flag or setting or the like. That way, new users can pay the longer compile price for a guaranteed-safer experience, and more experienced users can choose to use / build up a broader library of packages they can share across sandboxes. (Certainly some "nix-like tricks" in cabal could also help address the repeated builds problem, but a flag can be implemented much more quickly as a short-term measure). All that said, I think it would _still_ be better if more package authors paid attention to backwards-compatibility across releases, and it would _still_ be better for new users if they didn't go off and bash their heads against the newest and least stable packages around. But that is indeed a different problem. Cheers, Gershom From gershomb at gmail.com Mon Mar 23 17:31:08 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 23 Mar 2015 13:31:08 -0400 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Mon, Mar 23, 2015 at 4:45 AM, Simon Peyton Jones wrote: > > | Another thing we should fix is the (now false) impression that HP gets in > | the way of installing other packages and versions due to cabal hell. > > People mean different things by "cabal hell", but the inability to > simultaneously install multiple versions of the same package, > compiled against different dependencies > is certainly one of them, and I think it is the one that Yitzchak is referring to here. My understanding is that the problem Yitz is discussing is much more straightforward and easy to fix. The issue is that if I have an "empty" global package db and enter a sandbox and cabal-install something, then I will get one package install plan. But if I have a "well populated" package db, then attempt to cabal-install something in the sandbox, the plan will attempt to use the packages from that global db, and so will often be a different, and perhaps worse plan (especially if it runs into quirks in the solver). This is discussed on the associated reddit thread here: http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmx9v7 As I proposed on the main email thread, I think it would make sense to make the easy, default option the one which, in sandboxes, effectively ignores the global db for solving. This leads to more duplication and longer build times, but it is safer. However, we should have an easy setting/flag (to be set when initializing a sandbox or any time thereafter) which can switch the preference over to preferring to use already installed versions in the global db. That way, new users can, naively, get a _lot_ of isolation with sandboxes, and those who know what they are doing can opt out in order to reduce duplication of installs and cut down on build times. Addition of a `prefer-global-db` flag and a good default setting for it (i.e., false) seems to me like it would resolve the _central_ issue people have with the platform, and situate us well to unilaterally recommend it as the default install option. Cheers, Gershom From austin at well-typed.com Mon Mar 23 17:50:43 2015 From: austin at well-typed.com (Austin Seipp) Date: Mon, 23 Mar 2015 12:50:43 -0500 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: References: Message-ID: Hi Michael, I actually tried to adopt this patch into 7.10, because I thought it was needed for another dependent patch we wanted. Unfortunately, the backtrace-via-implicit-params patch seems to depend on some prior work by Simon PJ in the typechecker (-fwarn-redundant-constraints, a rather large patch), which we *did not* want in 7.10 (the *textual* diff applied fine, but there were some API changes the backtrace patch needed, so it failed to build). So, in the end, it was easier to surgically remove this patch from the one that depended on it, and it had a much lower 'surface area' of changes, than adopting both. Hope that makes sense. Also, as Simon said, we don't normally do big changes like this in point releases, so I think this is unlikely to happen. So the short story is "afraid not". But a backport should be possible, if you're willing to get your hands a bit dirty (any conflict will likely be fairly easy to fix, but it will involve some textual munging). On Mon, Mar 23, 2015 at 6:49 AM, Michael Snoyman wrote: > It looks like the srcLoc change[1] is something that some of our (FP > Complete's) customers would be quite interested in getting access to sooner > rather than later. Would there be any possibility of getting that patch > merged into the 7.10 branch of GHC? I'm not sure if I'd try my luck at > actually including it in 7.10.1, but would it be on the table for 7.10.2? > > We do of course have the option of backporting it ourselves and including it > in a custom GHC we provide customers, but we generally try to stay as close > to upstream as possible. > > [1] https://ghc.haskell.org/trac/ghc/ticket/9049 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From acowley at gmail.com Mon Mar 23 18:11:16 2015 From: acowley at gmail.com (Anthony Cowley) Date: Mon, 23 Mar 2015 14:11:16 -0400 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <71766C8F-2325-4752-8C24-F7CFB461FB85@gmail.com> Message-ID: <6A4B76BA-498A-4BF2-AE0C-DBAF4AF9AF28@gmail.com> > On Mar 23, 2015, at 1:19 PM, Gershom B wrote: > >> On Mon, Mar 23, 2015 at 11:20 AM, Anthony Cowley wrote: >> >> I don't understand this attitude. You say that neither new users nor package >> authors agree with your stance on the HP, so you want to force their hands. >> Presumably package authors know what they're doing for themselves, and the >> majority of evidence we have is that new users who stick with the language >> do not like the way the HP works >> . > > No, this is not what I said. I was explaining that it rather > difficult, even if we wanted to force their hands, to imagine that we > could do so. I will say that I do not share your belief that package > authors know what they are doing, in general. If they did, I would > imagine that nearly all packages would ensure they would work with the > current platform. But getting programmers to all agree on something > like that is herding cats, and all it takes is a few people saying > "feh on the platform" but nonetheless producing otherwise good > packages that come into widespread use to _in general_ mean that many > packages which directly or indirectly want to use those dependencies > must also now split off from support for the platform. To be clear, I said that package authors know what they are doing for themselves. I don't think they inherently know what is best for beginners, hence the reddit evidence. > > So I agree that people have voted with their feet, and we need to > catch up to that. > > In fact, it seems to me from this discussion that there are only _two_ > things we need to do to make the platform the recommended install path > for all platforms again: > > 1) Incorporate the improvements to windows builds that have been > pioneered by the MinGHC project (in particular so that > platform-installed windows ghc can build the network package properly, > and perhaps even the GL stuff). > > 2) Address the problem that in a sandbox you will get a different > install plan depending on your global package db. I would suggest this > be done by setting a default preference of the sandbox to ignore > global packages, and allow that to be overridden with an easily > configurable flag or setting or the like. That way, new users can pay > the longer compile price for a guaranteed-safer experience, and more > experienced users can choose to use / build up a broader library of > packages they can share across sandboxes. That's a good start, but not enough. For example, Mark's latest platform build shows OpenGL taking up a lot of space. Plenty of users want to install GHC in a server-like environment where this is a waste. But then OpenGL takes a long time (and apparently many gigabytes of RAM) to build, so we'd rather not require that those who want it rebuild it for each project (I've done this, and it's a drag). Now we face the question of having different platforms for different users, which may be acceptable despite the common claim that there should be a single download so as not to burden new users with a difficult choice. Alternately, if we let our installation tools catch up to our needs, we will have an automatic way to upgrade from a minimal installation to a, say, game development environment. That is, a user says "cabal install OpenGL", and it works, makes future rebuilds of OpenGL unlikely, and doesn't interfere with a program that depends on an older version of OpenGL. We can certainly offer kits of packages for specialized needs, but the main thing is to avoid "blessing" any one set of packages such that I'm stuck with a shared global database based on which platform I downloaded back on day 1 with Haskell. I chose OpenGL as an example, but a similarly unpleasant experience awaits potential users of our various web server packages. They are big things to install, and have dependency chains that are always itching for a rumble. These packages are some of our community's best software, the old tooling should be updated to support them. Anthony From afarmer at ittc.ku.edu Mon Mar 23 18:13:41 2015 From: afarmer at ittc.ku.edu (Andrew Farmer) Date: Mon, 23 Mar 2015 13:13:41 -0500 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <71766C8F-2325-4752-8C24-F7CFB461FB85@gmail.com> Message-ID: I think the fact that we now have these minimal installers floating around is evidence that there is demand for that. I personally just download the latest bindist from the GHC site and bootstrap cabal myself. Partly this is because my work requires me to have the latest GHC, so maybe I'm not in the HP's target demographic. That said, I would love if there was a platform that just did that (+ whatever is needed to get that to work). Maybe at the end of the minimal install, give me a choice between stackage and hackage and set the remote-repo in my cabal file appropriately. I was excited by all Mark's (and other's) recent work on the platform, because it sounded like the new build system would allow it to track GHC much more closely. To me, the value of the HP (and why I still recommend it to people) was always that it is a quick way to get ghc + cabal on your system. Have a curated set of recommended packages was neither here nor there (until they get way out of date, as Michael pointed out with aeson 0.6.2.1). Finding good libraries seems like a problem that google + hackage 2 + stackage solves well nowdays. On Mon, Mar 23, 2015 at 12:19 PM, Gershom B wrote: > On Mon, Mar 23, 2015 at 11:20 AM, Anthony Cowley wrote: >> >> I don't understand this attitude. You say that neither new users nor package >> authors agree with your stance on the HP, so you want to force their hands. >> Presumably package authors know what they're doing for themselves, and the >> majority of evidence we have is that new users who stick with the language >> do not like the way the HP works >> . > > No, this is not what I said. I was explaining that it rather > difficult, even if we wanted to force their hands, to imagine that we > could do so. I will say that I do not share your belief that package > authors know what they are doing, in general. If they did, I would > imagine that nearly all packages would ensure they would work with the > current platform. But getting programmers to all agree on something > like that is herding cats, and all it takes is a few people saying > "feh on the platform" but nonetheless producing otherwise good > packages that come into widespread use to _in general_ mean that many > packages which directly or indirectly want to use those dependencies > must also now split off from support for the platform. > > So I agree that people have voted with their feet, and we need to > catch up to that. > > In fact, it seems to me from this discussion that there are only _two_ > things we need to do to make the platform the recommended install path > for all platforms again: > > 1) Incorporate the improvements to windows builds that have been > pioneered by the MinGHC project (in particular so that > platform-installed windows ghc can build the network package properly, > and perhaps even the GL stuff). > > 2) Address the problem that in a sandbox you will get a different > install plan depending on your global package db. I would suggest this > be done by setting a default preference of the sandbox to ignore > global packages, and allow that to be overridden with an easily > configurable flag or setting or the like. That way, new users can pay > the longer compile price for a guaranteed-safer experience, and more > experienced users can choose to use / build up a broader library of > packages they can share across sandboxes. > > (Certainly some "nix-like tricks" in cabal could also help address the > repeated builds problem, but a flag can be implemented much more > quickly as a short-term measure). > > All that said, I think it would _still_ be better if more package > authors paid attention to backwards-compatibility across releases, and > it would _still_ be better for new users if they didn't go off and > bash their heads against the newest and least stable packages around. > But that is indeed a different problem. > > Cheers, > Gershom > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From eric at seidel.io Mon Mar 23 18:14:16 2015 From: eric at seidel.io (Eric Seidel) Date: Mon, 23 Mar 2015 11:14:16 -0700 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: References: Message-ID: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> IIRC the patch doesn't directly depend on -fwarn-redundant-constraints, but I think I ran into some merge conflicts that had to be resolved. I agree with Austin that backporting it should be doable, and would be happy to help if there's interest. Also, I still mean to submit a follow-on patch that uses the new srcLoc infrastructure to add locations to explicitly-failing functions (i.e. error, undefined, and maybe assert). I don't know if this will be palatable to GHC-HQ as it changes base, but I think it's at least a discussion worth having. Unfortunately I got sidetracked by school stuff and haven't had a chance to throw the patch together yet.. On Mon, Mar 23, 2015, at 10:50, Austin Seipp wrote: > Hi Michael, > > I actually tried to adopt this patch into 7.10, because I thought it > was needed for another dependent patch we wanted. Unfortunately, the > backtrace-via-implicit-params patch seems to depend on some prior work > by Simon PJ in the typechecker (-fwarn-redundant-constraints, a rather > large patch), which we *did not* want in 7.10 (the *textual* diff > applied fine, but there were some API changes the backtrace patch > needed, so it failed to build). So, in the end, it was easier to > surgically remove this patch from the one that depended on it, and it > had a much lower 'surface area' of changes, than adopting both. Hope > that makes sense. > > Also, as Simon said, we don't normally do big changes like this in > point releases, so I think this is unlikely to happen. > > So the short story is "afraid not". But a backport should be possible, > if you're willing to get your hands a bit dirty (any conflict will > likely be fairly easy to fix, but it will involve some textual > munging). > > On Mon, Mar 23, 2015 at 6:49 AM, Michael Snoyman > wrote: > > It looks like the srcLoc change[1] is something that some of our (FP > > Complete's) customers would be quite interested in getting access to sooner > > rather than later. Would there be any possibility of getting that patch > > merged into the 7.10 branch of GHC? I'm not sure if I'd try my luck at > > actually including it in 7.10.1, but would it be on the table for 7.10.2? > > > > We do of course have the option of backporting it ourselves and including it > > in a custom GHC we provide customers, but we generally try to stay as close > > to upstream as possible. > > > > [1] https://ghc.haskell.org/trac/ghc/ticket/9049 > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mietek at bak.io Mon Mar 23 18:17:11 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Mon, 23 Mar 2015 18:17:11 +0000 Subject: [haskell-infrastructure] wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <71766C8F-2325-4752-8C24-F7CFB461FB85@gmail.com> Message-ID: On 2015-03-23, at 18:13, Andrew Farmer wrote: > I personally just download the latest bindist from the GHC site and > bootstrap cabal myself. Partly this is because my work requires me to > have the latest GHC, so maybe I'm not in the HP's target demographic. > That said, I would love if there was a platform that just did that (+ > whatever is needed to get that to work). Maybe at the end of the > minimal install, give me a choice between stackage and hackage and set > the remote-repo in my cabal file appropriately. I?m happy to say `halcyon install --cabal-remote-repo=?` does just that. See the Halcyon tutorial and reference for details: https://halcyon.sh/tutorial/#install-ghc-and-cabal https://halcyon.sh/reference/#halcyon_cabal_remote_repo -- Mi?tek https://mietek.io -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From simonpj at microsoft.com Mon Mar 23 20:13:53 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Mar 2015 20:13:53 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net>, Message-ID: <1427141632771.55413@microsoft.com> But I'm hazy about why sandboxes are needed at all. As I understand it, they were invented to solve the very problem that is now solved (if only Cabal could take advantage of it). Simon ________________________________________ From: Gershom B Sent: 23 March 2015 17:31 To: Simon Peyton Jones Cc: cabal-devel at haskell.org; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Haskell Libraries; ghc-devs at haskell.org Subject: Re: Cabal and simultaneous installations of the same package On Mon, Mar 23, 2015 at 4:45 AM, Simon Peyton Jones wrote: > > | Another thing we should fix is the (now false) impression that HP gets in > | the way of installing other packages and versions due to cabal hell. > > People mean different things by "cabal hell", but the inability to > simultaneously install multiple versions of the same package, > compiled against different dependencies > is certainly one of them, and I think it is the one that Yitzchak is referring to here. My understanding is that the problem Yitz is discussing is much more straightforward and easy to fix. The issue is that if I have an "empty" global package db and enter a sandbox and cabal-install something, then I will get one package install plan. But if I have a "well populated" package db, then attempt to cabal-install something in the sandbox, the plan will attempt to use the packages from that global db, and so will often be a different, and perhaps worse plan (especially if it runs into quirks in the solver). This is discussed on the associated reddit thread here: http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/cpmx9v7 As I proposed on the main email thread, I think it would make sense to make the easy, default option the one which, in sandboxes, effectively ignores the global db for solving. This leads to more duplication and longer build times, but it is safer. However, we should have an easy setting/flag (to be set when initializing a sandbox or any time thereafter) which can switch the preference over to preferring to use already installed versions in the global db. That way, new users can, naively, get a _lot_ of isolation with sandboxes, and those who know what they are doing can opt out in order to reduce duplication of installs and cut down on build times. Addition of a `prefer-global-db` flag and a good default setting for it (i.e., false) seems to me like it would resolve the _central_ issue people have with the platform, and situate us well to unilaterally recommend it as the default install option. Cheers, Gershom From duncan.coutts at googlemail.com Mon Mar 23 22:07:32 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:07:32 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <1427148452.11324.439.camel@dunky.localdomain> On Mon, 2015-03-23 at 08:45 +0000, Simon Peyton Jones wrote: > Dear Cabal developers > > You'll probably have seen the thread about the Haskell Platform. > > Among other things, this point arose: > > | Another thing we should fix is the (now false) impression that HP gets in > | the way of installing other packages and versions due to cabal hell. > > People mean different things by "cabal hell", but the inability to > simultaneously install multiple versions of the same package, > compiled against different dependencies > is certainly one of them, and I think it is the one that Yitzchak is referring to here. > > But some time now GHC has allowed multiple versions of the same > package (compiled against different dependencies) to be installed > simultaneously. That's technically true of existing ghc versions, though ghc-pkg does not directly allow registering multiple instances of the same version of a package. As of 7.10 we can actually use ghc-pkg to register multiple instances, using ghc-pkg register --enable-multi-instance Also since 7.10 we can have "environment" files that say what packages to expose. There can be a per-user default one, or per-user named ones (which can be used via the ghc command line or via env var), or local environments in a directory. While Cabal has always built things with consistent deps and solved the problem of "which ByteString do I mean", the same has not been true for GHCi. With this new environment mechanism Cabal can create the environments and then when the user runs ghc/ghci then they get the set of packages previously set up by Cabal. Elsewhere in this thread you say: > What you want is for the confusing behaviour to be true of GHCi too. > Well that?s simple enough: ensure that the set of exposed packages (ie > the ones you say ?import M? for), is consistent in the same way. The > point is that I may need to install a bunch of packages to build a > program. If I?m using Cabal, none of those newly installed packages > need be exposed; I simply need them there so I can compile my program > (using Cabal). But at the moment I can?t do that. Yes, that is exactly what these environment files are intended for. Myself and Edsko implemented these features (for the IHG) to enable future Cabal versions to take the multi instance approach fully. > So all we need to do is to fix Cabal to allow it too, and thereby kill > of a huge class of cabal-hell problems at one blow. With these features now implemented in GHC we're in a position to turn attention to Cabal to make use of them. > But time has passed and it hasn't happened. Is this because I'm > misunderstanding? Or because it is harder than I think? Or because > there are much bigger problems? Or because there is insufficient > effort available? Or what? There's a number of parts remaining to do. > Unless I'm way off beam, this "multiple installations of the same > package" thing has been a huge pain forever, and the solution is > within our grasp. What's stopping us grasping it? Yes, we're closer than ever. I covered more of the details in this blog post: http://www.well-typed.com/blog/preview/how-we-might-abolish-cabal-hell-2/ So some of the remaining parts: Cabal needs to assign proper installed package ids, like nix does. These should be based on the hash of all inputs to a package build. In particular that means a hash of the content of the sources. This is easy for tarballs but a bit harder to do accurately for unpacked build trees. There are some new UI issues to deal with. The user interface will have to make this issue of multiple consistent environments be explicit in the user interface. We need to know what env we are in, what is in it, what other envs are available and be able to switch between them. Suppose that we enforce that each environment be fully consistent. Then when I "cabal install Q" and it cannot find a solution to install everything in the current environment plus the one extra package such that they all have consistent deps, then what should it do? Suppose that Q really could be installed on its own, but cannot be installed consistently with the other things in this env. Should it suggest that you make a new environment? There are some details to work out here so that we don't make a confusing UI. There's also an unresolved issue about when we try to reuse existing installed dependencies. One approach is to say that we make install plans without considering what is already available in the package store, and then only re-use existing ones if the installed package Ids happen to match up. The other approach is to say that the solver should actively try to reuse installed instances when it can. The latter is what we do now, to try and reduce the number of reinstalls. But when there are dozens of versions available this is harder: we need to know more information to know if it is safe to re-use an existing instance. (There are examples where it's clearly not safe to reuse packages.) Or a pragmatic approach might be to try and reuse existing installed instances within the current environment but not actively try to reuse other instances available in the package store. On a related topic, along with the London HUG we're trying to organise a couple infrastructure hackathons in London. The aim would be to work on Cabal/Hackage related things. The plan is to have two hackathons 6-8 weeks apart, to get new people set up with projects at the first and to get things merged in the second. For Cabal, this project would be my focus, trying to get people to work on different aspects of it. I gave a talk at the London HUG recently about getting involved with hacking on Cabal/Hackage. Duncan From duncan.coutts at googlemail.com Mon Mar 23 22:10:09 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:10:09 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <1427141632771.55413@microsoft.com> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> , <1427141632771.55413@microsoft.com> Message-ID: <1427148609.11324.441.camel@dunky.localdomain> On Mon, 2015-03-23 at 20:13 +0000, Simon Peyton Jones wrote: > But I'm hazy about why sandboxes are needed at all. As I understand > it, they were invented to solve the very problem that is now solved > (if only Cabal could take advantage of it). Yes, the nix approach would subsume sandboxes. I cover this in this post http://www.well-typed.com/blog/preview/how-we-might-abolish-cabal-hell-2/ Duncan From duncan.coutts at googlemail.com Mon Mar 23 22:18:57 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:18:57 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: <1427149137.11324.444.camel@dunky.localdomain> On Sun, 2015-03-22 at 09:17 +0000, Neil Mitchell wrote: > On Windows, the reason I used to use the Platform was that it came > with an installed network library, and installing the network library > on Windows is a real pain (and often fails). Unfortunately it was > incredibly brittle, a single attempt at upgrading network from some > newer package usually trashed my Haskell install and required a wipe > and restart. > > Nowadays I use https://github.com/fpco/minghc which can actually > install network, and I've had zero problems. Can we just include this fix into the platform installers? As Mark says, the Platform has decent automated build & test infrastructure so it shouldn't be that hard. As I understand it the network problem is just to do with how much of mingwin we include and not really related to "min" vs "max" installers. Duncan From duncan.coutts at googlemail.com Mon Mar 23 22:24:43 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:24:43 +0000 Subject: wither the Platform In-Reply-To: <87h9tdpder.fsf@gnu.org> References: <87h9tdpder.fsf@gnu.org> Message-ID: <1427149483.11324.447.camel@dunky.localdomain> On Sun, 2015-03-22 at 10:52 +0100, Herbert Valerio Riedel wrote: > My biggest complaint about the current HP is that it pollutes the global > package database with additional packages which leak into `cabal > sandbox`es. This causes `cabal sandbox` to provide quite different > sandbox environments for HP environments compared to a non-HP > environment without those additional packages pre-installed. > > Currently GHC/Cabal knows about a global package db and a user package > db (the user pkg db is is what gets replaced/shadowed by cabal > sandboxes). Maybe we need a 3rd package db sitting between the global > and the user package db that interacts better with cabal sandboxes? I think this is a good idea. As far as I can see there's no conflict between the advocates of mini and maxi installers (as aimed at new users) except for this behaviour of new sandboxes. All we need to do is make "cabal sandbox init" start with a minimal package set, rather than taking the global package db. It's true that the ghc/platform installers could help with this, e.g. by shipping an environment file (a new 7.10 feature) that lists all the core packages, and cabal-install could use this as a basis for new sandboxes. Duncan From ndmitchell at gmail.com Mon Mar 23 22:28:43 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon, 23 Mar 2015 22:28:43 +0000 Subject: wither the Platform In-Reply-To: <1427149137.11324.444.camel@dunky.localdomain> References: <1427149137.11324.444.camel@dunky.localdomain> Message-ID: >> Nowadays I use https://github.com/fpco/minghc which can actually >> install network, and I've had zero problems. > > Can we just include this fix into the platform installers? Yes. MinGHC was an experiment in seeing if we could do a Windows installer that worked with Network. We can, so the platform should. However, MinGHC has a few other advantages. It provides a switcher so you can put all the switchers on your PATH and type "minghc-7.8.3" to get that version of GHC selected. Again, the platform could gain that feature. MinGHC also ships with GHC 7.2, 7.4, 7.6 and 7.8. Hopefully as soon as 7.10 is out within days we'll have a MinGHC for it. I'd also really like to start shipping MinGHC installers for GHC release candidates and even nightly GHC release candidates. > As Mark says, > the Platform has decent automated build & test infrastructure so it > shouldn't be that hard. As I understand it the network problem is just > to do with how much of mingwin we include and not really related to > "min" vs "max" installers. Indeed, it has nothing to do with how many packages are shipped. As long as my installer ships with enough to install the packages I care about, then I don't care about min vs max. That said, all I really care is what GHC the platform includes, everything else is redundant (to me). As such having a link to a platform with each GHC version would be handy. Thanks, Neil From duncan.coutts at googlemail.com Mon Mar 23 22:33:15 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:33:15 +0000 Subject: Cabal and simultaneous installations of the same package In-Reply-To: <1427148609.11324.441.camel@dunky.localdomain> References: <68326f3ebbd943768effe6b0f2ff522c@DB4PR30MB030.064d.mgd.msft.net> , <1427141632771.55413@microsoft.com> <1427148609.11324.441.camel@dunky.localdomain> Message-ID: <1427149995.11324.448.camel@dunky.localdomain> On Mon, 2015-03-23 at 22:10 +0000, Duncan Coutts wrote: > On Mon, 2015-03-23 at 20:13 +0000, Simon Peyton Jones wrote: > > But I'm hazy about why sandboxes are needed at all. As I understand > > it, they were invented to solve the very problem that is now solved > > (if only Cabal could take advantage of it). > > Yes, the nix approach would subsume sandboxes. > > I cover this in this post > http://www.well-typed.com/blog/preview/how-we-might-abolish-cabal-hell-2/ Oops, permanent link: http://www.well-typed.com/blog/2015/01/how-we-might-abolish-cabal-hell-part-2/ From duncan.coutts at googlemail.com Mon Mar 23 22:51:17 2015 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Mon, 23 Mar 2015 22:51:17 +0000 Subject: wither the Platform In-Reply-To: References: Message-ID: <1427151077.11324.459.camel@dunky.localdomain> On Sat, 2015-03-21 at 10:54 -0700, Mark Lentczner wrote: > I'm wondering how we are all feeling about the platform these days.... > > I notice that in the new Haskell pages, the Platform is definitely not the > recommended way to go: The main download pages suggests the compiler and > base libraries as the first option - and the text for the Platform (second > option) pretty much steers folks away from it. Of the per-OS download > pages, only the Windows version even mentions it. There was a big argument about this. I was on the loosing side. :-) > Does this mean that we don't want to consider continuing with it? It is a > lot of community effort to put out a Platform release - we shouldn't do it > if we don't really want it. I think it is worth it, and the issues that people are complaining about wrt the platform vs minimal installers can be fixed. > That said, I note that the other ways to "officially get" Haskell look, to > my eye, very ad hoc. Many of the options involve multiple steps, and > exactly what one is getting isn't clear. It hardly looks like there is now > an "official, correct" way to setup Haskell. Right, I think there's still a great deal of value in having a simple recommendation for new users. One of the points of argument was that some people were arguing that the minimal installers are better for new users. I disagree, but certainly there is one issue that could be fixed that'd go a long way to resolving the particular use case with new users that was raised. > The Platform arose in an era before sandboxes and before curated library > sets like Stackage and LTS. Last time we set direction was several years > ago. These new features and development have clearly changed the landscape > for use to reconsider what to do. > I don't think the status quo for the Platform is now viable - mostly as > evidenced by waning interest in maintaining it. I offer several ways we > could proceed: Well, the people who like it don't really complain. But yes, things need improving. > *1) Abandon the Platform.* GHC is release in source and binary form. Other > package various installers, with more or less things, for various OSes. > > *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > "essential" libs + tools. Keeps a consistent build layout and installation > mechanism for Haskell. > > *3) Re-conceive the Platform.* Take a very minimal install approach, > coupled with close integration with a curated library set that makes it > easy to have a rich canonical, stable environment. This was the core idea > around my "GPS Haskell" thoughts from last September - but there would be > much to work out in this direction. I'm not sure that slimming is really needed. But I agree with the GPS approach. The current set is too small in the sense that it doesn't cover lots of things people need, and the GPS approach should solve that. We don't need to promise such high QA for the extended set, we just need to make sure they build together. We need to remember that one of the purposes of the platform as originally conceived is to get people to sync on the versions of their deps that they're using at the moment. This is where the GPS approach shines, but it still makes sense to have some core set at the middle of that. It's true that advanced users don't need lots of things pre-installed, but they sill benefit from other developers synchronising on versions of deps, so that they can have more things work together more often. On the argument that the platform is too big, the primary issue there is that people want to make new sandboxes that are more minimal, and with cabal's current behaviour of basing all sandboxes off of the global package db, and the platform installing lots of packages globally then we get a conflict. But the solution is simple: make cabal sandboxes not be based off of everything that is globally installed, make new sandboxes be really minimal (though the ghc/platform installers could help with identifying what is the minimal subset). Duncan From M.W.Wang at kent.ac.uk Tue Mar 24 00:18:24 2015 From: M.W.Wang at kent.ac.uk (Meng Wang) Date: Tue, 24 Mar 2015 00:18:24 +0000 Subject: hackage statistics Message-ID: <717AE6A6-E678-419E-A1E3-61CA88F0F4C9@kent.ac.uk> Hi All, A few of us are writing a survey of FP and would like to include some statistic graphs of Haskell (similar to those found here:http://galois.com/blog/2009/03/one-million-haskell-downloads/). Does anyone know how I can obtain such data? Thank you very much, Meng -------------- next part -------------- An HTML attachment was scrubbed... URL: From davean at xkcd.com Tue Mar 24 04:33:11 2015 From: davean at xkcd.com (davean) Date: Tue, 24 Mar 2015 00:33:11 -0400 Subject: wither the Platform In-Reply-To: References: <4acea26ce9484f7aa686d7f945ac85dd@DB4PR30MB030.064d.mgd.msft.net> <2A5B6DD1-4F30-4386-83F2-1F58DDE9051E@cis.upenn.edu> Message-ID: > > I didn't have that problem with Python or Clojure. I didn't run into > it with Python until I was building enterprise-class systems. I ran > into other issues that made me drop Clojure before I ran into this > one. > Well, it also was standard python practice to monkey patch the libraries to fix deficiencies, like the inability to call "PUT" with the standard HTTP lib. Where as I see people picking the right X library to have a style of programming that makes their code easy to follow in Haskell instead of "just making it work". Now I probably see a highly non-random selection of programmer's work in Haskell. I'd say what I see is not what you propose at all though. I see 2 or 3 HTTP client libs used in the same (large-ish) project even, because each of them has different code it makes easier and prettier. One of Haskell's attraction to me is the work done in selecting good abstractions and approaches to problems refining the method used. This will inherently lead to diversity. Sometimes its bad. but its part of not just getting the job done, but instead trying to do it better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Tue Mar 24 06:49:20 2015 From: lonetiger at gmail.com (=?utf-8?Q?Tamar_Christina?=) Date: Tue, 24 Mar 2015 06:49:20 +0000 Subject: =?utf-8?Q?build_system/default_targets_question?= Message-ID: <5511093f.2764c20a.5dd7.7aac@mx.google.com> Hi All, I'm trying to figure out the build system, but can't figure out why this isn't working: In the driver folder I created a new folder "ghc-split". The content of that is: -rw-r--r-- 1 Tamar Users 784 Mar 22 13:18 ghc.mk -rw-r--r-- 1 Tamar Users 513 Mar 15 11:40 ghc-split.cabal -rw-r--r-- 1 Tamar Users 1611 Mar 15 07:30 LICENSE -rw-r--r-- 1 Tamar Users 2162 Mar 15 07:51 Main.lhs -rw-r--r-- 1 Tamar Users 518 Mar 22 11:45 Makefile My Makefile contains: dir = driver/ghc-split TOP = ../.. include $(TOP)/mk/sub-makefile.mk and my ghc.mk: driver/ghc-split_USES_CABAL = YES driver/ghc-split_PACKAGE = ghc-split driver/ghc-split_dist-install_INSTALL = YES driver/ghc-split_dist-install_PROGNAME = ghc-split driver/ghc-split_dist-install_INSTALL_INPLACE = YES driver/ghc-split_dist-install_WANT_BINDIST_WRAPPER = YES $(eval $(call build-prog,driver/ghc-split,dist-install,0)) From https://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/StandardTargets I gather that this should work under the standard target make all_driver/ghc-split_dist-install, however when I do a make I get: make[2]: *** No rule to make target 'all_driver/ghc-split'. Stop. Makefile:72: recipe for target 'all_driver/ghc-split' failed make[1]: *** [all_driver/ghc-split] Error 2 make[1]: Leaving directory '/home/Tamar/ghc2' ../../mk/sub-makefile.mk:45: recipe for target 'all' failed make: *** [all] Error 2 and I haven't been able to figure out why.. Any thoughts? Regards, Tamar ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Tue Mar 24 07:00:02 2015 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 24 Mar 2015 07:00:02 +0000 Subject: Backporting srcLoc to the GHC 7.10 branch In-Reply-To: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> References: <1427134456.180256.244160054.58D3091A@webmail.messagingengine.com> Message-ID: Thanks for the feedback everyone. If/when we decide to backport the patch, we'll be sure to make the commit available for others interested in running a custom build of GHC. And thank you for the offer of help Eric, it's much appreciated :) On Mon, Mar 23, 2015 at 8:14 PM Eric Seidel wrote: > IIRC the patch doesn't directly depend on -fwarn-redundant-constraints, > but I think I ran into some merge conflicts that had to be resolved. I > agree with Austin that backporting it should be doable, and would be > happy to help if there's interest. > > Also, I still mean to submit a follow-on patch that uses the new srcLoc > infrastructure to add locations to explicitly-failing functions (i.e. > error, undefined, and maybe assert). I don't know if this will be > palatable to GHC-HQ as it changes base, but I think it's at least a > discussion worth having. Unfortunately I got sidetracked by school stuff > and haven't had a chance to throw the patch together yet.. > > On Mon, Mar 23, 2015, at 10:50, Austin Seipp wrote: > > Hi Michael, > > > > I actually tried to adopt this patch into 7.10, because I thought it > > was needed for another dependent patch we wanted. Unfortunately, the > > backtrace-via-implicit-params patch seems to depend on some prior work > > by Simon PJ in the typechecker (-fwarn-redundant-constraints, a rather > > large patch), which we *did not* want in 7.10 (the *textual* diff > > applied fine, but there were some API changes the backtrace patch > > needed, so it failed to build). So, in the end, it was easier to > > surgically remove this patch from the one that depended on it, and it > > had a much lower 'surface area' of changes, than adopting both. Hope > > that makes sense. > > > > Also, as Simon said, we don't normally do big changes like this in > > point releases, so I think this is unlikely to happen. > > > > So the short story is "afraid not". But a backport should be possible, > > if you're willing to get your hands a bit dirty (any conflict will > > likely be fairly easy to fix, but it will involve some textual > > munging). > > > > On Mon, Mar 23, 2015 at 6:49 AM, Michael Snoyman > > wrote: > > > It looks like the srcLoc change[1] is something that some of our (FP > > > Complete's) customers would be quite interested in getting access to > sooner > > > rather than later. Would there be any possibility of getting that patch > > > merged into the 7.10 branch of GHC? I'm not sure if I'd try my luck at > > > actually including it in 7.10.1, but would it be on the table for > 7.10.2? > > > > > > We do of course have the option of backporting it ourselves and > including it > > > in a custom GHC we provide customers, but we generally try to stay as > close > > > to upstream as possible. > > > > > > [1] https://ghc.haskell.org/trac/ghc/ticket/9049 > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > > > > > -- > > Regards, > > > > Austin Seipp, Haskell Consultant > > Well-Typed LLP, http://www.well-typed.com/ > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Tue Mar 24 08:59:40 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Tue, 24 Mar 2015 09:59:40 +0100 Subject: build system/default targets question In-Reply-To: <5511093f.2764c20a.5dd7.7aac@mx.google.com> References: <5511093f.2764c20a.5dd7.7aac@mx.google.com> Message-ID: It looks like other subdirectories are all added to the `BUILD_DIRS` variable in the toplevel ghc.mk. Did you do that? Please update the wiki if that was indeed the missing step. Otherwise, try the debugging hints on this page: https://ghc.haskell.org/trac/ghc/wiki/Building/Modifying On Tue, Mar 24, 2015 at 7:49 AM, Tamar Christina wrote: > Hi All, > > I'm trying to figure out the build system, but can't figure out why this > isn't working: > > In the driver folder I created a new folder "ghc-split". The content of > that is: > -rw-r--r-- 1 Tamar Users 784 Mar 22 13:18 ghc.mk > -rw-r--r-- 1 Tamar Users 513 Mar 15 11:40 ghc-split.cabal > -rw-r--r-- 1 Tamar Users 1611 Mar 15 07:30 LICENSE > -rw-r--r-- 1 Tamar Users 2162 Mar 15 07:51 Main.lhs > -rw-r--r-- 1 Tamar Users 518 Mar 22 11:45 Makefile > > My Makefile contains: > > dir = driver/ghc-split > TOP = ../.. > include $(TOP)/mk/sub-makefile.mk > > and my ghc.mk: > > driver/ghc-split_USES_CABAL = YES > driver/ghc-split_PACKAGE = ghc-split > driver/ghc-split_dist-install_INSTALL = YES > driver/ghc-split_dist-install_PROGNAME = ghc-split > driver/ghc-split_dist-install_INSTALL_INPLACE = YES > driver/ghc-split_dist-install_WANT_BINDIST_WRAPPER = YES > > $(eval $(call build-prog,driver/ghc-split,dist-install,0)) > > From > https://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/StandardTargets > I gather that this should > work under the standard target make all_driver/ghc-split_dist-install, > however when I do a make I get: > > make[2]: *** No rule to make target 'all_driver/ghc-split'. Stop. > Makefile:72: recipe for target 'all_driver/ghc-split' failed > make[1]: *** [all_driver/ghc-split] Error 2 > make[1]: Leaving directory '/home/Tamar/ghc2' > ../../mk/sub-makefile.mk:45: recipe for target 'all' failed > make: *** [all] Error 2 > > and I haven't been able to figure out why.. > Any thoughts? > > Regards, > Tamar > ? > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From komadori at gekkou.co.uk Tue Mar 24 10:12:47 2015 From: komadori at gekkou.co.uk (Robin KAY) Date: Tue, 24 Mar 2015 10:12:47 +0000 Subject: hackage statistics In-Reply-To: <717AE6A6-E678-419E-A1E3-61CA88F0F4C9@kent.ac.uk> References: <717AE6A6-E678-419E-A1E3-61CA88F0F4C9@kent.ac.uk> Message-ID: <1427191967.3188842.244460638.474628B5@webmail.messagingengine.com> Dear Meng, Meng Wang wrote: [snip] > A few of us are writing a survey of FP and would like to include some > statistic graphs of Haskell (similar to those found > here:http://galois.com/blog/2009/03/one-million-haskell-downloads/). > Does anyone know how I can obtain such data? I have obtained this information before and I used, AFAICR, the web-service URL http://hackage.haskell.org/packages/downloads as described on the API page: http://hackage.haskell.org/api#download However, when I tried it just now it requested my Hackage credentials and then gave me a 403 Forbidden error. The file was quite large, nearly 100 MB when I downloaded it last August, and it can only grow bigger so perhaps it has been disabled for that reason? BTW, ghc-devs is probably the wrong list for this topic. Try -cafe? Regards, -- Robin KAY http://www.gekkou.co.uk/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Tue Mar 24 20:21:09 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 24 Mar 2015 15:21:09 -0500 Subject: Note: please write down your tentative plans for GHC 7.12 Message-ID: Hi *, I plan on shipping GHC 7.10.1 Real Soon Now (a bit later today). In light of this - we should think about what we want to get done for 7.12! I've set up a new status page about GHC 712. It's got a lot of tickets on it; I'll probably prune them later: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.12.1 At the top, you can see a list of tentative plans for what we want to implement. This list is short and I'm surely missing some things (for example - Edward, what might be on the Backpack roadmap? Worth mentioning?) Please feel free to add to this list liberally - I'll be reusing it for the 2015 HCAR, which will be due in a month or so. Thanks all, and happy hacking. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From chak at cse.unsw.edu.au Wed Mar 25 00:13:52 2015 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed, 25 Mar 2015 11:13:52 +1100 Subject: wither the Platform In-Reply-To: <1427151077.11324.459.camel@dunky.localdomain> References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: > Duncan Coutts : > On Sat, 2015-03-21 at 10:54 -0700, Mark Lentczner wrote: >> I'm wondering how we are all feeling about the platform these days.... >> >> I notice that in the new Haskell pages, the Platform is definitely not the >> recommended way to go: The main download pages suggests the compiler and >> base libraries as the first option - and the text for the Platform (second >> option) pretty much steers folks away from it. Of the per-OS download >> pages, only the Windows version even mentions it. > > There was a big argument about this. I was on the loosing side. :-) > >> Does this mean that we don't want to consider continuing with it? It is a >> lot of community effort to put out a Platform release - we shouldn't do it >> if we don't really want it. > > I think it is worth it, and the issues that people are complaining about > wrt the platform vs minimal installers can be fixed. > >> That said, I note that the other ways to "officially get" Haskell look, to >> my eye, very ad hoc. Many of the options involve multiple steps, and >> exactly what one is getting isn't clear. It hardly looks like there is now >> an "official, correct" way to setup Haskell. > > Right, I think there's still a great deal of value in having a simple > recommendation for new users. Absolutely! The recurring problem with decisions like the one about the recommended installers on the Haskell front page is that they are made by power users who simply lack the perspective to understand the requirements of new users. A minimal installer followed by half an hour of cabal install is an extremely bad way to sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers. We are using Haskell in a few courses here at UNSW. We always recommend students to use the Haskell Platform when they want to install Haskell on their own machines. It?s one download and gives them the same packages on all platforms. Anything else just leads to lots of support questions of students trying to get their installations working to do their assignments. Manuel > One of the points of argument was that some people were arguing that the > minimal installers are better for new users. I disagree, but certainly > there is one issue that could be fixed that'd go a long way to resolving > the particular use case with new users that was raised. > >> The Platform arose in an era before sandboxes and before curated library >> sets like Stackage and LTS. Last time we set direction was several years >> ago. These new features and development have clearly changed the landscape >> for use to reconsider what to do. > >> I don't think the status quo for the Platform is now viable - mostly as >> evidenced by waning interest in maintaining it. I offer several ways we >> could proceed: > > Well, the people who like it don't really complain. But yes, things need > improving. > >> *1) Abandon the Platform.* GHC is release in source and binary form. Other >> package various installers, with more or less things, for various OSes. >> >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of >> "essential" libs + tools. Keeps a consistent build layout and installation >> mechanism for Haskell. >> >> *3) Re-conceive the Platform.* Take a very minimal install approach, >> coupled with close integration with a curated library set that makes it >> easy to have a rich canonical, stable environment. This was the core idea >> around my "GPS Haskell" thoughts from last September - but there would be >> much to work out in this direction. > > I'm not sure that slimming is really needed. But I agree with the GPS > approach. The current set is too small in the sense that it doesn't > cover lots of things people need, and the GPS approach should solve > that. We don't need to promise such high QA for the extended set, we > just need to make sure they build together. > > We need to remember that one of the purposes of the platform as > originally conceived is to get people to sync on the versions of their > deps that they're using at the moment. This is where the GPS approach > shines, but it still makes sense to have some core set at the middle of > that. It's true that advanced users don't need lots of things > pre-installed, but they sill benefit from other developers synchronising > on versions of deps, so that they can have more things work together > more often. > > On the argument that the platform is too big, the primary issue there is > that people want to make new sandboxes that are more minimal, and with > cabal's current behaviour of basing all sandboxes off of the global > package db, and the platform installing lots of packages globally then > we get a conflict. > > But the solution is simple: make cabal sandboxes not be based off of > everything that is globally installed, make new sandboxes be really > minimal (though the ghc/platform installers could help with identifying > what is the minimal subset). > > Duncan > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From carter.schonwald at gmail.com Wed Mar 25 00:54:35 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 24 Mar 2015 20:54:35 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: I absolutely agree that haskell platform is the right choice for class rooms. On Mar 24, 2015 8:14 PM, "Manuel M T Chakravarty" wrote: > > Duncan Coutts : > > On Sat, 2015-03-21 at 10:54 -0700, Mark Lentczner wrote: > >> I'm wondering how we are all feeling about the platform these days.... > >> > >> I notice that in the new Haskell pages, the Platform is definitely not > the > >> recommended way to go: The main download pages suggests the compiler and > >> base libraries as the first option - and the text for the Platform > (second > >> option) pretty much steers folks away from it. Of the per-OS download > >> pages, only the Windows version even mentions it. > > > > There was a big argument about this. I was on the loosing side. :-) > > > >> Does this mean that we don't want to consider continuing with it? It is > a > >> lot of community effort to put out a Platform release - we shouldn't do > it > >> if we don't really want it. > > > > I think it is worth it, and the issues that people are complaining about > > wrt the platform vs minimal installers can be fixed. > > > >> That said, I note that the other ways to "officially get" Haskell look, > to > >> my eye, very ad hoc. Many of the options involve multiple steps, and > >> exactly what one is getting isn't clear. It hardly looks like there is > now > >> an "official, correct" way to setup Haskell. > > > > Right, I think there's still a great deal of value in having a simple > > recommendation for new users. > > Absolutely! The recurring problem with decisions like the one about the > recommended installers on the Haskell front page is that they are made by > power users who simply lack the perspective to understand the requirements > of new users. > > A minimal installer followed by half an hour of cabal install is an > extremely bad way to sell Haskell to a newcomer. Sure, it is more flexible, > but flexible is *bad* for newcomers. > > We are using Haskell in a few courses here at UNSW. We always recommend > students to use the Haskell Platform when they want to install Haskell on > their own machines. It?s one download and gives them the same packages on > all platforms. Anything else just leads to lots of support questions of > students trying to get their installations working to do their assignments. > > Manuel > > > One of the points of argument was that some people were arguing that the > > minimal installers are better for new users. I disagree, but certainly > > there is one issue that could be fixed that'd go a long way to resolving > > the particular use case with new users that was raised. > > > >> The Platform arose in an era before sandboxes and before curated library > >> sets like Stackage and LTS. Last time we set direction was several years > >> ago. These new features and development have clearly changed the > landscape > >> for use to reconsider what to do. > > > >> I don't think the status quo for the Platform is now viable - mostly as > >> evidenced by waning interest in maintaining it. I offer several ways we > >> could proceed: > > > > Well, the people who like it don't really complain. But yes, things need > > improving. > > > >> *1) Abandon the Platform.* GHC is release in source and binary form. > Other > >> package various installers, with more or less things, for various OSes. > >> > >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > >> "essential" libs + tools. Keeps a consistent build layout and > installation > >> mechanism for Haskell. > >> > >> *3) Re-conceive the Platform.* Take a very minimal install approach, > >> coupled with close integration with a curated library set that makes it > >> easy to have a rich canonical, stable environment. This was the core > idea > >> around my "GPS Haskell" thoughts from last September - but there would > be > >> much to work out in this direction. > > > > I'm not sure that slimming is really needed. But I agree with the GPS > > approach. The current set is too small in the sense that it doesn't > > cover lots of things people need, and the GPS approach should solve > > that. We don't need to promise such high QA for the extended set, we > > just need to make sure they build together. > > > > We need to remember that one of the purposes of the platform as > > originally conceived is to get people to sync on the versions of their > > deps that they're using at the moment. This is where the GPS approach > > shines, but it still makes sense to have some core set at the middle of > > that. It's true that advanced users don't need lots of things > > pre-installed, but they sill benefit from other developers synchronising > > on versions of deps, so that they can have more things work together > > more often. > > > > On the argument that the platform is too big, the primary issue there is > > that people want to make new sandboxes that are more minimal, and with > > cabal's current behaviour of basing all sandboxes off of the global > > package db, and the platform installing lots of packages globally then > > we get a conflict. > > > > But the solution is simple: make cabal sandboxes not be based off of > > everything that is globally installed, make new sandboxes be really > > minimal (though the ghc/platform installers could help with identifying > > what is the minimal subset). > > > > Duncan > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Wed Mar 25 02:21:39 2015 From: austin at well-typed.com (Austin Seipp) Date: Tue, 24 Mar 2015 21:21:39 -0500 Subject: GHC Weekly News - 2015/03/24 Message-ID: (This post is available online with hyperlinks at https://ghc.haskell.org/trac/ghc/blog/weekly20150324) Hi *, It's time for the GHC weekly news. We've had an absence of the last one, mostly due to a lot of hustle to try and get 7.10 out the door (more on that shortly throughout this post). But now we're back and everything seems to be taken care of. This week, in the wake of the GHC 7.10 release (which is occuring EOD, hopefully), GHC HQ met up for a brief chat and caught up: - This week GHC HQ met for only a very short time to discuss the pending release - it looks like all the blocking bugs have been fixed, and we've got everything triaged appropriately. You'll hopefully see the 7.10 announcement shortly after reading this. We've also had small amounts of list activity (the past 6-8 weeks have been very, very quiet it seems): - Your editor sent out a call for developers to fill information in on the Status page about what they plan to do. If you're working on something, please add it there! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008661.html - Herbert Valerio Riedel asked about a possible regression regarding identifiers containing unicode subscripts - but nobody has replied! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008503.html - Doug Burke chimed in as a new contributor and wrote down some notes on what it took to write his first patch and submit it to us - and we really appreciate the feedback, Doug! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008526.html - Yitzchak Gale revived a thread he started a while back, which puttered out: bootstrapping GHC 7.8 with GHC 7.10. The long and short of it is, it should just about work - although we still haven't committed to this policy, it looks like Yitz and some others are quite adamant about it. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008531.html - Neil Mitchell uncovered a nasty bug in GHC 7.10.1 RC3, submitted it to us. He also wrote a fantastic [http://neilmitchell.blogspot.co.at/2015/03/finding-ghc-bug.html blog post explaining the issue]. And it was promply diagnosed, fixed, and taken care of by our own Joachim Breitner. Thank you for the fast response Joachim and Neil! https://mail.haskell.org/pipermail/ghc-devs/2015-March/008532.html - Mark Lentczner has announced Alpha releases of the Haskell Platform 2015.2.0.0, containing GHC 7.10.1 RC3: https://mail.haskell.org/pipermail/ghc-devs/2015-March/008597.html - Simon Peyton Jones asks: what's the current state about having simultaneous installations of a package? Simon is a bit confused as to why this is still a problem when we have all the tools to solve it, it looks like! (But read on for more): https://mail.haskell.org/pipermail/ghc-devs/2015-March/008602.html - Michael Snoyman asks: can we get a new feature patch in GHC 7.10.2? The answer seems to be an unfortunate 'no', but with some tips, Michael may end up backporting the changes from HEAD to GHC 7.10 himself. https://mail.haskell.org/pipermail/ghc-devs/2015-March/008612.html Some noteworthy commits that went into `ghc.git` in the past two weeks include: - Commit 71fcc4c096ec0b575522e4c2d0104ef7a71a13c5 - GHC defaults to using the `gold` linker on ARM/Android and ARM/Linux targets. - Commit 9dfdd16a61e79cb03c633d442190a81fe5c0b6b8 - Bump `ghc-prim` to version 0.4.0.0. - Commit 42448e3757f25735a0a5b5e2b7ee456b5e8b0039 - GHC HEAD now always looks for LLVM 3.6 specifically. Closed tickets this past week include: #9122, #10099, #10081, #9886, #9722, #9619, #9920, #9691, #8976, #9873, #9541, #9619, #9799, #9823, #10156, #1820, #6079, #9056, #9963, #10164, #10138, #10166, #10115, #9921, #9873, #9956, #9609, #7191, #10165, #10011, #8379, #10177, #9261, #10176, #10151, #9839, #8078, #8727, #9849, #10146, #9194, #10158, #7788, #9554, #8550, #10079, #10139, #10180, #10181, #10170, #10186, #10038, #10164, and #8976. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From gershomb at gmail.com Wed Mar 25 03:20:32 2015 From: gershomb at gmail.com (Gershom B) Date: Tue, 24 Mar 2015 23:20:32 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: On March 24, 2015 at 8:14:27 PM, Manuel M T Chakravarty (chak at cse.unsw.edu.au) wrote: > > Right, I think there's still a great deal of value in having a simple > > recommendation for new users. > > Absolutely! The recurring problem with decisions like the one about the recommended > installers on the Haskell front page is that they are made by power users who simply lack > the perspective to understand the requirements of new users. To be clear, the current recommendations that highlight minimal installers were not made on behalf of ?power users.? In fact, they were motivated by those with the most experience helping _new users_. As the discussed on various reddit threads [1], people coming to Haskell in the context of independent acquisition (i.e. not students at the fine institutions of higher learning with sufficient distinction and taste to teach Haskell) have consistently had trouble with the platform. I am here talking about people that are probably experienced programmers to some degree, but just not experienced with Haskell. If they are to be confused by things, I want them to be confused by clever types, subtle uses of laziness, and mind-blowing idioms relying on higher order functions, not confusing messages when trying to install libraries. The first things they try to do are not write student exercises, but e.g. install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package with an API binding for some webservice which has not been updated in two years and requires an old version of time, and then maybe a GUI toolkit and of course lens. They do not yet know how to vet packages and carefully manage dependencies. They do not know how to fix trivial breakages or manually change bounds. They know how to type at least three words: ?cabal? ?install? and ?ghci?. And they do not have a professor or instructor to guide them. And, consistently, repeatedly, they destroy their package environment. And when they do so, the answer is invariably the only one that is easy to give remotely and without lots of context ? wipe the package environment and start again. The most important message for these new users is ?always use a sandbox?, because that at least keeps them from destroying the full environment when they allow installations of packages that break other packages, etc. And the platform, to the extent that it changes and complicates build plans, does these users no good. > A minimal installer followed by half an hour of cabal install is an extremely bad way to? > sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers.? I will grant this. But I will also say that a full platform install followed by a day of trying and failing to install complex combinations of dependencies also isn?t particularly inviting. Again, I very much _want_ to be able to recommend the platform unilaterally as the ?best choice nearly always?. I like the fact that it has a uniform process for releases and installers. I like that it has infrastructure and buy-in, and I remember how bad things were in the days before it. I personally always use it, and I personally (absent the network/windows issue that MinGHC solves) don?t understand why experienced users don?t always go with the platform (except, I suppose, if they are so accustomed to ?sandbox everything? that they never see a payoff, or if they are now using nix, which is also an awesome approach but very much for power users still). I think Duncan?s proposals are very good. That is to say first, change the ?new sandbox behavior? issue. Once we do that, the platform will be perfectly fine for the sorts of users I described above, and I would hope that changing the recommendations on the website to say so would be uncontroversial. Then, above and beyond that, and at a future date, finishing the big plans for nix-like operations, allowing the same version of package A to be built against multiple versions of package B, etc, will do away for the need for sandboxes altogether, we hope. In the interim, I did point out an outstanding ticket [2] on the homepage to further improve and balance the current layout and wording ? pull requests are always welcome!? Cheers, Gershom [1] a) Most recently, related to this discussion and linked by acowley: http://www.reddit.com/r/haskell/comments/2zts44/wither_the_platform/ b) Occasioned by the launch of the new homepage: http://www.reddit.com/r/haskell/comments/2w3php/venerable_haskell_platform_necessity_or_product/ [2] https://github.com/haskell-infra/hl/issues/55 > A minimal installer followed by half an hour of cabal install is an extremely bad way to > sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers. > > We are using Haskell in a few courses here at UNSW. We always recommend students to use > the Haskell Platform when they want to install Haskell on their own machines. It?s one > download and gives them the same packages on all platforms. Anything else just leads > to lots of support questions of students trying to get their installations working to > do their assignments. > > Manuel > > > One of the points of argument was that some people were arguing that the > > minimal installers are better for new users. I disagree, but certainly > > there is one issue that could be fixed that'd go a long way to resolving > > the particular use case with new users that was raised. > > > >> The Platform arose in an era before sandboxes and before curated library > >> sets like Stackage and LTS. Last time we set direction was several years > >> ago. These new features and development have clearly changed the landscape > >> for use to reconsider what to do. > > > >> I don't think the status quo for the Platform is now viable - mostly as > >> evidenced by waning interest in maintaining it. I offer several ways we > >> could proceed: > > > > Well, the people who like it don't really complain. But yes, things need > > improving. > > > >> *1) Abandon the Platform.* GHC is release in source and binary form. Other > >> package various installers, with more or less things, for various OSes. > >> > >> *2) Slim the Platform.* Pare it back to GHC + base + a smaller set of > >> "essential" libs + tools. Keeps a consistent build layout and installation > >> mechanism for Haskell. > >> > >> *3) Re-conceive the Platform.* Take a very minimal install approach, > >> coupled with close integration with a curated library set that makes it > >> easy to have a rich canonical, stable environment. This was the core idea > >> around my "GPS Haskell" thoughts from last September - but there would be > >> much to work out in this direction. > > > > I'm not sure that slimming is really needed. But I agree with the GPS > > approach. The current set is too small in the sense that it doesn't > > cover lots of things people need, and the GPS approach should solve > > that. We don't need to promise such high QA for the extended set, we > > just need to make sure they build together. > > > > We need to remember that one of the purposes of the platform as > > originally conceived is to get people to sync on the versions of their > > deps that they're using at the moment. This is where the GPS approach > > shines, but it still makes sense to have some core set at the middle of > > that. It's true that advanced users don't need lots of things > > pre-installed, but they sill benefit from other developers synchronising > > on versions of deps, so that they can have more things work together > > more often. > > > > On the argument that the platform is too big, the primary issue there is > > that people want to make new sandboxes that are more minimal, and with > > cabal's current behaviour of basing all sandboxes off of the global > > package db, and the platform installing lots of packages globally then > > we get a conflict. > > > > But the solution is simple: make cabal sandboxes not be based off of > > everything that is globally installed, make new sandboxes be really > > minimal (though the ghc/platform installers could help with identifying > > what is the minimal subset). > > > > Duncan > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From chak at cse.unsw.edu.au Wed Mar 25 04:43:13 2015 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed, 25 Mar 2015 15:43:13 +1100 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: > Gershom B : > On March 24, 2015 at 8:14:27 PM, Manuel M T Chakravarty (chak at cse.unsw.edu.au) wrote: > >>> Right, I think there's still a great deal of value in having a simple >>> recommendation for new users. >> >> Absolutely! The recurring problem with decisions like the one about the recommended >> installers on the Haskell front page is that they are made by power users who simply lack >> the perspective to understand the requirements of new users. > > To be clear, the current recommendations that highlight minimal installers were not made on behalf of ?power users.? In fact, they were motivated by those with the most experience helping _new users_. As the discussed on various reddit threads [1], people coming to Haskell in the context of independent acquisition (i.e. not students at the fine institutions of higher learning with sufficient distinction and taste to teach Haskell) have consistently had trouble with the platform. I am here talking about people that are probably experienced programmers to some degree, but just not experienced with Haskell. If they are to be confused by things, I want them to be confused by clever types, subtle uses of laziness, and mind-blowing idioms relying on higher order functions, not confusing messages when trying to install libraries. > > The first things they try to do are not write student exercises, but e.g. install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package with an API binding for some webservice which has not been updated in two years and requires an old version of time, and then maybe a GUI toolkit and of course lens. They do not yet know how to vet packages and carefully manage dependencies. They do not know how to fix trivial breakages or manually change bounds. They know how to type at least three words: ?cabal? ?install? and ?ghci?. And they do not have a professor or instructor to guide them. And, consistently, repeatedly, they destroy their package environment. And when they do so, the answer is invariably the only one that is easy to give remotely and without lots of context ? wipe the package environment and start again. > > The most important message for these new users is ?always use a sandbox?, because that at least keeps them from destroying the full environment when they allow installations of packages that break other packages, etc. And the platform, to the extent that it changes and complicates build plans, does these users no good. You are talking about a specific kind of new users. These new users want to install a web stack or similar ? i.e., they need tons of packages. These people may be new to Haskell, but I reckon they are otherwise power users. I?m talking about somebody picking up Learn you a Haskell and wanting to write Hello World. Why should they care about sandboxes? Who cares if they mess up their installation by installing the wrong package. They can always nuke it and install it again. That?s a much simpler story. Look. I guess, I count as a power user ;) I rarely use sandboxes. They are great for a particular type of use, but you can do many things quite happily without them. (Ask SimonPJ; I reckon he doesn?t use sandboxes either.) >> A minimal installer followed by half an hour of cabal install is an extremely bad way to >> sell Haskell to a newcomer. Sure, it is more flexible, but flexible is *bad* for newcomers. > > I will grant this. But I will also say that a full platform install followed by a day of trying and failing to install complex combinations of dependencies also isn?t particularly inviting. > > Again, I very much _want_ to be able to recommend the platform unilaterally as the ?best choice nearly always?. I like the fact that it has a uniform process for releases and installers. I like that it has infrastructure and buy-in, and I remember how bad things were in the days before it. I personally always use it, and I personally (absent the network/windows issue that MinGHC solves) don?t understand why experienced users don?t always go with the platform (except, I suppose, if they are so accustomed to ?sandbox everything? that they never see a payoff, or if they are now using nix, which is also an awesome approach but very much for power users still). The mistake here is to try to make this a one-size-fits all. I honestly don?t care about a platform that is ideal for everybody. I want something that I can point newbies at that makes them happy quickly. That needs to be one download with all the packages that you need to get going included. If somebody gets sufficiently hooked on Haskell to want to start a bigger project, then they will have the patience for a more elaborate story (and wait for cabal install for a few hours to do its job). The point is that one-size-fits-all is inherently unfriendly to novices. A novice needs something simple with as few options as possible, whereas a power user wants flexibility and customisability. A minimal installer with sandboxes gives you the latter, but it comes at the expense of simplicity, which makes is unfriendly to novices. > I think Duncan?s proposals are very good. That is to say first, change the ?new sandbox behavior? issue. Once we do that, the platform will be perfectly fine for the sorts of users I described above, and I would hope that changing the recommendations on the website to say so would be uncontroversial. Then, above and beyond that, and at a future date, finishing the big plans for nix-like operations, allowing the same version of package A to be built against multiple versions of package B, etc, will do away for the need for sandboxes altogether, we hope. Well, we have got people who want to learn Haskell now and who use Haskell as part of their coursework now. Why make them wait for future work which will probably take longer than planned, needs to be rolled out, etc? I?m sorry if I?m sounding negative here. I appreciate all these efforts. However, I am quite frustrated by the recurrent argument that flexibility implies simplicity. That is true for the expert, but flexibility is a curse to the beginner. Manuel From gershomb at gmail.com Wed Mar 25 05:09:02 2015 From: gershomb at gmail.com (Gershom B) Date: Wed, 25 Mar 2015 01:09:02 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: On March 25, 2015 at 12:43:22 AM, Manuel M T Chakravarty (chak at cse.unsw.edu.au) wrote: > > Look. I guess, I count as a power user ;) I rarely use sandboxes. They are great for a particular > type of use, but you can do many things quite happily without them. (Ask SimonPJ; I reckon > he doesn?t use sandboxes either.) Ironically, the only time I have had to use a sandbox was in doing work on the new Haskell homepage (it is written in Yesod). In fact, that was insufficient for some reason and I had to install hsenv as well and use that for an even ?stronger? sandbox. As I have said, I also install the platform whenever possible. Believe me, you are preaching to the choir! > The mistake here is to try to make this a one-size-fits all. I honestly don?t care about > a platform that is ideal for everybody. I want something that I can point newbies at that > makes them happy quickly. That needs to be one download with all the packages that you > need to get going included. .. > Well, we have got people who want to learn Haskell now and who use Haskell as part of their? > coursework now. Why make them wait for future work which will probably take longer than? > planned, needs to be rolled out, etc? I do not understand this. The platform still exists, is still great, is not going anywhere, and as far as I can tell, is on track to become even better. You can point people at?https://www.haskell.org/platform/ or you can point them at downloads.haskell.org which links to there or you can point them at www.haskell.org and tell them ?the downloads page gives you options, pick the platform option.? Nobody who wants to use the platform must wait for anything. Nobody has taken anything from you, or anyone else. Nobody wants to take anything from you, or anyone else. We just want to recognize that this other set of users ? those coming from other languages, and wanting to ?from the gate? install large sets of dependencies ? this set of users has grown and is growing and if we don?t want them to become frustrated and bounce off Haskell, then we need to provide resources for them too, and steer them to things that meet _their_ needs as well. They are not lucky enough to be in your class and be guided by an instructor. If you want to patch the downloads page so that it more clearly highlights the platform option or makes clear that if you want to be a ?power user? and manage lots of dependencies with abandon you may want the minimal installers, and if you want ?a good, wide-ranging set of defaults to experiment and learn with? then you want the platform, or some other wording that is perhaps clearer, or anything at all like that, then there is again a ticket on the github homepage to improve the language, and pull requests are welcome. The compromise wording on the page now is just that: a compromise. I don?t even claim it to be a great one, just what was settled on. If you (or anyone) can improve it to present both sorts of installers and the tradeoffs more clearly and more simply, please do! There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. Again, the main advantage that students have is that they have instructors who can guide them in what they recommend to download, how to get started, etc. So, for the moment, I would argue that students are not the most fundamental target audience for that snippet of text on the downloads page. But, that does not mean the language cannot be better for students too. And I would very much like it to be! Beyond that I don?t feel we?re discussing anything as metaphysical as flexibility or simplicity. And I don?t feel my own preferences are necessarily better or worse than others ? I just want two things, as do we all I think. A) To have the best possible toolsets available for all types of users in all possible development setups, and B) To somehow condense the core of that information into an easily digestible form to help steer visitors to the Haskell homepage to the setup that is right for _them_.? As always, anybody who wants to help with this in any regard with the new homepage is welcome and invited to do so. We have plenty of open tickets and room for improvement all around, a helpful crew on the #haskell-infrastructure irc, and patches, pull requests, and new tickets are always welcomed. Best, Gershom From mark.lentczner at gmail.com Wed Mar 25 05:52:22 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 24 Mar 2015 22:52:22 -0700 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: On Tue, Mar 24, 2015 at 8:20 PM, Gershom B wrote: > install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package > with an API binding for some webservice which has not been updated in two > years and requires an old version of time, and then maybe a GUI toolkit and > of course lens. That sounds like a recipe for Cabal Hell, Platform or not! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Wed Mar 25 06:21:48 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 24 Mar 2015 23:21:48 -0700 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: On Tue, Mar 24, 2015 at 10:09 PM, Gershom B wrote: > There are different types of beginners, and meeting all their needs (as > well as the needs of long-timers of various stripes, etc) all at once is a > tricky task. Actually, pretty much all other language systems (C++, Java(*), Python, PHP, Ruby, Scala, etc...) meet *all* users' needs, not just beginners, with one common tool set + core libs. Different users don't install different packagings of Python. There isn't a list of choices of Scala installers. I had a really long post prepared about my reasoning, but I think I'll just spare you all, and cut to the chase: *The problem is how GHC is released:* It is released as a compiler, and minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no other tools, and no installer. *This is an insufficient set of things for most users.* At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of these, the set could be bigger or smaller, ... basically, it should be the Platform. We should consider those additional libs as frozen, and tied to the GHC release, as the base libs - because that will mean those will be the common versions people will build and test against. And they will update as frequently as GHC. (If they aren't as stable as all that, or aren't willing to be part of that release cycle and constraint, then perhaps they shouldn't be in that set!) Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. We worked really hard last Summer to make the Platform be very quickly buildable - there is already a 7.10 RC3 Platform out (though I did it by, ahem, not following Haskell Platform procedure - and, er, well, just did it!) - I think we should just pare back the definition of the Platform, and then commit to making it be the way new GHCs are released. - Mark (*) Okay, so Java comes in three variants, but they are mostly distinguished by final deployment environment, not user type. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Wed Mar 25 06:31:58 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 24 Mar 2015 23:31:58 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: *Hey you....* yes you... Platform committee member, or Platform library maintainer, Platform packager... that's right, you: GHC 7.10 is about to be released. Wouldn't it rock if we came out with a Platform within days? Or on the same day? I know, I know, our process is long and full of discussion, and hard, and slow.... let's smash that, eh? How'z'bout it? OKAY? Good! Your task is: - look over the the source file at GitHub that defines the release - see if the version of your stuff looks right - yeah, I bumped it all to latest, major or minor version change - so APIs probably broke from last HP - look near the end where there is a bunch of stuff I kinda just added to get it all to compile - read the notes about those things in the first message of this thread (copied below) - weigh in - short and sweet - if you have an opinion - if you have a spare Mac - download it and try it! Crazy, right? I know... but, can we do this? ? Mark On Sun, Mar 22, 2015 at 10:13 PM, Mark Lentczner wrote: > I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 > using GHC 7.10 RC3. > > I bumped all the GHC libs to the versions in 7.10, and bumped all the > Platform libs to the latest versions I could find on Hackage. There were a > few issues: > > - *old-locale and old-time* - no longer part of GHC, but > cabal-install, cgi & HTTP need them - and they are part of the platform - > so included now as added packages. Not sure this is a great idea, since > they are now very deprecated... but until cabal-install, cgi, & HTTP > update, not sure what else to do. > - *tf-random* - is now required by alex and QuickCheck - seems a shame > to add this, as now we're going to have two random packages > - *network-uri *- was split out of network, and needed by > cabal-install, cgi, & HTTP. I suppose we should include it, as it was > functionality and API that was part of the platform > - *exceptions* & *multipart* - needed by cgi - is exceptions now > subsumed by something in transformers? and... multipart? maybe time to drop > cgi? We didn't have it last time anyway as it wouldn't compile! > - *scientific* - needed by attoparsec - debated in detail last time > ... and we're still here! > > The Platform is significantly larger now: On OS X it has gone from 316M to > 499M! Most of this is due to new OpenGL libs which are now huge (went from > 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole > installed magilla is 1.5G! Even the compressed installer is now 250M! > > If you want to poke at it, the source is in the pre-release branch at > GitHub , > and the OS X builds are at my usual platform staging area: > > Index of /mark/platform > > > Remember, it already includes GHC, so no need to download the GHC binary > for OS X that is there, too. > > I'll try to get a generic linux build up soonish... but my VM now runs out > of memory trying to build OpenGL - and adding more only makes my machine > thrash to death! > > - Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at cse.unsw.edu.au Wed Mar 25 06:33:40 2015 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed, 25 Mar 2015 17:33:40 +1100 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: <5B7964AF-8532-457E-A24B-5C05AFA5A362@cse.unsw.edu.au> > Gershom B : > > On March 25, 2015 at 12:43:22 AM, Manuel M T Chakravarty (chak at cse.unsw.edu.au) wrote: >> >> Look. I guess, I count as a power user ;) I rarely use sandboxes. They are great for a particular >> type of use, but you can do many things quite happily without them. (Ask SimonPJ; I reckon >> he doesn?t use sandboxes either.) > > Ironically, the only time I have had to use a sandbox was in doing work on the new Haskell homepage (it is written in Yesod). In fact, that was insufficient for some reason and I had to install hsenv as well and use that for an even ?stronger? sandbox. As I have said, I also install the platform whenever possible. Believe me, you are preaching to the choir! Then, I don?t understand why the Platform isn?t the recommended on the homepage. >> The mistake here is to try to make this a one-size-fits all. I honestly don?t care about >> a platform that is ideal for everybody. I want something that I can point newbies at that >> makes them happy quickly. That needs to be one download with all the packages that you >> need to get going included. > .. >> Well, we have got people who want to learn Haskell now and who use Haskell as part of their >> coursework now. Why make them wait for future work which will probably take longer than >> planned, needs to be rolled out, etc? > > I do not understand this. The platform still exists, is still great, is not going anywhere, and as far as I can tell, is on track to become even better. You can point people at https://www.haskell.org/platform/ or you can point them at downloads.haskell.org which links to there or you can point them at www.haskell.org and tell them ?the downloads page gives you options, pick the platform option.? Nobody who wants to use the platform must wait for anything. > > Nobody has taken anything from you, or anyone else. Nobody wants to take anything from you, or anyone else. I know, but look at the subject of this message (and the original post in this thread). Mark?s questions was ?as I read it? do we still need the platform. Then, lots of power users jumped up and down criticising the flaws in the platform and why other approaches are better. To which I say, other approaches are better for you (plural)[1], but not to a large class of novices. That is all. Also, to reiterate, I?m arguing with you because you replied to my message. I definitely do appreciate all the effort you (and others) are putting into the homepage and infrastructure. Manuel [1] English is such an awkward language :P > We just want to recognize that this other set of users ? those coming from other languages, and wanting to ?from the gate? install large sets of dependencies ? this set of users has grown and is growing and if we don?t want them to become frustrated and bounce off Haskell, then we need to provide resources for them too, and steer them to things that meet _their_ needs as well. They are not lucky enough to be in your class and be guided by an instructor. > > If you want to patch the downloads page so that it more clearly highlights the platform option or makes clear that if you want to be a ?power user? and manage lots of dependencies with abandon you may want the minimal installers, and if you want ?a good, wide-ranging set of defaults to experiment and learn with? then you want the platform, or some other wording that is perhaps clearer, or anything at all like that, then there is again a ticket on the github homepage to improve the language, and pull requests are welcome. The compromise wording on the page now is just that: a compromise. I don?t even claim it to be a great one, just what was settled on. If you (or anyone) can improve it to present both sorts of installers and the tradeoffs more clearly and more simply, please do! > > There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. Again, the main advantage that students have is that they have instructors who can guide them in what they recommend to download, how to get started, etc. So, for the moment, I would argue that students are not the most fundamental target audience for that snippet of text on the downloads page. But, that does not mean the language cannot be better for students too. And I would very much like it to be! > > Beyond that I don?t feel we?re discussing anything as metaphysical as flexibility or simplicity. And I don?t feel my own preferences are necessarily better or worse than others ? I just want two things, as do we all I think. A) To have the best possible toolsets available for all types of users in all possible development setups, and B) To somehow condense the core of that information into an easily digestible form to help steer visitors to the Haskell homepage to the setup that is right for _them_. > > As always, anybody who wants to help with this in any regard with the new homepage is welcome and invited to do so. We have plenty of open tickets and room for improvement all around, a helpful crew on the #haskell-infrastructure irc, and patches, pull requests, and new tickets are always welcomed. > > Best, > Gershom > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From mark.lentczner at gmail.com Wed Mar 25 06:39:36 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Tue, 24 Mar 2015 23:39:36 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On Mon, Mar 23, 2015 at 7:58 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > How do you get the ghc docs built successfully on os x? I've tried to > replicate you buildsteps but docbook hits a failure when tryingto download > some remote file. > I added my OS X build notes for GHC to the Platform repo. Enjoy! - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Wed Mar 25 07:55:11 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 25 Mar 2015 08:55:11 +0100 Subject: wither the Platform In-Reply-To: (Mark Lentczner's message of "Tue, 24 Mar 2015 23:21:48 -0700") References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: <87egodtstc.fsf@gmail.com> On 2015-03-25 at 07:21:48 +0100, Mark Lentczner wrote: [...] > *The problem is how GHC is released:* It is released as a compiler, and > minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no > other tools, and no installer. *This is an insufficient set of things for > most users.* > > At minimum it should also have cabal-install, and the libs so many things > are built on: async, mtl, text, parsec, vector, etc..., and also common > tools (like happy, alex, and hscolour). You can argue plus or minus some of > these, the set could be bigger or smaller, ... basically, it should be the > Platform. > We should consider those additional libs as frozen, and tied to the GHC > release, as the base libs - because that will mean those will be the common > versions people will build and test against. And they will update as > frequently as GHC. (If they aren't as stable as all that, or aren't willing > to be part of that release cycle and constraint, then perhaps they > shouldn't be in that set!) > > Yes, I'm arguing that the GHC release and the Platform release should be > one and the same. The vast majority of the pain I think stems from the skew > between these two, and that GHC is not enough. You need something besides > the GHC release. If that something isn't standard, and/or it lags the GHC > release, then all the attendant problems creep in. [...] While I sympathise myself with bundling cabal-install with GHC bindists, as that's been (in my perception) the most requested feature from ghc-bindist users, GHC HQ is trying rather trying strip down the GHC distribution and dropping packages being installed by default whenever possible. E.g. with GHC 7.10.1 we dropped 4 packages (old-locale, old-time, haskell98, and haskell2010) as those don't need to be part of the (installed) GHC distribution. Some other packages (xhtml, haskeline, terminfo) that were recently exposed could be dropped again if we manage to workaround an unexpected DSO issue. We would even be in the position (since GHC 7.10) to drop the `Cabal` package from being installed (if it wasn't for the Cabal spec), as the `ghc` package severed its dependency on `Cabal` with this release.[1] Not tying packages to GHC releases gives more flexibility and less overhead, as we need to synchronise less with upstream maintainers, and more importantly updates to non-bundled packages can happen independently of GHC releases and more frequently. Also, it gives 3rd party packagers more degrees of freedom to select different cross-sections/subsets of Hackage to define as curated snapshot (i.e. LTS, Stackage, HP, Linux distributions, NixOS, ...). Cheers, hvr [1]: http://comments.gmane.org/gmane.comp.lang.haskell.ghc.devel/7571 From svenpanne at gmail.com Wed Mar 25 08:02:29 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 25 Mar 2015 09:02:29 +0100 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: 2015-03-25 7:31 GMT+01:00 Mark Lentczner : > [...] look over the the source file at GitHub that defines the release > see if the version of your stuff looks right The OpenGLRaw and GLUTRaw versions are OK, for OpenGL and GLUT we should use newer versions I just released (OpenGL-2.12.0.0 and GLUT-2.7.0.0). These contain much requested API additions/generalizations. Furthermore, due to other popular requests like generalizing things and making OpenAL stuff independent from OpenGL, I split off improved StateVar (thanks to Edward Kmett!) and ObjectName packages again, which are now additional dependencies. This move was made in spite of all those bikeshedding discussions around them, because several actual package users requested them. ("Listen to your customers!") I simply don't want to be held back by eternal theoretical discussions anymore, instead let's ship what people actually want. > [...] look near the end where there is a bunch of stuff I kinda just added to get > it all to compile [...] As mentioned above, we need StateVar-1.1.0.0 and ObjectName-1.1.0.0 now, too. A +1 for including exceptions, but why version 0.6.1, which is quite old? I would propose including the latest and greatest 0.8.0.2 version. Regarding the random packages: Shipping 2 packages for basically the same thing is silly IMHO and a bad sign for something which claims to be a coherent set of APIs. Either these packages should be merged or the dependencies adapted. Offering choice for the same task has no place in the platform IMHO, we should ship what is considered the best/most widely used for each area. For the more arcane needs, there's always Hackage... From hvr at gnu.org Wed Mar 25 08:12:07 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 25 Mar 2015 09:12:07 +0100 Subject: wither the Platform In-Reply-To: (Manuel M. T. Chakravarty's message of "Wed, 25 Mar 2015 15:43:13 +1100") References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: <878uelts14.fsf@gnu.org> On 2015-03-25 at 05:43:13 +0100, Manuel M T Chakravarty wrote: [...] >> The most important message for these new users is ?always use a >> sandbox?, because that at least keeps them from destroying the full >> environment when they allow installations of packages that break >> other packages, etc. And the platform, to the extent that it changes >> and complicates build plans, does these users no good. > > You are talking about a specific kind of new users. These new users > want to install a web stack or similar ? i.e., they need tons of > packages. These people may be new to Haskell, but I reckon they are > otherwise power users. > > I?m talking about somebody picking up Learn you a Haskell and wanting > to write Hello World. IMO, that class of users don't need anything beyond the packages bundled with GHC anyway... However, LYAH already directs such users to the platform as it states in its introduction: | What you need to dive in | | A text editor and a Haskell compiler. You probably already have your | favorite text editor installed so we won't waste time on that. For the | purposes of this tutorial we'll be using GHC, the most widely used | Haskell compiler. | | *The best way to get started is to download the Haskell Platform,* | which is basically Haskell with batteries included.* | [...] And here's what Bird's "Thinking Functionally with Haskell" has to say about the HP: | 1.5 The Haskell Platform | | If you visit the site www.haskell.org, you will see how to download | The Haskell Platform. This is a large collection of tools and packages | that can be used to run Haskell scripts. The platform comes in three | versions, one for each of Windows, Mac and Linux. We deal only with | the Windows version, the others being similar. So I'm not too worried that newcomers following a guided course/tutorial (such as LYAH or TFwH) won't be directed to the platform. Cheers, hvr From johan.tibell at gmail.com Wed Mar 25 08:33:05 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 25 Mar 2015 09:33:05 +0100 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: cabal-install should be 1.22.2.0 (latest). Otherwise looks good. On Mar 25, 2015 7:32 AM, "Mark Lentczner" wrote: > *Hey you....* yes you... Platform committee member, or Platform library > maintainer, Platform packager... that's right, you: > > GHC 7.10 is about to be released. Wouldn't it rock if we came out with a > Platform within days? Or on the same day? > > I know, I know, our process is long and full of discussion, and hard, and > slow.... let's smash that, eh? How'z'bout it? > > OKAY? Good! Your task is: > > - look over the the source file at GitHub > that > defines the release > - see if the version of your stuff looks right > - yeah, I bumped it all to latest, major or minor version change - so > APIs probably broke from last HP > - look near the end where there is a bunch of stuff I kinda just added > to get it all to compile > - read the notes about those things in the first message of this > thread (copied below) > - weigh in - short and sweet - if you have an opinion > - if you have a spare Mac - download it and try it! > > > Crazy, right? I know... but, can we do this? > > ? Mark > > On Sun, Mar 22, 2015 at 10:13 PM, Mark Lentczner > wrote: > >> I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 >> using GHC 7.10 RC3. >> >> I bumped all the GHC libs to the versions in 7.10, and bumped all the >> Platform libs to the latest versions I could find on Hackage. There were a >> few issues: >> >> - *old-locale and old-time* - no longer part of GHC, but >> cabal-install, cgi & HTTP need them - and they are part of the platform - >> so included now as added packages. Not sure this is a great idea, since >> they are now very deprecated... but until cabal-install, cgi, & HTTP >> update, not sure what else to do. >> - *tf-random* - is now required by alex and QuickCheck - seems a >> shame to add this, as now we're going to have two random packages >> - *network-uri *- was split out of network, and needed by >> cabal-install, cgi, & HTTP. I suppose we should include it, as it was >> functionality and API that was part of the platform >> - *exceptions* & *multipart* - needed by cgi - is exceptions now >> subsumed by something in transformers? and... multipart? maybe time to drop >> cgi? We didn't have it last time anyway as it wouldn't compile! >> - *scientific* - needed by attoparsec - debated in detail last time >> ... and we're still here! >> >> The Platform is significantly larger now: On OS X it has gone from 316M >> to 499M! Most of this is due to new OpenGL libs which are now huge (went >> from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the >> whole installed magilla is 1.5G! Even the compressed installer is now 250M! >> >> If you want to poke at it, the source is in the pre-release branch at >> GitHub , >> and the OS X builds are at my usual platform staging area: >> >> Index of /mark/platform >> >> >> Remember, it already includes GHC, so no need to download the GHC binary >> for OS X that is there, too. >> >> I'll try to get a generic linux build up soonish... but my VM now runs >> out of memory trying to build OpenGL - and adding more only makes my >> machine thrash to death! >> >> - Mark >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Wed Mar 25 08:33:41 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 25 Mar 2015 09:33:41 +0100 Subject: wither the Platform In-Reply-To: (Mark Lentczner's message of "Tue, 24 Mar 2015 22:52:22 -0700") References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: <874mp9tr16.fsf@gnu.org> On 2015-03-25 at 06:52:22 +0100, Mark Lentczner wrote: > On Tue, Mar 24, 2015 at 8:20 PM, Gershom B wrote: > >> install Yesod, or GHCJS, or Yesod and then GHCJS, and then some package >> with an API binding for some webservice which has not been updated in two >> years and requires an old version of time, and then maybe a GUI toolkit and >> of course lens. > > That sounds like a recipe for Cabal Hell, Platform or not! Regardless of the hellish issue, Gershom's comment indirectly highlights of one thing where I'm wondering if the HP's growth isn't bounded by diversity: There are some areas which I'd expected to some degree in a batteries-included platform, where the Haskell ecosystem has diverged into popular but distinct package-sub-ecosystems (which all have their respective communities/followers), such as HTTP-serving (Yesod/Snap/Happstack/...), or which lens-abstraction to use, or at the more fundamental level, even the streaming abstraction (pipes/conduit/io-streams/machines/...) doesn't seem to have a clearly recommended and agreed upon representative. Also, to this day we don't have any TLS library support in the platform, which also is subject to debate of which crypto-library to use (and there's also the question whether to use OpenSSL via FFI or a native TLS reimpl). So the platform-included `HTTP` package is not even able to access `https://` URLs which is quite sad, as this also holds back `cabal-install`'s ability to access `https://`-only repositories. So, where do you see the platform's growth for those packages/areas where you'll probably not get a reasonable majority consensus for picking a specific package? Cheers, hvr From simonpj at microsoft.com Wed Mar 25 09:09:10 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Mar 2015 09:09:10 +0000 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> Message-ID: <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ? There are some people working on GHC itself. That is already a big job. Just getting GHC ready to release is hard. Hence the desire that Herbert mentions to strip it down as much as possible. ? But a release of GHC is not adequate. No one except power users should install a GHC release. It should be a secret among the cognoscenti that a GHC release has happened. ? The first sensible unit of installation (at least for a non-power user) is the Haskell Platform. It includes the tools you need (Happy, Alex, Cabal) as well as a small but useful collection of libraries. That?s why GHC?s download page explicitly says ?Stop! Shouldn?t you be installing the Haskell Platform instead??. ? HP releases should therefore, in contrast to GHC releases, be widely publicised. ? Moreover, a HP release should very closely follow a GHC release (though the former could occur more often), to reduce the chance that a na?ve user bypasses the HP and gets GHC alone. That is what Mark is rightly working on at this very moment for GHC 7.10. We probably should work harder to reduce the lag. In this sense, the plan was always that ?the GHC and the Platform release are one and the same?. I think of the HP release as the ?real GHC release?. It?s just that, as an implementation mechanism, the GHC team push out the bare GHC bits, so that the HP team have something firm to chew on. So that was the plan. I still think it?s a good plan. But it clearly is not working well, and I?m hazy about why. Possible reasons: ? Possible diagnosis 1. Installing HP somehow screws up the world for power users, or for a beginner who grows into a power user. Surely we can fix this! Installing HP should not get in the way. I suppose that, even if installing HP doesn?t get in the way, it might be a waste of internet bandwidth and disk space for some power users. But that is a smaller problem. ? Possible diagnosis 2. We have not shared the plan as a community; that is, we have focused lots of attention on GHC releases, and little attention on HP releases. It should be the other way around. So here are the questions in my mind: ? Is the original plan still good? ? Is it possible to make the HP so that installing it does not get in the way of power users? So that installing it is, at worst, a waste of disk space? Personally I like the plan because it?s simple; because it usefully empowers, and splits responsibility between, two different groups (GHC and HP); and because it makes life easy for our users. Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Mark Lentczner Sent: 25 March 2015 06:22 To: Gershom B Cc: Manuel M T Chakravarty; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Duncan Coutts; ghc-devs at haskell.org; Haskell Libraries Subject: Re: wither the Platform On Tue, Mar 24, 2015 at 10:09 PM, Gershom B > wrote: There are different types of beginners, and meeting all their needs (as well as the needs of long-timers of various stripes, etc) all at once is a tricky task. Actually, pretty much all other language systems (C++, Java(*), Python, PHP, Ruby, Scala, etc...) meet all users' needs, not just beginners, with one common tool set + core libs. Different users don't install different packagings of Python. There isn't a list of choices of Scala installers. I had a really long post prepared about my reasoning, but I think I'll just spare you all, and cut to the chase: The problem is how GHC is released: It is released as a compiler, and minimal base libs, and (strangely) with 1/2 of cabal, haddock, ghc-pkg, no other tools, and no installer. This is an insufficient set of things for most users. At minimum it should also have cabal-install, and the libs so many things are built on: async, mtl, text, parsec, vector, etc..., and also common tools (like happy, alex, and hscolour). You can argue plus or minus some of these, the set could be bigger or smaller, ... basically, it should be the Platform. We should consider those additional libs as frozen, and tied to the GHC release, as the base libs - because that will mean those will be the common versions people will build and test against. And they will update as frequently as GHC. (If they aren't as stable as all that, or aren't willing to be part of that release cycle and constraint, then perhaps they shouldn't be in that set!) Yes, I'm arguing that the GHC release and the Platform release should be one and the same. The vast majority of the pain I think stems from the skew between these two, and that GHC is not enough. You need something besides the GHC release. If that something isn't standard, and/or it lags the GHC release, then all the attendant problems creep in. We worked really hard last Summer to make the Platform be very quickly buildable - there is already a 7.10 RC3 Platform out (though I did it by, ahem, not following Haskell Platform procedure - and, er, well, just did it!) - I think we should just pare back the definition of the Platform, and then commit to making it be the way new GHCs are released. - Mark (*) Okay, so Java comes in three variants, but they are mostly distinguished by final deployment environment, not user type. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Mar 25 09:49:10 2015 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 25 Mar 2015 09:49:10 +0000 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Thanks for linking to that Mike, I'd actually forgotten that I'd written that :). Those are all very concrete issues people run into with the platform regularly, but I'd like to point out a meta issue: the platform tries to do too much, and in a non-composable manner. As I pointed out previously, it's providing a tools installer, choosing blessed libraries, pegging certain library versions, and selecting a distribution manner for those libraries. Even if the other issues were all addressed, I still believe the current trajectory of the platform is problematic, because it is necessarily removing choice. When Mark, Duncan and I were discussing GPS Haskell at ICFP, a big goal (in my mind at least) was to allow individual tools to target individual goals. I don't expect every use case to be served by a curated package set (like LTS), so making that an optional feature of tooling makes sense. Similarly, almost all users (excepting some people playing with bleeding-edge GHC) will benefit from having an easy-to-use GHC+cabal-install installation, but a large set of users (specifically Hackage package authors) need a way to compile against different versions than the HP-blessed ones for testing purposes. And now a completely separate point: the current functioning of the HP process seems very much at odds with the way people actually write and release packages. Some examples: * Having to go through an extra step of requesting that a package version is bumped is tedious, and resulted in a buggy attoparsec being released in HP * Requiring package authors to endure long debate periods before the package is accepted scares people off from wanting to participate * A number of months back, the HP was used as a vehicle to push the PVP agenda as well, which completely alienated some people from wanting to participate (ironically, the package being pushed instead was not PVP compliant either, go figure). The practical result to that is we currently have no plans at all for getting TLS/HTTPS support into the platform, and everyone's tooling (cabal-install) is far less secure than it should be. * Authors want the freedom to quickly release new versions to their users, especially for bug fixes. While in theory the HP is set up to do bugfix releases, in practice this has never happened. In that sense, it is often preferable from the eyes of a package author *not* to have his/her package in the HP, as then users are better served As long as I'm writing a long email, I want to point out one other thing. A lot of the points being raised in this thread are discussing an idealized view of what the HP could become. I'm fully in favor of improving it (like I said, that's why I tried working with Mark on GPS Haskell and integrating with Stackage). However, we need to accept the reality of the situation today. Could the windows HP installer be improved like MinGHC to include MSYS? Absolutely, and I hope it happens. Could we improve Cabal and work around the global package database issues we've been mentioning? Yes, and I support such moves. But we need to acknowledge current deficiencies, and plot out a course of action to solve them. And given that this thread started by lamenting how much effort the platform currently takes to maintain, I'm concerned about those improvements actually occurring. On Wed, Mar 25, 2015 at 11:30 AM Mike Meyer wrote: > On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones > wrote: > >> So that was the plan. I still think it?s a good plan. But it clearly >> is not working well, and I?m hazy about why. Possible reasons: >> > > Possibly relevant is the stackage commentary on HP at > http://www.stackage.org/install#why-not-haskell-platform: > > ? On Windows, it does not provide a complete environment (missing MSYS). > ? By placing a large number of packages in the global package database, > Haskell Platform installations are more easily corrupted. > ? The choice of package versions conflicts with the needs of many commonly > used packages. > ? Some of the package versions included with the platform have known and > severe bugs, and cannot be reliably upgraded. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Mar 25 09:52:20 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Mar 2015 09:52:20 +0000 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Very good! This one is perhaps a missing piece, if you are saying that a Windows user cannot use GHC without MSYS: ? On Windows, it does not provide a complete environment (missing MSYS). On the other hand these three are examples of HP getting in the way: ? By placing a large number of packages in the global package database, Haskell Platform installations are more easily corrupted. ? The choice of package versions conflicts with the needs of many commonly used packages. ? Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded. My question was: can they be fixed so that HP does not get in the way? E.g. if we solve the multiple-versions-of-packages problem with Cabal (which Duncan in a separate thread says we can), then that would solve the first two; and for the third, I guess the solution is to release a new version of HP. Simon From: Mike Meyer [mailto:mwm at mired.org] Sent: 25 March 2015 09:30 To: Simon Peyton Jones Cc: Mark Lentczner; Gershom B; Manuel M T Chakravarty; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Duncan Coutts; ghc-devs at haskell.org; Haskell Libraries Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 4:09 AM, Simon Peyton Jones > wrote: So that was the plan. I still think it?s a good plan. But it clearly is not working well, and I?m hazy about why. Possible reasons: Possibly relevant is the stackage commentary on HP at http://www.stackage.org/install#why-not-haskell-platform: ? On Windows, it does not provide a complete environment (missing MSYS). ? By placing a large number of packages in the global package database, Haskell Platform installations are more easily corrupted. ? The choice of package versions conflicts with the needs of many commonly used packages. ? Some of the package versions included with the platform have known and severe bugs, and cannot be reliably upgraded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Wed Mar 25 10:10:37 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 25 Mar 2015 11:10:37 +0100 Subject: wither the Platform In-Reply-To: (Simon Peyton Jones's message of "Wed, 25 Mar 2015 09:52:20 +0000") References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87zj71s7z6.fsf@gmail.com> On 2015-03-25 at 10:52:20 +0100, Simon Peyton Jones wrote: [...] >> ? Some of the package versions included with the platform have known >> and severe bugs, and cannot be reliably upgraded. [...] > I guess the solution is to release a new version of HP. IMHO, if HP releases are to happen more frequently, a simple way to upgrade would be desirable rather than having to download a new multi-MiB full installer image each time only because a single package was updated (and the ability to have access to multiple HP releases side-by-side -- in case that isn't supported already) Or put differently, how shall HP users be informed they're not running the latest HP version with all known critical bugs fixed? Cheers, hvr From chak at cse.unsw.edu.au Wed Mar 25 10:14:46 2015 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed, 25 Mar 2015 21:14:46 +1100 Subject: wither the Platform In-Reply-To: <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <9C597846-0885-45AD-B72E-6BDA54BA0070@cse.unsw.edu.au> Simon Peyton Jones : > So that was the plan. I still think it?s a good plan. But it clearly is not working well, and I?m hazy about why. Possible reasons: > > ? Possible diagnosis 1. Installing HP somehow screws up the world for power users, or for a beginner who grows into a power user. Surely we can fix this! Installing HP should not get in the way. I suppose that, even if installing HP doesn?t get in the way, it might be a waste of internet bandwidth and disk space for some power users. But that is a smaller problem. > > ? Possible diagnosis 2. We have not shared the plan as a community; that is, we have focused lots of attention on GHC releases, and little attention on HP releases. It should be the other way around. > I?d say, both. Re 1, a big part of the problem is the whole cabal, package dependency and versioning morass. Re 2, I think, there are multiple factors. The delays in putting out the HP (as previously mentioned). Power users reading GHC Status reports and wanting to get the goodies as quickly as possible. The HP just being quite a bit of hard work people like to avoid. Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Wed Mar 25 10:15:37 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 25 Mar 2015 11:15:37 +0100 Subject: wither the Platform In-Reply-To: <87zj71s7z6.fsf@gmail.com> References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> <87zj71s7z6.fsf@gmail.com> Message-ID: On Wed, Mar 25, 2015 at 11:10 AM, Herbert Valerio Riedel wrote: > Or put differently, how shall HP users be informed they're not running > the latest HP version with all known critical bugs fixed? While I can see most of the problems people claim the platform has, this particular one is shared by manual installs of packages. Cabal prefers installed version, so a package with a bug will not automatically be upgraded, and there is no warning informing users either. Erik From mark.lentczner at gmail.com Wed Mar 25 14:24:30 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Wed, 25 Mar 2015 07:24:30 -0700 Subject: wither the Platform In-Reply-To: <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones wrote: > Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, > was this: ... > I still like that plan! Concrete proposal based on that and the other fine input in the responses: *Simultaneous Release:* Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. *In fact, let's version HP with the same number as GHC!* *Pare the Platform Back:* Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. *And, make that stuff be the latest it can be at each release. *The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. *Make sure the Platform Installers are Complete:* I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. *Make Updating the Packages in Cabal 'work':* I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. *One Web Site:* Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Mar 25 14:34:20 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 25 Mar 2015 10:34:20 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Wed, Mar 25, 2015 at 10:24 AM, Mark Lentczner wrote: > The OpenGL stuff is a hard one, since it is large, but a very big painful > build if you need it. Perhaps we need server/non-server versions of the > platform - but only if we can get them out on the same day. OpenGL has always been an odd fit; it was included partly because of the size and complexity to build, but also because it was felt that batteries-included had to include *some* kind of graphics library. I'm inclined to think that it doesn't really belong in the core Platform, myself. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Mar 25 14:50:10 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 25 Mar 2015 10:50:10 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Wed, Mar 25, 2015 at 10:47 AM, Mike Meyer wrote: > The words "Core Platform" makes me think there ought to be a "non-Core" > platform. This would actually match the Clojure model, where there's "the > stuff that's part of Clojure", "a set of recommended libraries", and "the > library archive anyone can put stuff in". If the platform is going to > undergo serious shrinkage, maybe the things that get pushed out - like the > OpenGL stuff - should be considered for that middle category? Less rigorous > testing, not bundled with the platform, but unlike all of hackage, an > effort is made to insure that there's a repository where it builds on top > of the "core platform"? > That's pretty much what I'm thinking of, yes. Not sure about "less rigorous testing" --- but "doesn't have to release at the same time" is a possibility. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard_b_golden at yahoo.com Wed Mar 25 17:34:08 2015 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Wed, 25 Mar 2015 17:34:08 +0000 (UTC) Subject: wither the Platform In-Reply-To: References: Message-ID: <909148175.1481073.1427304848552.JavaMail.yahoo@mail.yahoo.com> In general, I think Mark's proposals are the way to go. However, I know that there are many developers who will chafe under this plan. There is an inherent tension between "latest and greatest" and "batteries included." While I understand the concerns of those who are on the bleeding edge, I believe it is best for the future of Haskell to go in Mark's direction. Issues that will need to be confronted: 1. Slower release cycle: Coordinating the stability of even a streamlined Platform with a new GHC release candidate will take more time. On the other hand, this is likely to produce a more tested final GHC release. 2. Less diversity in new GHC features: The GHC developers have generally aimed new features at a future release, where the existence and stability of new features has driven their incorporation. It was assumed that the Platform would eventually catch up. If the GHC release and the corresponding Platform release are simultaneous, then some GHC features may need to be pushed out to the following release so there is time for the Platform to be adapted. 3. The GHC development process will need to become more phased: Experimentation with new features will still be encouraged, but adoption of the new features will need to be gated to correspond with what the Platform can implement. (This is really another view of issue 2.) So I would like to add to Mark's call for the developer community to "step up": The research community will need to accept a more structured deployment of their innovations. Howard ________________________________ From: Mark Lentczner Sent: Wednesday, March 25, 2015 7:24 AM Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones wrote: Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ... I still like that plan! Concrete proposal based on that and the other fine input in the responses: Simultaneous Release: Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. In fact, let's version HP with the same number as GHC! > > >Pare the Platform Back: Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. And, make that stuff be the latest it can be at each release. The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. > > >Make sure the Platform Installers are Complete: I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. > > >Make Updating the Packages in Cabal 'work': I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. > > >One Web Site: Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. > > This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? ? Mark _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From spam at scientician.net Wed Mar 25 17:59:19 2015 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 25 Mar 2015 18:59:19 +0100 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On 25-03-2015 15:24, Mark Lentczner wrote: > Concrete proposal based on that and the other fine input in the responses: > > *Simultaneous Release:* Since it is organizationally impractical to have > one release, let's have GHC and Platform release at the same moment. That > is, GHC HQ would keep a release in "RC" until HP was ready. By the same > token, HP team commits to tracking GHC from RC1, and aiming to hit ready > for release within a week of GHC being ready. Both go "release" in the same > announcement. *In fact, let's version HP with the same number as GHC!* What is the purpose of doing this? It's not clear to me that there's any upside, only the rather large downside of GHC HQ (and thus some of us downstreams) having to wait arbitrarily long for the HP release. The historical record for timeliness of HP releases is not encouraging. Are we just expecting that the HP will somehow magically attract more developers... which will somehow translate into more timely releases? Regards, From ekmett at gmail.com Wed Mar 25 21:16:37 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 25 Mar 2015 17:16:37 -0400 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On Mon, Mar 23, 2015 at 4:35 AM, Sven Panne wrote: > 2015-03-23 6:13 GMT+01:00 Mark Lentczner : > > [...] exceptions & multipart - needed by cgi - is exceptions now > subsumed by > > something in transformers? [...] > > Coincidentally, Edward Kmett pointed me to the exceptions package > while I was trying to generalize some of my packages from using plain > IO to MonadIO. Alas, the transformers package still doesn't subsume > the exceptions package, but IMHO it really should. Looking at the > import list of e.g. Control.Monad.Catch alone is already indicating > that. :-) transformers remains rather rigidly locked into Haskell 98/2010. mtl uses comparatively few extensions. exceptions uses rank-3 types in the API, which is something we currently don't do in transformers or the mtl. > BTW: System.Console.Haskeline.MonadException has something > similar, but far less complete, too, but that's really a strange place > for such a feature. How did it end up there? > Haskeline makes a few weird choices. e.g. The opacity of the InputT type pretty much renders the library very difficult to use the moment you need to do something that the package doesn't anticipate, like work with InputT in a transformer and expect any instances to exist, handle exceptions around _it_ in turn, lift monad transformers over it yourself, etc. =( I have more code for working around this aspect of Haskeline than I do for working with it. But it appears, in this case, Judah needed it for working with InputT, and chose to implement that by lifting transformer-by-transformer, since internally InputT is made by wrapping up an mtl-based type in a newtype. -Edward > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Wed Mar 25 21:51:57 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 25 Mar 2015 18:51:57 -0300 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Thanks for doing this, AFAIK there is no bindist for 7.10.3 on the Mac. I downloaded and installed it, works great. I used it to install hlint and criterion. The only issue I saw was that uninstall didn't remove ghc executables of older versions that I had in /usr/local/bin (earlier bindist of 7.10.1rc2). Looking forward to using next version for 7.10.1 final Thanks again On Mon, Mar 23, 2015 at 2:13 AM, Mark Lentczner wrote: > I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 > using GHC 7.10 RC3. > > I bumped all the GHC libs to the versions in 7.10, and bumped all the > Platform libs to the latest versions I could find on Hackage. There were a > few issues: > > - *old-locale and old-time* - no longer part of GHC, but > cabal-install, cgi & HTTP need them - and they are part of the platform - > so included now as added packages. Not sure this is a great idea, since > they are now very deprecated... but until cabal-install, cgi, & HTTP > update, not sure what else to do. > - *tf-random* - is now required by alex and QuickCheck - seems a shame > to add this, as now we're going to have two random packages > - *network-uri *- was split out of network, and needed by > cabal-install, cgi, & HTTP. I suppose we should include it, as it was > functionality and API that was part of the platform > - *exceptions* & *multipart* - needed by cgi - is exceptions now > subsumed by something in transformers? and... multipart? maybe time to drop > cgi? We didn't have it last time anyway as it wouldn't compile! > - *scientific* - needed by attoparsec - debated in detail last time > ... and we're still here! > > The Platform is significantly larger now: On OS X it has gone from 316M to > 499M! Most of this is due to new OpenGL libs which are now huge (went from > 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the whole > installed magilla is 1.5G! Even the compressed installer is now 250M! > > If you want to poke at it, the source is in the pre-release branch at > GitHub , > and the OS X builds are at my usual platform staging area: > > Index of /mark/platform > > > Remember, it already includes GHC, so no need to download the GHC binary > for OS X that is there, too. > > I'll try to get a generic linux build up soonish... but my VM now runs out > of memory trying to build OpenGL - and adding more only makes my machine > thrash to death! > > - Mark > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Mar 26 09:36:04 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Mar 2015 09:36:04 +0000 Subject: wither the Platform In-Reply-To: <909148175.1481073.1427304848552.JavaMail.yahoo@mail.yahoo.com> References: <909148175.1481073.1427304848552.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5e71ff0c20374a578c6e3844577f3407@DB4PR30MB030.064d.mgd.msft.net> | 2. Less diversity in new GHC features: The GHC developers have generally | aimed new features at a future release, where the existence and stability | of new features has driven their incorporation. It was assumed that the | Platform would eventually catch up. If the GHC release and the | corresponding Platform release are simultaneous, then some GHC features | may need to be pushed out to the following release so there is time for | the Platform to be adapted. | 3. The GHC development process will need to become more phased: | Experimentation with new features will still be encouraged, but adoption | of the new features will need to be gated to correspond with what the | Platform can implement. (This is really another view of issue 2.) I'm not sure that's true. We try hard not to break backward compatibility with new features. So a new GHC/HP release might have new features in GHC that are simply un-exploited by the HP libraries. That's fine! By far the biggest backward-compat issues are related to changes in the libraries themselves, rather than new features. Simon From hesselink at gmail.com Thu Mar 26 09:39:48 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 26 Mar 2015 10:39:48 +0100 Subject: quick report using GHC 7.10 RC3 In-Reply-To: References: Message-ID: On Mon, Mar 23, 2015 at 6:44 AM, Mark Lentczner wrote: > 7. Cabal incompatible API change > In particular, the api that a custom Setup.hs uses. > Distribution.Simple.UserHooks changed the type of a hook. It should not, it > should have added another to do what it wanted. The poblem is you can't use > CPP in Setup.hs. And so now anyone using the testHook hook is in a pickle: > Your Setup.hs can't work in both 7.10 and 7.8! It can, but it's a bit tricky. When this happened before, people used a type class with two instances, where one of them filled in a default argument, IIRC. I can't find the exact code now, perhaps others remember this better. Erik From simonpj at microsoft.com Thu Mar 26 09:40:44 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Mar 2015 09:40:44 +0000 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <9500237d82fa4680828718f2b4cc462c@DB4PR30MB030.064d.mgd.msft.net> Good plan. You didn?t mention a key point: ? Make sure that installing the Platform doesn?t get in the way, if you subsequently want to upgrade libraries or whatever. I am un-clear about precisely what the problem(s) is/are here. I?m pretty sure they require infrastructure work (in Cabal) to achieve. Simon From: Mark Lentczner [mailto:mark.lentczner at gmail.com] Sent: 25 March 2015 14:25 To: Simon Peyton Jones Cc: Gershom B; Manuel M T Chakravarty; haskell-platform at projects.haskell.org; haskell-infrastructure at community.galois.com; Duncan Coutts; ghc-devs at haskell.org; Haskell Libraries Subject: Re: wither the Platform On Wed, Mar 25, 2015 at 2:09 AM, Simon Peyton Jones > wrote: Yes! Our plan for GHC, dating back to the dawn of the Haskell Platform, was this: ... I still like that plan! Concrete proposal based on that and the other fine input in the responses: Simultaneous Release: Since it is organizationally impractical to have one release, let's have GHC and Platform release at the same moment. That is, GHC HQ would keep a release in "RC" until HP was ready. By the same token, HP team commits to tracking GHC from RC1, and aiming to hit ready for release within a week of GHC being ready. Both go "release" in the same announcement. In fact, let's version HP with the same number as GHC! Pare the Platform Back: Bring down the number of packages in the Platform, focusing on the things that everyone needs, like text and vector, etc. I reckon that about 1/3 of the packages should go. And, make that stuff be the latest it can be at each release. The OpenGL stuff is a hard one, since it is large, but a very big painful build if you need it. Perhaps we need server/non-server versions of the platform - but only if we can get them out on the same day. Make sure the Platform Installers are Complete: I don't know Windows, but if this means adding MSYS, great.. let's do it. The Mac installer has a version switching script and supports multiple installed versions already, but people didn't seem to know. There needs to be more documentation. Make Updating the Packages in Cabal 'work': I'm unclear on the right technical path here, but we need away for Cabal to understand that a) it can't update the stuff tied to GHC, b) it *can* update the other stuff installed from the platform, but as a cohesive set, c) it can easily (and optionally) do (b) in just a sandbox, or in the global(-ish) install. One Web Site: Drop the separate Platform website. Incorporate it into the lovely new Haskell one. Put all the documentation there. This certainly has implications for how we choose what is in the platform, and how we position those packages. In particular, packages in the past have been stuck at older versions because of the requirement that the transitive dependencies be added to the platform, with the support guarantee that implies. I think we'd have to change that: There are packages in the platform, like attoparsec, packages that are there because they are dependencies, like scientific, but who knows if they will be there next time! Now, normally I'm the crazy, ranty stability guy. But, I'm thinking this: It is better to have clear release points that package developers can test against, then to have the current slidey scale of different stability guarntees, on different release schedules that we have now. And, to be honest, I realize that the Haskell community "hath spoken" recently on the issue and prefers things to evolve even if the APIs change... I think we can do this if all the great volunteer talent in our community steps up. Shall we? ? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Mar 26 09:54:59 2015 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 26 Mar 2015 09:54:59 +0000 Subject: quick report using GHC 7.10 RC3 In-Reply-To: References: Message-ID: On Thu, Mar 26, 2015 at 11:40 AM Erik Hesselink wrote: > On Mon, Mar 23, 2015 at 6:44 AM, Mark Lentczner > wrote: > > > 7. Cabal incompatible API change > > In particular, the api that a custom Setup.hs uses. > > Distribution.Simple.UserHooks changed the type of a hook. It should not, > it > > should have added another to do what it wanted. The poblem is you can't > use > > CPP in Setup.hs. And so now anyone using the testHook hook is in a > pickle: > > Your Setup.hs can't work in both 7.10 and 7.8! > > It can, but it's a bit tricky. When this happened before, people used > a type class with two instances, where one of them filled in a default > argument, IIRC. I can't find the exact code now, perhaps others > remember this better. > > > I wrote a blog post in June of last year[1] and was told that some of those tricks are used to Cabal files. I also don't have a link to a real example, but the blog post may help. Michael [1] http://www.yesodweb.com/blog/2014/06/evil-conditional-compile -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Mar 26 12:48:30 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 26 Mar 2015 12:48:30 +0000 Subject: Typeable Message-ID: Iavor, Richard, and others We always thought it was the Right Thing to generate the runtime representation for a TyCon (used in Typeable type representations) at the definition site of the type, not "on the fly". I thought I'd do this. But it was a LOT harder than I expected. I have spent a ridiculous amount of time on it over the last three weeks. Sigh. However (a) it's done, (b) I did a lot of other tidying up (as usual). So I'm keen to use it. Would you like to take a look? It's on branch wip/T9858-typeable-spj. Relevant log messages below. Unsurprisingly, some perf/compiler tests get a bit slower (see below). More surprisingly, there are two perf/should_run tests that get worse perf/should_run T5205 [stat not good enough] (normal) perf/should_run lazy-bs-alloc [stat not good enough] (normal) This is much more surprising: neither seems to have anything much to do with Typeable. But I can't investigate before I go on holiday. Would anyone else like to? It's all up to date wrt HEAD. Simon commit fcd18c42b6ae2e73a9f4c67dbe6d994b0f8468c8 Author: Simon Peyton Jones Date: Thu Mar 26 11:06:12 2015 +0000 Remove a redndant 'return' commit a6200759fd2f3f0e901cb2092e148bf31abb08b4 Author: Simon Peyton Jones Date: Mon Mar 23 14:53:53 2015 +0000 Error message wibbles These are associated with - new instance reporting - typeable changes in -ddump-simpl output - -ddump-types being a bit less verbose - some renaming of type variables in debugger output (no idea why this happens) commit fe510d911b6cf61d6884b8b42d8771d4aea3229f Author: Simon Peyton Jones Date: Mon Mar 23 14:50:23 2015 +0000 Generate Typeble info at definition sites This patch implements the idea floated in #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: - we need to have enough data types around to *define* a TyCon - many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp T1969 T1969: GHC allocates 30% more T5642: GHC allocates 14% more T9872d: GHC allocates 5% more I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, - a type *family* (whether type or data) is repesented by a FamilyTyCon - a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. * I added PatSynId, DefMethId, and ReflectionId to the IdInfo.IdDetails type. They are used for debugging only, namely to suppress excessive output in -ddump-types. * Tidy up the generation of PrelInfo.knownKeyNames * Move newImplicitBinder from IfaceEnv to BuildTyCl * PrelNames.conName renamed to dcQual for consistency with varQual, tcQual * Move mkDefaultMethodIds, mkRecSelBinds from TcTyClsDecls to TcTyDecls commit 021e6f583a1159b0a3581ab1713d560cadc2bdf7 Author: Simon Peyton Jones Date: Mon Mar 23 14:32:31 2015 +0000 tcRnDeclsi can use tcRnSrcDecls I'm not sure why tcRnDeclsi didn't call tcRnSrcDecls before, but now it does. About 20 lines of code vanish. Hooray. commit 6473d110ab1aa22a5933e405b59e3f597562ce02 Author: Simon Peyton Jones Date: Fri Mar 20 12:38:42 2015 +0000 Implement lookupGlobal in TcEnv, and use it This localises the (revolting) initTcForLookup function, exposing instead the more civilised interface for lookupGlobal commit 7078a11f50e3af9139dd5ceef032e89047677833 Author: Simon Peyton Jones Date: Fri Mar 20 12:36:22 2015 +0000 Comments and white space commit 48512df5751a07fd503f0ba523e5504d09ee258d Author: Simon Peyton Jones Date: Fri Mar 20 12:27:59 2015 +0000 Improve the error messages for class instance errors See Note [Displaying potential instances]. simonpj at cam-05-unx:~/code/HEAD-5$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Mar 26 13:23:32 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 26 Mar 2015 09:23:32 -0400 Subject: Typeable In-Reply-To: References: Message-ID: I'll take a look in the next few days. I'm concerned about that performance regression -- we'll need to get a handle on it. Enjoy your holiday! Richard On Mar 26, 2015, at 8:48 AM, Simon Peyton Jones wrote: > Iavor, Richard, and others > > We always thought it was the Right Thing to generate the runtime representation for a TyCon (used in Typeable type representations) at the definition site of the type, not ?on the fly?. I thought I?d do this. > > But it was a LOT harder than I expected. I have spent a ridiculous amount of time on it over the last three weeks. Sigh. > > However (a) it?s done, (b) I did a lot of other tidying up (as usual). So I?m keen to use it. > > Would you like to take a look? It?s on branch wip/T9858-typeable-spj. Relevant log messages below. > > Unsurprisingly, some perf/compiler tests get a bit slower (see below). > > More surprisingly, there are two perf/should_run tests that get worse > > perf/should_run T5205 [stat not good enough] (normal) > > perf/should_run lazy-bs-alloc [stat not good enough] (normal) > > This is much more surprising: neither seems to have anything much to do with Typeable. But I can?t investigate before I go on holiday. Would anyone else like to? > > It?s all up to date wrt HEAD. > > Simon > > > > > > commit fcd18c42b6ae2e73a9f4c67dbe6d994b0f8468c8 > Author: Simon Peyton Jones > Date: Thu Mar 26 11:06:12 2015 +0000 > > Remove a redndant 'return' > > commit a6200759fd2f3f0e901cb2092e148bf31abb08b4 > Author: Simon Peyton Jones > Date: Mon Mar 23 14:53:53 2015 +0000 > > Error message wibbles > > These are associated with > - new instance reporting > - typeable changes in -ddump-simpl output > - -ddump-types being a bit less verbose > - some renaming of type variables in debugger output (no idea why this happens) > > commit fe510d911b6cf61d6884b8b42d8771d4aea3229f > Author: Simon Peyton Jones > Date: Mon Mar 23 14:50:23 2015 +0000 > > Generate Typeble info at definition sites > > This patch implements the idea floated in #9858, namely that we should > generate type-representation information at the data type declaration > site, rather than when solving a Typeable constraint. > > However, this turned out quite a bit harder than I expected. I still > think it's the right thing to do, and it's done now, but it was quite > a struggle. > > See particularly > * Note [Grand plan for Typeable] in TcTypeable (which is a new module) > * Note [The overall promotion story] in DataCon (clarifies existing stuff) > > The most painful bit was that to generate Typeable instances (ie TyConRepName > bindings) for every TyCon is tricky for types in ghc-prim etc: > - we need to have enough data types around to *define* a TyCon > - many of these types are wired-in > > Also, to minimise the code generated for each data type, I wanted to generate > pure data, not CAFs with unpackCString# stuff floating about. > > Performance > ~~~~~~~~~~~ > Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, > because they all allocate zillions of data types, with practically no other code, > esp T1969 > > T1969: GHC allocates 30% more > T5642: GHC allocates 14% more > T9872d: GHC allocates 5% more > > I'm treating this as acceptable. The payoff comes in Typeable-heavy code. > > Remaining to do > ~~~~~~~~~~~~~~~ > * I think that "TyCon" and "Module" are over-generic names to use for > the runtime type representations used in GHC.Typeable. Better might > be "TrTyCon" and "TrModule". But I have not yet done this > > * Add more info the the "TyCon" e.g. source location where it was defined > > * Use the new "Module" type to help with Trac #10068 > > * It would be possible to generate TyConRepName (ie Typeable instances) > selectively rather than all the time. We'd need to persist the information > in interface files. Lacking a motivating reason I have not done this, but > it would not be difficult. > > Refactoring > ~~~~~~~~~~~ > As is so often the case, I ended up refactoring more than I intended. > In particular > > * In TyCon, > - a type *family* (whether type or data) > is repesented by a FamilyTyCon > - a algebraic data type (including data/newtype instances) > is represented by AlgTyCon > This wasn't true before; a data family was represented as > an AlgTyCon. There are some corresponding changes in IfaceSyn. > > Also get rid of the (unhelpfully named) tyConParent. > > * In TyCon define 'Promoted', isomorphic to Maybe, used when things > are optionally promoted; and use it elsewhere in GHC. > > * Each TyCon, including promoted TyCons, contains its TyConRepName, > if it has one. This is, in effect, the name of its Typeable > instance. > > * I added PatSynId, DefMethId, and ReflectionId to the IdInfo.IdDetails > type. They are used for debugging only, namely to suppress excessive > output in -ddump-types. > > * Tidy up the generation of PrelInfo.knownKeyNames > > * Move newImplicitBinder from IfaceEnv to BuildTyCl > > * PrelNames.conName renamed to dcQual for consistency with varQual, tcQual > > * Move mkDefaultMethodIds, mkRecSelBinds from TcTyClsDecls to TcTyDecls > > commit 021e6f583a1159b0a3581ab1713d560cadc2bdf7 > Author: Simon Peyton Jones > Date: Mon Mar 23 14:32:31 2015 +0000 > > tcRnDeclsi can use tcRnSrcDecls > > I'm not sure why tcRnDeclsi didn't call tcRnSrcDecls before, but now it > does. About 20 lines of code vanish. Hooray. > > commit 6473d110ab1aa22a5933e405b59e3f597562ce02 > Author: Simon Peyton Jones > Date: Fri Mar 20 12:38:42 2015 +0000 > > Implement lookupGlobal in TcEnv, and use it > > This localises the (revolting) initTcForLookup function, exposing > instead the more civilised interface for lookupGlobal > > commit 7078a11f50e3af9139dd5ceef032e89047677833 > Author: Simon Peyton Jones > Date: Fri Mar 20 12:36:22 2015 +0000 > > Comments and white space > > commit 48512df5751a07fd503f0ba523e5504d09ee258d > Author: Simon Peyton Jones > Date: Fri Mar 20 12:27:59 2015 +0000 > > Improve the error messages for class instance errors > > See Note [Displaying potential instances]. > simonpj at cam-05-unx:~/code/HEAD-5$ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Mar 26 14:50:38 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 26 Mar 2015 10:50:38 -0400 Subject: Typeable In-Reply-To: References: Message-ID: This is now on Phab as https://phabricator.haskell.org/D757 I'll be making some comments there. On Mar 26, 2015, at 9:23 AM, Richard Eisenberg wrote: > I'll take a look in the next few days. I'm concerned about that performance regression -- we'll need to get a handle on it. > > Enjoy your holiday! > > Richard > > On Mar 26, 2015, at 8:48 AM, Simon Peyton Jones wrote: > >> Iavor, Richard, and others >> >> We always thought it was the Right Thing to generate the runtime representation for a TyCon (used in Typeable type representations) at the definition site of the type, not ?on the fly?. I thought I?d do this. >> >> But it was a LOT harder than I expected. I have spent a ridiculous amount of time on it over the last three weeks. Sigh. >> >> However (a) it?s done, (b) I did a lot of other tidying up (as usual). So I?m keen to use it. >> >> Would you like to take a look? It?s on branch wip/T9858-typeable-spj. Relevant log messages below. >> >> Unsurprisingly, some perf/compiler tests get a bit slower (see below). >> >> More surprisingly, there are two perf/should_run tests that get worse >> >> perf/should_run T5205 [stat not good enough] (normal) >> >> perf/should_run lazy-bs-alloc [stat not good enough] (normal) >> >> This is much more surprising: neither seems to have anything much to do with Typeable. But I can?t investigate before I go on holiday. Would anyone else like to? >> >> It?s all up to date wrt HEAD. >> >> Simon >> >> >> >> commit fcd18c42b6ae2e73a9f4c67dbe6d994b0f8468c8 >> Author: Simon Peyton Jones >> Date: Thu Mar 26 11:06:12 2015 +0000 >> >> Remove a redndant 'return' >> >> commit a6200759fd2f3f0e901cb2092e148bf31abb08b4 >> Author: Simon Peyton Jones >> Date: Mon Mar 23 14:53:53 2015 +0000 >> >> Error message wibbles >> >> These are associated with >> - new instance reporting >> - typeable changes in -ddump-simpl output >> - -ddump-types being a bit less verbose >> - some renaming of type variables in debugger output (no idea why this happens) >> >> commit fe510d911b6cf61d6884b8b42d8771d4aea3229f >> Author: Simon Peyton Jones >> Date: Mon Mar 23 14:50:23 2015 +0000 >> >> Generate Typeble info at definition sites >> >> This patch implements the idea floated in #9858, namely that we should >> generate type-representation information at the data type declaration >> site, rather than when solving a Typeable constraint. >> >> However, this turned out quite a bit harder than I expected. I still >> think it's the right thing to do, and it's done now, but it was quite >> a struggle. >> >> See particularly >> * Note [Grand plan for Typeable] in TcTypeable (which is a new module) >> * Note [The overall promotion story] in DataCon (clarifies existing stuff) >> >> The most painful bit was that to generate Typeable instances (ie TyConRepName >> bindings) for every TyCon is tricky for types in ghc-prim etc: >> - we need to have enough data types around to *define* a TyCon >> - many of these types are wired-in >> >> Also, to minimise the code generated for each data type, I wanted to generate >> pure data, not CAFs with unpackCString# stuff floating about. >> >> Performance >> ~~~~~~~~~~~ >> Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, >> because they all allocate zillions of data types, with practically no other code, >> esp T1969 >> >> T1969: GHC allocates 30% more >> T5642: GHC allocates 14% more >> T9872d: GHC allocates 5% more >> >> I'm treating this as acceptable. The payoff comes in Typeable-heavy code. >> >> Remaining to do >> ~~~~~~~~~~~~~~~ >> * I think that "TyCon" and "Module" are over-generic names to use for >> the runtime type representations used in GHC.Typeable. Better might >> be "TrTyCon" and "TrModule". But I have not yet done this >> >> * Add more info the the "TyCon" e.g. source location where it was defined >> >> * Use the new "Module" type to help with Trac #10068 >> >> * It would be possible to generate TyConRepName (ie Typeable instances) >> selectively rather than all the time. We'd need to persist the information >> in interface files. Lacking a motivating reason I have not done this, but >> it would not be difficult. >> >> Refactoring >> ~~~~~~~~~~~ >> As is so often the case, I ended up refactoring more than I intended. >> In particular >> >> * In TyCon, >> - a type *family* (whether type or data) >> is repesented by a FamilyTyCon >> - a algebraic data type (including data/newtype instances) >> is represented by AlgTyCon >> This wasn't true before; a data family was represented as >> an AlgTyCon. There are some corresponding changes in IfaceSyn. >> >> Also get rid of the (unhelpfully named) tyConParent. >> >> * In TyCon define 'Promoted', isomorphic to Maybe, used when things >> are optionally promoted; and use it elsewhere in GHC. >> >> * Each TyCon, including promoted TyCons, contains its TyConRepName, >> if it has one. This is, in effect, the name of its Typeable >> instance. >> >> * I added PatSynId, DefMethId, and ReflectionId to the IdInfo.IdDetails >> type. They are used for debugging only, namely to suppress excessive >> output in -ddump-types. >> >> * Tidy up the generation of PrelInfo.knownKeyNames >> >> * Move newImplicitBinder from IfaceEnv to BuildTyCl >> >> * PrelNames.conName renamed to dcQual for consistency with varQual, tcQual >> >> * Move mkDefaultMethodIds, mkRecSelBinds from TcTyClsDecls to TcTyDecls >> >> commit 021e6f583a1159b0a3581ab1713d560cadc2bdf7 >> Author: Simon Peyton Jones >> Date: Mon Mar 23 14:32:31 2015 +0000 >> >> tcRnDeclsi can use tcRnSrcDecls >> >> I'm not sure why tcRnDeclsi didn't call tcRnSrcDecls before, but now it >> does. About 20 lines of code vanish. Hooray. >> >> commit 6473d110ab1aa22a5933e405b59e3f597562ce02 >> Author: Simon Peyton Jones >> Date: Fri Mar 20 12:38:42 2015 +0000 >> >> Implement lookupGlobal in TcEnv, and use it >> >> This localises the (revolting) initTcForLookup function, exposing >> instead the more civilised interface for lookupGlobal >> >> commit 7078a11f50e3af9139dd5ceef032e89047677833 >> Author: Simon Peyton Jones >> Date: Fri Mar 20 12:36:22 2015 +0000 >> >> Comments and white space >> >> commit 48512df5751a07fd503f0ba523e5504d09ee258d >> Author: Simon Peyton Jones >> Date: Fri Mar 20 12:27:59 2015 +0000 >> >> Improve the error messages for class instance errors >> >> See Note [Displaying potential instances]. >> simonpj at cam-05-unx:~/code/HEAD-5$ >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From yongqli at 10gic.net Fri Mar 27 00:50:14 2015 From: yongqli at 10gic.net (Yongqian Li) Date: Thu, 26 Mar 2015 17:50:14 -0700 Subject: GHC 7.10 Regression(?) regarding Unicode subscript characters in identifiers Message-ID: Is this a bug, and if so, will it be fixed before the final release? We currently use subscript characters in our identifiers and would like to see the old behavior restored... From ecrockett0 at gmail.com Fri Mar 27 03:06:03 2015 From: ecrockett0 at gmail.com (Eric Crockett) Date: Thu, 26 Mar 2015 23:06:03 -0400 Subject: Fwd: [hackage-server] Duplicate anchors in source code (#319) In-Reply-To: References: Message-ID: I reported a bug in HsColour ( https://github.com/haskell/hackage-server/issues/319#issuecomment-76088047) which has been fixed in a new version. The HSColour dev thought it might be useful to mention this new version of HsColour to the GHC devs so that documentation for 7.10 will be marginally easier to reference. -Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Fri Mar 27 07:43:48 2015 From: austin at well-typed.com (Austin Seipp) Date: Fri, 27 Mar 2015 02:43:48 -0500 Subject: ANNOUNCE: GHC version 7.10.1 Message-ID: ============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.10.1 ============================================================== The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Several new language features and changes have been implemented: - Applicative is now a superclass of Monad and in the Prelude. - Many prelude combinators have been generalized - Static pointers * GHC now has preliminary and experimental support for DWARF based debugging. * `integer-gmp` has been completely rewritten. * Type-checking plugins can now extend the type checker. * Support for partial type signatures * Many bugfixes and other performance improvements. * Preliminary support for 'backpack' features like signatures. * Typeable is now generated by default for all data types automatically. We've also fixed a handful of issues reported since RC3: - A bug in the call arity analysis that would result in invalid core was fixed (#10176) - A bug in the Win32 package causing it to fail to load was fixed (#10165) - ghc-prim has (correctly) been bumped to version 0.4.0.0, to comply with the PVP. - Several libraries have been bumped to their latest available versions after coordination. The full release notes are here: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-10-1.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Platforms https://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://www.haskell.org/mailman/listinfo/glasgow-haskell-users https://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ On https://downloads.haskell.org/~ghc/7.10.1/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key (0F8F 3AA9 9235 C704 ADA0 B419 B942 AEE5 3B58 D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From jan.stolarek at p.lodz.pl Fri Mar 27 08:21:09 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 27 Mar 2015 09:21:09 +0100 Subject: ANNOUNCE: GHC version 7.10.1 In-Reply-To: References: Message-ID: <201503270921.10136.jan.stolarek@p.lodz.pl> Austin, links to x86_64 linux versions for CentOS don't work. Janek Dnia pi?tek, 27 marca 2015, Austin Seipp napisa?: > ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 7.10.1 > ============================================================== > > The GHC Team is pleased to announce a new major release of GHC. There > have been a number of significant changes since the last major > release, including: > > * Several new language features and changes have been implemented: > - Applicative is now a superclass of Monad and in the Prelude. > > - Many prelude combinators have been generalized > > - Static pointers > > * GHC now has preliminary and experimental support for DWARF based > debugging. > > * `integer-gmp` has been completely rewritten. > > * Type-checking plugins can now extend the type checker. > > * Support for partial type signatures > > * Many bugfixes and other performance improvements. > > * Preliminary support for 'backpack' features like signatures. > > * Typeable is now generated by default for all data types automatically. > > We've also fixed a handful of issues reported since RC3: > > - A bug in the call arity analysis that would result in invalid core > was fixed (#10176) > - A bug in the Win32 package causing it to fail to load was fixed > (#10165) - ghc-prim has (correctly) been bumped to version 0.4.0.0, to > comply with the PVP. > - Several libraries have been bumped to their latest available > versions after coordination. > > The full release notes are here: > > https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-1 >0-1.html > > > How to get it > ~~~~~~~~~~~~~ > > The easy way is to go to the web page, which should be self-explanatory: > > https://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~~~~~~~~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating good code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces (C, whatever). GHC is distributed under a > BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Relevant URLs on the World-Wide Web: > > GHC home page http://www.haskell.org/ghc/ > GHC developers' home page http://ghc.haskell.org/trac/ghc/ > Haskell home page http://www.haskell.org/ > > > Supported Platforms > ~~~~~~~~~~~~~~~~~~~ > > The list of platforms we support, and the people responsible for them, > is here: > > https://ghc.haskell.org/trac/ghc/wiki/Platforms > https://ghc.haskell.org/trac/ghc/wiki/CodeOwners > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > https://ghc.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~~~~~~~~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > https://ghc.haskell.org/trac/ghc/ > > > Mailing lists > ~~~~~~~~~~~~~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > https://www.haskell.org/mailman/listinfo/glasgow-haskell-users > https://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > https://www.haskell.org/mailman/listinfo/ > > Some GHC developers hang out on #haskell on IRC, too: > > https://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > https://www.haskell.org/ghc/reportabug > > > Hashes & Signatures > ~~~~~~~~~~~~~~~~~ > > On https://downloads.haskell.org/~ghc/7.10.1/ you will find a signed > copy of the SHA256 hashes for the tarballs, using my GPG key (0F8F > 3AA9 9235 C704 ADA0 B419 B942 AEE5 3B58 D86F). --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From thomasmiedema at gmail.com Fri Mar 27 09:32:08 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 27 Mar 2015 10:32:08 +0100 Subject: GHC 7.10 Regression(?) regarding Unicode subscript characters in identifiers In-Reply-To: References: Message-ID: I opened the following ticket for this issue: https://ghc.haskell.org/trac/ghc/ticket/10196 On Fri, Mar 27, 2015 at 1:50 AM, Yongqian Li wrote: > Is this a bug, and if so, will it be fixed before the final release? > We currently use subscript characters in our identifiers and would > like to see the old behavior restored... > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmiedema at gmail.com Fri Mar 27 10:03:32 2015 From: thomasmiedema at gmail.com (Thomas Miedema) Date: Fri, 27 Mar 2015 11:03:32 +0100 Subject: GHC 7.10 Regression(?) regarding Unicode subscript characters in identifiers In-Reply-To: References: Message-ID: Yonqian, if subscript characters were allowed starting from the second character of an identifier, would that be sufficient for you? Please comment on https://ghc.haskell.org/trac/ghc/ticket/10196, or here. Thomas On Fri, Mar 27, 2015 at 10:32 AM, Thomas Miedema wrote: > I opened the following ticket for this issue: > https://ghc.haskell.org/trac/ghc/ticket/10196 > > On Fri, Mar 27, 2015 at 1:50 AM, Yongqian Li wrote: > >> Is this a bug, and if so, will it be fixed before the final release? >> We currently use subscript characters in our identifiers and would >> like to see the old behavior restored... >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Fri Mar 27 12:24:37 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Fri, 27 Mar 2015 13:24:37 +0100 Subject: wither the Platform In-Reply-To: (Mark Lentczner's message of "Wed, 25 Mar 2015 07:24:30 -0700") References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <87r3saocfu.fsf@gnu.org> On 2015-03-25 at 15:24:30 +0100, Mark Lentczner wrote: [...] > Concrete proposal based on that and the other fine input in the responses: > > *Simultaneous Release:* Since it is organizationally impractical to have > one release, let's have GHC and Platform release at the same moment. That > is, GHC HQ would keep a release in "RC" until HP was ready. By the same > token, HP team commits to tracking GHC from RC1, and aiming to hit ready > for release within a week of GHC being ready. Both go "release" in the same > announcement. *In fact, let's version HP with the same number as GHC!* [...] I'm a bit worried about the aspect of delaying the GHC release schedule for the sole purpose to provide the HP with more visibility, while penalising those users that have no interest to use the HP anyway. Otoh, there's usually enough time between the last RC and the actual final release, which should give the HP at least one week of time anyway w/o any active delay on GHC's end. Otoh, as soon as the new HP is released, it provides users with the perception of a new stable HP release to jump on right-away. That, however, may lead to a poor experience if the it's the first HP release for a given major GHC version as Hackage usually hasn't fully caught up by the time a GHC x.y.1 is unleashed. So if we had co-released a HP featuring GHC 7.10.1 today, there would still be enough Hackage packages not yet compatible with GHC 7.10.1 to recommend users *not* to install the release right-away. So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP would be in the HP's best interest in terms of providing a reliable and complete development environment (which IMO requires access to Hackage, even more so if the HP is to be reduced to contain less packages) -- hvr From mark.lentczner at gmail.com Fri Mar 27 14:09:42 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 27 Mar 2015 07:09:42 -0700 Subject: wither the Platform In-Reply-To: <87r3saocfu.fsf@gnu.org> References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> <87r3saocfu.fsf@gnu.org> Message-ID: On Fri, Mar 27, 2015 at 5:24 AM, Herbert Valerio Riedel wrote: > I'm a bit worried about the aspect of delaying the GHC release schedule > for the sole purpose to provide the HP with more visibility, That isn't the purpose at all. My aim ins't to promote HP. The aim of my suggestion is to ensure that there is a consistent way for the community to "get Haskell" (as GHC itself is not enough for anyone - you need cabal at the least, and there are libraries that are common enough to be considered essential: text, vector, etc...). It is also to ensure there is a consistent reference point for package developers to test their packages against, for those packages that wish to support more than just the current GHC. Again, GHC releases themselves do not form a big enough reference point to ensure two packages that "support the last two release" are supporting the same thing. ... > Otoh, > there's usually enough time between the last RC and the actual final > release, which should give the HP at least one week of time anyway w/o > any active delay on GHC's end. > Well - if there is a week of commits to GHC, it should really do another RC before declaring it final. The difference between the last RC and the release should a single commit of no more than the version number change and the change log. Frankly, if we are all on board with this, then GHC could suffer a few day (week at most) delay between such an RC (as in "we're frozen, save for the version stamp"), and announcing "release". This would not only allow there to be a Platform on the same day - but also GHC bindists for other OSes on the same day. > Otoh, as soon as the new HP is released, it provides users with the > perception of a new stable HP release to jump on right-away. That, > however, may lead to a poor experience if the it's the first HP release > for a given major GHC version as Hackage usually hasn't fully caught up > by the time a GHC x.y.1 is unleashed. We need to have to maintainers of the packages in the HP on board with this and down with the "we're all going to gear up in the four weeks before a GHC version"... not "we'll gear up in the four weeks after". Frankly, for the kinds of packages that are in the platform (text, vector, unordered containers, etc...), having these packages lag GHC release so that they are broken on Hackage the day of GHC release is in nobody's interest: It gives a poor experience for ALL users of Haskell. So if we had co-released a HP > featuring GHC 7.10.1 today, there would still be enough Hackage packages > not yet compatible with GHC 7.10.1 to recommend users *not* to install > the release right-away. > But that is true of GHC as well. We need to stop having the attitude of "Platform is for newcomers / GHC is for heavyweights". It is perfectly fine to announce "GHC 7.10.1 is out - you can install it from Platform 7.10.1 which is a complete installer for your OS with core and standard libraries, and tools; or if you prefer you can get the minimal binary compiler build. As always, not all packages on Hackage will be compatible." Then our recommendations on to users on IRC are about which version is best for their needs, not "don't install platform, you won't be able to get lens to compile..." > So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP > would be in the HP's best interest in terms of providing a reliable and > complete development environment (which IMO requires access to Hackage, > even more so if the HP is to be reduced to contain less packages) > People who care about stability will go ahead and hang back to what they consider a stable reference for them. (Gosh, how many projects are still supporting Python 2.6?!). But it will only be a "stable reference" if people use it, and package maintainers support it. Today's mess of GHC releases, Platform releases, alternative installer releases, etc... leaves both users and package maintainers no way to create or find stability. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Mar 27 14:27:38 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 27 Mar 2015 10:27:38 -0400 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> <87r3saocfu.fsf@gnu.org> Message-ID: On Fri, Mar 27, 2015 at 10:09 AM, Mark Lentczner wrote: > But that is true of GHC as well. We need to stop having the attitude of > "Platform is for newcomers / GHC is for heavyweights". It is perfectly fine > to announce "GHC 7.10.1 is out - you can install it from Platform 7.10.1 > which is a complete installer for your OS with core and standard libraries, > and tools; or if you prefer you can get the minimal binary compiler build. > As always, not all packages on Hackage will be compatible." Then our > recommendations on to users on IRC are about which version is best for > their needs, not "don't install platform, you won't be able to get lens to > compile..." > The lens package (alongside every other package I maintain that is incurred as a dependency of lens) has very deliberately support all Haskell Platform releases for at least 3 current major GHC releases, often at great expense to the API. No offense, but I don't think lens is the culprit here. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Fri Mar 27 14:35:36 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 27 Mar 2015 07:35:36 -0700 Subject: wither the Platform In-Reply-To: References: <1427151077.11324.459.camel@dunky.localdomain> <3a60c7dc14df4c74b972db8f2738e235@DB4PR30MB030.064d.mgd.msft.net> <87r3saocfu.fsf@gnu.org> Message-ID: On Fri, Mar 27, 2015 at 7:27 AM, Edward Kmett wrote: > The lens package (alongside every other package I maintain that is > incurred as a dependency of lens) has very > deliberately support all Haskell Platform releases for at least 3 current > major GHC releases, often at great expense to the API. > > No offense, but I don't think lens is the culprit here. > Excellent! None taken. I appologize for my poor choice of example. Several people have included lens in an example of "newcomers want to install x, y, and z - and it won't work with the platform." It is great that lens is not the problem - but it does underscore that the other packages haven't seen fit to match the same stability release points as lens - hence the unlikeliness of them working together except at HEAD. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Fri Mar 27 14:41:27 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 27 Mar 2015 07:41:27 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: NO MOAR BIKESHEDS! I don't want to release in the platform an API that is out of date the day we release it. So we either go with the new (and I'm trusting Sven to vouch for 'it's the right API, we'll support this for the next year or so') - or we drop OpenGL* from the platform release - or we do "with and without" releases. Votes? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Fri Mar 27 14:42:38 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 27 Mar 2015 07:42:38 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: there is a bindist for 7.10 RC3 - right alongside the HP I built. I'm the builder for the bindists for GHC of OS X - not sure why Austin never put it on the GHC site. On Wed, Mar 25, 2015 at 2:51 PM, George Colpitts wrote: > Thanks for doing this, AFAIK there is no bindist for 7.10.3 on the Mac. I > downloaded and installed it, works great. I used it to install hlint and > criterion. The only issue I saw was that uninstall didn't remove ghc > executables of older versions that I had in /usr/local/bin (earlier bindist > of 7.10.1rc2). Looking forward to using next version for 7.10.1 final > > Thanks again > > On Mon, Mar 23, 2015 at 2:13 AM, Mark Lentczner > wrote: > >> I've gone ahead and built a very provisional, alpha version of 2015.2.0.0 >> using GHC 7.10 RC3. >> >> I bumped all the GHC libs to the versions in 7.10, and bumped all the >> Platform libs to the latest versions I could find on Hackage. There were a >> few issues: >> >> - *old-locale and old-time* - no longer part of GHC, but >> cabal-install, cgi & HTTP need them - and they are part of the platform - >> so included now as added packages. Not sure this is a great idea, since >> they are now very deprecated... but until cabal-install, cgi, & HTTP >> update, not sure what else to do. >> - *tf-random* - is now required by alex and QuickCheck - seems a >> shame to add this, as now we're going to have two random packages >> - *network-uri *- was split out of network, and needed by >> cabal-install, cgi, & HTTP. I suppose we should include it, as it was >> functionality and API that was part of the platform >> - *exceptions* & *multipart* - needed by cgi - is exceptions now >> subsumed by something in transformers? and... multipart? maybe time to drop >> cgi? We didn't have it last time anyway as it wouldn't compile! >> - *scientific* - needed by attoparsec - debated in detail last time >> ... and we're still here! >> >> The Platform is significantly larger now: On OS X it has gone from 316M >> to 499M! Most of this is due to new OpenGL libs which are now huge (went >> from 98M to 239M!) GHC itself grew by 109M (to almost 1G), so that the >> whole installed magilla is 1.5G! Even the compressed installer is now 250M! >> >> If you want to poke at it, the source is in the pre-release branch at >> GitHub , >> and the OS X builds are at my usual platform staging area: >> >> Index of /mark/platform >> >> >> Remember, it already includes GHC, so no need to download the GHC binary >> for OS X that is there, too. >> >> I'll try to get a generic linux build up soonish... but my VM now runs >> out of memory trying to build OpenGL - and adding more only makes my >> machine thrash to death! >> >> - Mark >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Fri Mar 27 15:28:45 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 27 Mar 2015 11:28:45 -0400 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: I'm personally a rather vocal proponent of the new OpenGL API changes. I'd also in general favor a policy of greater trust when it comes to library authors factoring out bits of their packages even once they become part of the platform. We all want our code to work together. The hand-wringing we've had over the splitting off of multipart from cgi and ObjectName or StateVar from OpenGL because designers of packages like sdl2 want to be able to support a common API without incurring a needless OpenGL dependency is largely indicative of why some folks get scared of their packages being included in the platform. And, e.g. aeson's scientific dependency is needed to ensure data going through the API doesn't lose precision, and due to stackage almost everyone has adapted to its presence for over a year. Removing it would do nobody any good. Let's bless it and move on. -Edward On Fri, Mar 27, 2015 at 10:41 AM, Mark Lentczner wrote: > NO MOAR BIKESHEDS! > > I don't want to release in the platform an API that is out of date the day > we release it. So we either go with the new (and I'm trusting Sven to vouch > for 'it's the right API, we'll support this for the next year or so') - or > we drop OpenGL* from the platform release - or we do "with and without" > releases. > > Votes? > ? > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Fri Mar 27 16:15:45 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 27 Mar 2015 16:15:45 +0000 Subject: ANNOUNCE: GHC version 7.10.1 In-Reply-To: References: Message-ID: <55158231.80409@fuuzetsu.co.uk> On 03/27/2015 07:43 AM, Austin Seipp wrote: > ============================================================== > The (Interactive) Glasgow Haskell Compiler -- version 7.10.1 > ============================================================== > > The GHC Team is pleased to announce a new major release of GHC. There > have been a number of significant changes since the last major > release, including: > > * Several new language features and changes have been implemented: > - Applicative is now a superclass of Monad and in the Prelude. > > - Many prelude combinators have been generalized > > [snip] I wanted to learn about which combinators have been updated so I click on ?GHC 7.10 Migration Guide? in linked documentation page but it seems that it doesn't lead anywhere, or rather leads to the page it's linked from. It was probably meant to link to https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10 -- Mateusz K. From randyhaskell at outlook.com Fri Mar 27 17:16:14 2015 From: randyhaskell at outlook.com (Randy Polen) Date: Fri, 27 Mar 2015 10:16:14 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 Message-ID: I am helping Mark with the Haskell Platform, doing the Windows builds (32- and 64-bit). I want you to be aware of a problem I am encountering, and solicit suggestions and possible help. In building for HP 2015.2.0.0 on Windows 7, 64-bit (haven't gotten to 32-bit yet but likely the same problem will occur), I seem to be hitting the 32K limit for the length of arguments to a process, encountered while cabal is invoking haddock to build the docs for the OpenGLRaw package. For HP2014.2.0.0, the argument list was ~25K (from looking at my old build logs) but now is ~36K, which exceeds the maximum for CreateProcess (not a limit of the command-line, but of the OS call itself). Is there a way to build haddock docs for a single package but in multiple haddock invocations (maybe building a .haddock file for portions, then combining them, with the goal that the command line is kept short)? Seems this would also require a corresponding cabal change, as cabal is the invocator when this happens. Barring any existing mechanism, the typical solution to this problem on the Windows OS is (when possible, of course) to modify the program to accept a "response file" of command-line arguments. In this case, we could add an option to haddock to accept either a complete "response file" (i.e., allowing *all* options and arguments to come from a file) or just a file containing the files to process. Either of these changes to haddock are rather trivial to write (but adding another option implies more testing, documentation, other cases to handle, etc.). Since haddock ships with the ghc release, that's another wrinkle for this particular release. The other implication of such a solution is that cabal would need a change to utilize this change for it to be effective, checking haddock's version for support of this new haddock-flag, and either use it if the haddock version supports it, or do it optionally (which implies a new flag for cabal's haddock sub-command). This change to cabal is also rather trivial to implement (this is not to imply insensitivity to the incurred cost of each line of code, nor to the added burden of user-visible changes such as a command-line option). (Less desirable possibilities, mentioned only for completeness: skip the documentation for OpenGLRaw for this version of the Haskell Platform; split up the OpenGLRaw package itself in some way.) Other possible solutions and work-arounds? Thoughts on either using haddock in a different way (and the cabal change that would be required to break up the doc build into multiple steps for a single package)? Thoughts on the "response file" solution? Randy From ekmett at gmail.com Fri Mar 27 17:39:04 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 27 Mar 2015 13:39:04 -0400 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: To ship `gl`, we wound up having to rename all of the modules to make it work on Windows. Alas, the module name conventions used by `OpenGLRaw` are longer. -Edward On Fri, Mar 27, 2015 at 1:16 PM, Randy Polen wrote: > I am helping Mark with the Haskell Platform, doing the Windows builds (32- > and > 64-bit). I want you to be aware of a problem I am encountering, and > solicit > suggestions and possible help. > > In building for HP 2015.2.0.0 on Windows 7, 64-bit (haven't gotten to > 32-bit > yet but likely the same problem will occur), I seem to be hitting the 32K > limit > for the length of arguments to a process, encountered while cabal is > invoking > haddock to build the docs for the OpenGLRaw package. For HP2014.2.0.0, the > argument list was ~25K (from looking at my old build logs) but now is ~36K, > which exceeds the maximum for CreateProcess (not a limit of the > command-line, > but of the OS call itself). > > Is there a way to build haddock docs for a single package but in multiple > haddock invocations (maybe building a .haddock file for portions, then > combining them, with the goal that the command line is kept short)? Seems > this > would also require a corresponding cabal change, as cabal is the invocator > when > this happens. > > > Barring any existing mechanism, the typical solution to this problem on the > Windows OS is (when possible, of course) to modify the program to accept a > "response file" of command-line arguments. In this case, we could add an > option to haddock to accept either a complete "response file" (i.e., > allowing > *all* options and arguments to come from a file) or just a file containing > the > files to process. Either of these changes to haddock are rather trivial to > write (but adding another option implies more testing, documentation, other > cases to handle, etc.). Since haddock ships with the ghc release, that's > another wrinkle for this particular release. The other implication of > such a > solution is that cabal would need a change to utilize this change for it > to be > effective, checking haddock's version for support of this new > haddock-flag, and > either use it if the haddock version supports it, or do it optionally > (which > implies a new flag for cabal's haddock sub-command). This change to cabal > is > also rather trivial to implement (this is not to imply insensitivity to the > incurred cost of each line of code, nor to the added burden of user-visible > changes such as a command-line option). > > > (Less desirable possibilities, mentioned only for completeness: skip the > documentation for OpenGLRaw for this version of the Haskell Platform; > split up > the OpenGLRaw package itself in some way.) > > > Other possible solutions and work-arounds? Thoughts on either using > haddock in > a different way (and the cabal change that would be required to break up > the > doc build into multiple steps for a single package)? Thoughts on the > "response > file" solution? > > > Randy > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri Mar 27 18:50:53 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 27 Mar 2015 14:50:53 -0400 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Relatedly, theres a major version bump release of primitive that's due to be cut soon, and in a month or two vector 0.11 will be ready for release one way or another. At the very least, we should try to get that new version of primitive ready for release and onto platform, since it immediately upgrades the power of any package that uses prim monad! On Mar 27, 2015 11:28 AM, "Edward Kmett" wrote: > I'm personally a rather vocal proponent of the new OpenGL API changes. > > I'd also in general favor a policy of greater trust when it comes to > library authors factoring out bits of their packages even once they become > part of the platform. We all want our code to work together. > > The hand-wringing we've had over the splitting off of multipart from cgi > and ObjectName or StateVar from OpenGL because designers of packages like > sdl2 want to be able to support a common API without incurring a needless > OpenGL dependency is largely indicative of why some folks get scared of > their packages being included in the platform. > > And, e.g. aeson's scientific dependency is needed to ensure data going > through the API doesn't lose precision, and due to stackage almost everyone > has adapted to its presence for over a year. Removing it would do nobody > any good. Let's bless it and move on. > > -Edward > > On Fri, Mar 27, 2015 at 10:41 AM, Mark Lentczner > wrote: > >> NO MOAR BIKESHEDS! >> >> I don't want to release in the platform an API that is out of date the >> day we release it. So we either go with the new (and I'm trusting Sven to >> vouch for 'it's the right API, we'll support this for the next year or so') >> - or we drop OpenGL* from the platform release - or we do "with and >> without" releases. >> >> Votes? >> ? >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Fri Mar 27 21:03:41 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 27 Mar 2015 22:03:41 +0100 Subject: [commit: ghc] master: Rename driver phases C(obj)cpp to C(obj)cplusplus (abde5da) In-Reply-To: <20150327203820.A2E593A300@ghc.haskell.org> References: <20150327203820.A2E593A300@ghc.haskell.org> Message-ID: <5515C5AD.2040309@centrum.cz> Hi Thomas, Cplusplus is quite long identifier, bad for eyes. Usually in C++ community if you can't use cpp then you use cxx. It's shorter and clear even when reading fast, don't you think? Karel PS: of course even before cxx it was CC, but I think this does not have any advantage over cxx in this context... On 03/27/15 09:38 PM, git at git.haskell.org wrote: > Repository : ssh://git at git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/abde5da4dee5f3b83264f8471e458b20d04f8b29/ghc > >> --------------------------------------------------------------- > > commit abde5da4dee5f3b83264f8471e458b20d04f8b29 > Author: Thomas Miedema > Date: Fri Mar 27 21:37:49 2015 +0100 > > Rename driver phases C(obj)cpp to C(obj)cplusplus > > Before: > Cpp = Pre-process C > Ccpp = Compile C++ > Cobjcpp = Compile Objective-C++ > CmmCpp = Pre-process Cmm > > Quite confusing! This commit renames `Ccpp` to `Ccplusplus`, and > `Cobjcpp` to `Cobjcplusplus`. The two letters `p-p` keep standing for > `pre-processing` throughout the compiler. > > Reviewed By: austin > > Differential Revision: https://phabricator.haskell.org/D756 > > >> --------------------------------------------------------------- > > abde5da4dee5f3b83264f8471e458b20d04f8b29 > compiler/main/DriverPhases.hs | 32 ++++++++++++++++---------------- > compiler/main/DriverPipeline.hs | 9 +++++---- > ghc/Main.hs | 2 +- > 3 files changed, 22 insertions(+), 21 deletions(-) > > diff --git a/compiler/main/DriverPhases.hs b/compiler/main/DriverPhases.hs > index 2433f6d..2d7d904 100644 > --- a/compiler/main/DriverPhases.hs > +++ b/compiler/main/DriverPhases.hs > @@ -111,10 +111,10 @@ data Phase > | Cpp HscSource > | HsPp HscSource > | Hsc HscSource > - | Ccpp > - | Cc > - | Cobjc > - | Cobjcpp > + | Ccplusplus -- Compile C++ > + | Cc -- Compile C > + | Cobjc -- Compile Objective-C > + | Cobjcplusplus -- Compile Objective-C++ > | HCc -- Haskellised C (as opposed to vanilla C) compilation > | Splitter -- Assembly file splitter (part of '-split-objs') > | SplitAs -- Assembler for split assembly files (part of '-split-objs') > @@ -148,10 +148,8 @@ eqPhase (Unlit _) (Unlit _) = True > eqPhase (Cpp _) (Cpp _) = True > eqPhase (HsPp _) (HsPp _) = True > eqPhase (Hsc _) (Hsc _) = True > -eqPhase Ccpp Ccpp = True > eqPhase Cc Cc = True > eqPhase Cobjc Cobjc = True > -eqPhase Cobjcpp Cobjcpp = True > eqPhase HCc HCc = True > eqPhase Splitter Splitter = True > eqPhase SplitAs SplitAs = True > @@ -163,7 +161,9 @@ eqPhase CmmCpp CmmCpp = True > eqPhase Cmm Cmm = True > eqPhase MergeStub MergeStub = True > eqPhase StopLn StopLn = True > -eqPhase _ _ = False > +eqPhase Ccplusplus Ccplusplus = True > +eqPhase Cobjcplusplus Cobjcplusplus = True > +eqPhase _ _ = False > > -- Partial ordering on phases: we want to know which phases will occur before > -- which others. This is used for sanity checking, to ensure that the > @@ -189,10 +189,10 @@ nextPhase dflags p > LlvmMangle -> As False > SplitAs -> MergeStub > As _ -> MergeStub > - Ccpp -> As False > + Ccplusplus -> As False > Cc -> As False > Cobjc -> As False > - Cobjcpp -> As False > + Cobjcplusplus -> As False > CmmCpp -> Cmm > Cmm -> maybeHCc > HCc -> As False > @@ -215,13 +215,13 @@ startPhase "hscpp" = HsPp HsSrcFile > startPhase "hspp" = Hsc HsSrcFile > startPhase "hc" = HCc > startPhase "c" = Cc > -startPhase "cpp" = Ccpp > +startPhase "cpp" = Ccplusplus > startPhase "C" = Cc > startPhase "m" = Cobjc > -startPhase "M" = Cobjcpp > -startPhase "mm" = Cobjcpp > -startPhase "cc" = Ccpp > -startPhase "cxx" = Ccpp > +startPhase "M" = Cobjcplusplus > +startPhase "mm" = Cobjcplusplus > +startPhase "cc" = Ccplusplus > +startPhase "cxx" = Ccplusplus > startPhase "split_s" = Splitter > startPhase "s" = As False > startPhase "S" = As True > @@ -247,9 +247,9 @@ phaseInputExt (Hsc _) = "hspp" -- intermediate only > -- because runPipeline uses the StopBefore phase to pick the > -- output filename. That could be fixed, but watch out. > phaseInputExt HCc = "hc" > -phaseInputExt Ccpp = "cpp" > +phaseInputExt Ccplusplus = "cpp" > phaseInputExt Cobjc = "m" > -phaseInputExt Cobjcpp = "mm" > +phaseInputExt Cobjcplusplus = "mm" > phaseInputExt Cc = "c" > phaseInputExt Splitter = "split_s" > phaseInputExt (As True) = "S" > diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs > index 24df3a2..845cc95 100644 > --- a/compiler/main/DriverPipeline.hs > +++ b/compiler/main/DriverPipeline.hs > @@ -1068,7 +1068,7 @@ runPhase (RealPhase Cmm) input_fn dflags > -- way too many hacks, and I can't say I've ever used it anyway. > > runPhase (RealPhase cc_phase) input_fn dflags > - | any (cc_phase `eqPhase`) [Cc, Ccpp, HCc, Cobjc, Cobjcpp] > + | any (cc_phase `eqPhase`) [Cc, Ccplusplus, HCc, Cobjc, Cobjcplusplus] > = do > let platform = targetPlatform dflags > hcc = cc_phase `eqPhase` HCc > @@ -1137,9 +1137,9 @@ runPhase (RealPhase cc_phase) input_fn dflags > > ghcVersionH<- liftIO $ getGhcVersionPathName dflags > > - let gcc_lang_opt | cc_phase `eqPhase` Ccpp = "c++" > + let gcc_lang_opt | cc_phase `eqPhase` Ccplusplus = "c++" > | cc_phase `eqPhase` Cobjc = "objective-c" > - | cc_phase `eqPhase` Cobjcpp = "objective-c++" > + | cc_phase `eqPhase` Cobjcplusplus = "objective-c++" > | otherwise = "c" > liftIO $ SysTools.runCc dflags ( > -- force the C compiler to interpret this file as C when > @@ -1176,7 +1176,8 @@ runPhase (RealPhase cc_phase) input_fn dflags > else []) > > -- GCC 4.6+ doesn't like -Wimplicit when compiling C++. > - ++ (if (cc_phase /= Ccpp&& cc_phase /= Cobjcpp) > + ++ (if (cc_phase /= Ccplusplus&& > + cc_phase /= Cobjcplusplus) > then ["-Wimplicit"] > else []) > > diff --git a/ghc/Main.hs b/ghc/Main.hs > index da95ebf..a95382f 100644 > --- a/ghc/Main.hs > +++ b/ghc/Main.hs > @@ -653,7 +653,7 @@ doMake srcs = do > haskellish (f,Nothing) = > looksLikeModuleName f || isHaskellUserSrcFilename f || '.' `notElem` f > haskellish (_,Just phase) = > - phase `notElem` [ As True, As False, Cc, Cobjc, Cobjcpp, CmmCpp, Cmm > + phase `notElem` [ As True, As False, Cc, Cobjc, Cobjcplusplus, CmmCpp, Cmm > , StopLn] > > hsc_env<- GHC.getSession > > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits > From mark.lentczner at gmail.com Sat Mar 28 02:46:43 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Fri, 27 Mar 2015 19:46:43 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On Fri, Mar 27, 2015 at 11:50 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Relatedly, theres a major version bump release of primitive that's due to > be cut soon, and in a month or two vector 0.11 will be ready for release > one way or another. > > Is "soon" measured in hours? If not - I suggest that it misses. I'm pushing that we change how we do this Platform thing - and make it stick, like glue, to the GHC release schedule. Sure, this time 'round we'll be out of sync with those "it's almost there" packages... but next time we'll know it's coming and hopefully, we'll have these panic attacks as GHC is in beta not post-Release. - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sat Mar 28 02:58:55 2015 From: gershomb at gmail.com (Gershom B) Date: Fri, 27 Mar 2015 22:58:55 -0400 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On March 27, 2015 at 10:47:12 PM, Mark Lentczner (mark.lentczner at gmail.com) wrote: > Is "soon" measured in hours? If not - I suggest that it misses. > > I'm pushing that we change how we do this Platform thing - and make it > stick, like glue, to the GHC release schedule. Sure, this time 'round we'll > be out of sync with those "it's almost there" packages... but next time > we'll know it's coming and hopefully, we'll have these panic attacks as GHC > is in beta not post-Release. +1 to this sentiment. Now that we can do efficient platform builds, better to release regularly and efficiently. Otherwise we?ll always be playing catch-up to ?one more thing.? -g From dan.doel at gmail.com Sat Mar 28 03:02:42 2015 From: dan.doel at gmail.com (Dan Doel) Date: Fri, 27 Mar 2015 23:02:42 -0400 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Soon is now. I just published primitive-0.6 and vector-0.10.12.3 that increments the version dependency for it. So they can go in if people want. -- Dan On Fri, Mar 27, 2015 at 10:46 PM, Mark Lentczner wrote: > > On Fri, Mar 27, 2015 at 11:50 AM, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> Relatedly, theres a major version bump release of primitive that's due to >> be cut soon, and in a month or two vector 0.11 will be ready for release >> one way or another. >> >> > Is "soon" measured in hours? If not - I suggest that it misses. > > I'm pushing that we change how we do this Platform thing - and make it > stick, like glue, to the GHC release schedule. Sure, this time 'round we'll > be out of sync with those "it's almost there" packages... but next time > we'll know it's coming and hopefully, we'll have these panic attacks as GHC > is in beta not post-Release. > > - Mark > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Sat Mar 28 11:59:42 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Sat, 28 Mar 2015 11:59:42 +0000 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: <5DBD6BF3-0069-48C3-AEEA-018EE7C72085@me.com> With the advent of efficient build tools, would it be too outrageous to suggest we start to move to automated HP releases on an even faster (but rigid) schedule, e.g. weekly, or monthly? As new versions of libraries come out, they could be incorporated in the platform as soon as they are verified to build successfully with the other dependencies, and the next weekly/monthly bundle would have it. Then there would always be a "recent" Platform good enough for even the bleeding-edge types of users. It would eliminate the rush of "please can we hold off until foo is released in a few days time" requests, which has tended to cause schedule-drift in the past. Continuous integration FTW! Regards, Malcolm On 28 Mar 2015, at 02:58, Gershom B wrote: > On March 27, 2015 at 10:47:12 PM, Mark Lentczner (mark.lentczner at gmail.com) wrote: >> Is "soon" measured in hours? If not - I suggest that it misses. >> >> I'm pushing that we change how we do this Platform thing - and make it >> stick, like glue, to the GHC release schedule. Sure, this time 'round we'll >> be out of sync with those "it's almost there" packages... but next time >> we'll know it's coming and hopefully, we'll have these panic attacks as GHC >> is in beta not post-Release. > > +1 to this sentiment. Now that we can do efficient platform builds, better to release regularly and efficiently. Otherwise we?ll always be playing catch-up to ?one more thing.? > > -g > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From fuuzetsu at fuuzetsu.co.uk Sat Mar 28 15:12:34 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Sat, 28 Mar 2015 15:12:34 +0000 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: <5516C4E2.3080303@fuuzetsu.co.uk> On 03/27/2015 05:16 PM, Randy Polen wrote: > I am helping Mark with the Haskell Platform, doing the Windows builds (32- and > 64-bit). I want you to be aware of a problem I am encountering, and solicit > suggestions and possible help. > > In building for HP 2015.2.0.0 on Windows 7, 64-bit (haven't gotten to 32-bit > yet but likely the same problem will occur), I seem to be hitting the 32K limit > for the length of arguments to a process, encountered while cabal is invoking > haddock to build the docs for the OpenGLRaw package. For HP2014.2.0.0, the > argument list was ~25K (from looking at my old build logs) but now is ~36K, > which exceeds the maximum for CreateProcess (not a limit of the command-line, > but of the OS call itself). > > Is there a way to build haddock docs for a single package but in multiple > haddock invocations (maybe building a .haddock file for portions, then > combining them, with the goal that the command line is kept short)? Seems this > would also require a corresponding cabal change, as cabal is the invocator when > this happens. > > > Barring any existing mechanism, the typical solution to this problem on the > Windows OS is (when possible, of course) to modify the program to accept a > "response file" of command-line arguments. In this case, we could add an > option to haddock to accept either a complete "response file" (i.e., allowing > *all* options and arguments to come from a file) or just a file containing the > files to process. Either of these changes to haddock are rather trivial to > write (but adding another option implies more testing, documentation, other > cases to handle, etc.). Since haddock ships with the ghc release, that's > another wrinkle for this particular release. The other implication of such a > solution is that cabal would need a change to utilize this change for it to be > effective, checking haddock's version for support of this new haddock-flag, and > either use it if the haddock version supports it, or do it optionally (which > implies a new flag for cabal's haddock sub-command). This change to cabal is > also rather trivial to implement (this is not to imply insensitivity to the > incurred cost of each line of code, nor to the added burden of user-visible > changes such as a command-line option). > > > (Less desirable possibilities, mentioned only for completeness: skip the > documentation for OpenGLRaw for this version of the Haskell Platform; split up > the OpenGLRaw package itself in some way.) > > > Other possible solutions and work-arounds? Thoughts on either using haddock in > a different way (and the cabal change that would be required to break up the > doc build into multiple steps for a single package)? Thoughts on the "response > file" solution? > Hi Randy, We actually have an issue about response files already[1], I just haven't gotten around to doing it. When I looked into it last, cabal folks were willing to support it too so there should be no problem on that end. All that remains is that we write code for it in Haddock and for cabal and GHC to adapt. I can implement this in Haddock even today and you can cherry-pick a patch onto whatever you're working with. Is that satisfactory? [1]: https://github.com/haskell/haddock/issues/285 -- Mateusz K. From randyhaskell at outlook.com Sat Mar 28 16:27:45 2015 From: randyhaskell at outlook.com (Randy Polen) Date: Sat, 28 Mar 2015 09:27:45 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: <5516C4E2.3080303@fuuzetsu.co.uk> References: , <5516C4E2.3080303@fuuzetsu.co.uk> Message-ID: Mateusz, Haddock issue #285 indeed sounds like a win (or Win-dows). A logistical wrinkle I worry about for the short-term is that the HP uses the GHC release, and haddock is part of that release. I can certainly incorporate a newer haddock, but I want to mention this GHC-related release issue in case others here have a better approach for this part of the plan (e.g., "yes, go ahead and augment GHC 7.10.1 release with a custom haddock" or "no, let's spin up a 7.10.1.1 (?)"). There is also the Cabal piece as well, but that is separate from GHC and thus a bit easier to incorporate into the HP build. Randy ---------------------------------------- > Date: Sat, 28 Mar 2015 15:12:34 +0000 > From: fuuzetsu at fuuzetsu.co.uk > To: ghc-devs at haskell.org > Subject: Re: HP 2015.2.0.0 and GHC 7.10 > > On 03/27/2015 05:16 PM, Randy Polen wrote: >> I am helping Mark with the Haskell Platform, doing the Windows builds (32- and >> 64-bit). I want you to be aware of a problem I am encountering, and solicit >> suggestions and possible help. >> >> In building for HP 2015.2.0.0 on Windows 7, 64-bit (haven't gotten to 32-bit >> yet but likely the same problem will occur), I seem to be hitting the 32K limit >> for the length of arguments to a process, encountered while cabal is invoking >> haddock to build the docs for the OpenGLRaw package. For HP2014.2.0.0, the >> argument list was ~25K (from looking at my old build logs) but now is ~36K, >> which exceeds the maximum for CreateProcess (not a limit of the command-line, >> but of the OS call itself). >> >> Is there a way to build haddock docs for a single package but in multiple >> haddock invocations (maybe building a .haddock file for portions, then >> combining them, with the goal that the command line is kept short)? Seems this >> would also require a corresponding cabal change, as cabal is the invocator when >> this happens. >> >> >> Barring any existing mechanism, the typical solution to this problem on the >> Windows OS is (when possible, of course) to modify the program to accept a >> "response file" of command-line arguments. In this case, we could add an >> option to haddock to accept either a complete "response file" (i.e., allowing >> *all* options and arguments to come from a file) or just a file containing the >> files to process. Either of these changes to haddock are rather trivial to >> write (but adding another option implies more testing, documentation, other >> cases to handle, etc.). Since haddock ships with the ghc release, that's >> another wrinkle for this particular release. The other implication of such a >> solution is that cabal would need a change to utilize this change for it to be >> effective, checking haddock's version for support of this new haddock-flag, and >> either use it if the haddock version supports it, or do it optionally (which >> implies a new flag for cabal's haddock sub-command). This change to cabal is >> also rather trivial to implement (this is not to imply insensitivity to the >> incurred cost of each line of code, nor to the added burden of user-visible >> changes such as a command-line option). >> >> >> (Less desirable possibilities, mentioned only for completeness: skip the >> documentation for OpenGLRaw for this version of the Haskell Platform; split up >> the OpenGLRaw package itself in some way.) >> >> >> Other possible solutions and work-arounds? Thoughts on either using haddock in >> a different way (and the cabal change that would be required to break up the >> doc build into multiple steps for a single package)? Thoughts on the "response >> file" solution? >> > > Hi Randy, > > We actually have an issue about response files already[1], I just > haven't gotten around to doing it. When I looked into it last, cabal > folks were willing to support it too so there should be no problem on > that end. All that remains is that we write code for it in Haddock and > for cabal and GHC to adapt. I can implement this in Haddock even today > and you can cherry-pick a patch onto whatever you're working with. > > Is that satisfactory? > > [1]: https://github.com/haskell/haddock/issues/285 > > > -- > Mateusz K. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sat Mar 28 16:48:26 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 09:48:26 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On Wed, Mar 25, 2015 at 1:02 AM, Sven Panne wrote: > A +1 for including exceptions, but why version 0.6.1, which is quite > old? I would propose including the latest and greatest 0.8.0.2 > version. > Ah - because gci 3001.2.2.0 has a bound on exceptions < 0.7. John Chee: I don't want to ship an old exceptions. Can update cgi or shall we keep cgi out this time 'round? - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sat Mar 28 17:49:20 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 10:49:20 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: On Sat, Mar 28, 2015 at 10:28 AM, John Alfred Nathanael Chee < cheecheeo at gmail.com> wrote: > Mark: I'm bumping the dependency on exceptions now. I'll post back before > noon PDT if I get a release out. > Rockin'! All: I appreciate the crazy weekend scramble! Alas, for me during the week I'm swamped with work (a good thing - it means my project there is going very well!) If this sync'ing with GHC releases path is well received, then next time we'll have a bit more (~1 month) runway! - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sat Mar 28 22:23:02 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 15:23:02 -0700 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 Message-ID: I have built the 7.10.1 bindist for OS X. It is currently sitting on my server at: ghc-7.10.1-x86_64-apple-darwin.tar.bz2 \O/ I have built an Alpha 2 of Haskell Platform 2015.2.0.0 for OS X . It is based on the above bindist. I should have an ubuntu version of the Platform built by tomorrow. \O/ - Mark *sha256 sums:* c6eb8d573538eba27dfb2d9acf52a1beaaa512208261528b91e8d1775d133eee ghc-7.10.1-x86_64-apple-darwin.tar.bz2 0cb351281fcf5ef34c54b455a3643d0ff078299a53b2c39d911dbda4aac2d233 Haskell Platform 2015.2.0.0 alpha 2 64bit.pkg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sat Mar 28 22:37:46 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 15:37:46 -0700 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: Message-ID: Thanks, John! Alpha 2 is now out: - github commit - OS X Build: Haskell Platform 2015.2.0.0 alpha 2 64bit.pkg Notable changes: - Based on GHC 7.10.1 release - updated attoparsec - updated cgi - brand spanking new major release of OpenGL & GLUT (and related packages) - brand new primitive - updated vector - modern exceptions - updated cabal-install - added ObjectName, StateVar, and transformers-compat, needed by the above Whew! I'll be building the ubuntu based generic build tonight (just got a brand new Intel NUC for this!) Keep the cards and letters coming! Test it out! Review the versions! *Look over the issues list on GitHub , and see if there is anything we need to fix before going final sometime in the next few days.* - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob at redivi.com Sat Mar 28 23:03:18 2015 From: bob at redivi.com (Bob Ippolito) Date: Sat, 28 Mar 2015 16:03:18 -0700 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 In-Reply-To: References: Message-ID: I'm having the same issue with that build. On Sat, Mar 28, 2015 at 3:42 PM, Alec wrote: > Thanks Mark! But: > > % shasum -a 256 ghc-7.10.1-x86_64-apple-darwin.tar.bz2 > f7b112577966391988d16cb44061602f26bbe9a341aa6f4f1301d257895f1c65 > ghc-7.10.1-x86_64-apple-darwin.tar.bz2 > > Also, `tar xjf` didn't like it very much. Did your upload get cut off? > The tarball is only 77 Megs. > > -A > > On Sat, Mar 28, 2015 at 6:23 PM Mark Lentczner > wrote: > >> I have built the 7.10.1 bindist for OS X. >> It is currently sitting on my server at: >> ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >> >> \O/ >> >> I have built an Alpha 2 of Haskell Platform 2015.2.0.0 for OS X >> . >> It is based on the above bindist. >> I should have an ubuntu version of the Platform built by tomorrow. >> \O/ >> >> - Mark >> >> *sha256 sums:* >> c6eb8d573538eba27dfb2d9acf52a1beaaa512208261528b91e8d1775d133eee >> ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >> 0cb351281fcf5ef34c54b455a3643d0ff078299a53b2c39d911dbda4aac2d233 Haskell >> Platform 2015.2.0.0 alpha 2 64bit.pkg >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sat Mar 28 23:19:31 2015 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 28 Mar 2015 20:19:31 -0300 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 In-Reply-To: References: Message-ID: install of alpha 2 on my mac went fine installed hlint but ghc-pkg check ... There are problems in package cgi-3001.2.2.1: dependency "mtl-2.2.1-9d6d3937c3a89aa7f29852ba03f9c592" doesn't exist dependency "network-uri-2.6.0.1-8c523f0a13f0f03c68f10e0359bde85e" doesn't exist The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. cgi-3001.2.2.1 Regards George On Sat, Mar 28, 2015 at 7:23 PM, Mark Lentczner wrote: > I have built the 7.10.1 bindist for OS X. > It is currently sitting on my server at: > ghc-7.10.1-x86_64-apple-darwin.tar.bz2 > > \O/ > > I have built an Alpha 2 of Haskell Platform 2015.2.0.0 for OS X > . > It is based on the above bindist. > I should have an ubuntu version of the Platform built by tomorrow. > \O/ > > - Mark > > *sha256 sums:* > c6eb8d573538eba27dfb2d9acf52a1beaaa512208261528b91e8d1775d133eee > ghc-7.10.1-x86_64-apple-darwin.tar.bz2 > 0cb351281fcf5ef34c54b455a3643d0ff078299a53b2c39d911dbda4aac2d233 Haskell > Platform 2015.2.0.0 alpha 2 64bit.pkg > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sat Mar 28 23:29:21 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 28 Mar 2015 19:29:21 -0400 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 In-Reply-To: References: Message-ID: I'll kick off my own build for os x this evening. On Saturday, March 28, 2015, Bob Ippolito wrote: > I'm having the same issue with that build. > > On Sat, Mar 28, 2015 at 3:42 PM, Alec > wrote: > >> Thanks Mark! But: >> >> % shasum -a 256 ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >> f7b112577966391988d16cb44061602f26bbe9a341aa6f4f1301d257895f1c65 >> ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >> >> Also, `tar xjf` didn't like it very much. Did your upload get cut off? >> The tarball is only 77 Megs. >> >> -A >> >> On Sat, Mar 28, 2015 at 6:23 PM Mark Lentczner > > wrote: >> >>> I have built the 7.10.1 bindist for OS X. >>> It is currently sitting on my server at: >>> ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >>> >>> \O/ >>> >>> I have built an Alpha 2 of Haskell Platform 2015.2.0.0 for OS X >>> . >>> It is based on the above bindist. >>> I should have an ubuntu version of the Platform built by tomorrow. >>> \O/ >>> >>> - Mark >>> >>> *sha256 sums:* >>> c6eb8d573538eba27dfb2d9acf52a1beaaa512208261528b91e8d1775d133eee >>> ghc-7.10.1-x86_64-apple-darwin.tar.bz2 >>> 0cb351281fcf5ef34c54b455a3643d0ff078299a53b2c39d911dbda4aac2d233 Haskell >>> Platform 2015.2.0.0 alpha 2 64bit.pkg >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Mar 29 00:19:14 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 17:19:14 -0700 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 In-Reply-To: References: Message-ID: Verfied that the upload of the ghc bindist was cut short. New upload in progress! I've double checked and the build of Platform, and it's upload is fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Sun Mar 29 00:39:14 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sat, 28 Mar 2015 17:39:14 -0700 Subject: GHC 7.10.1 bindist for OS X + Haskell Platform 2015.2.0.0 Alpha 2 In-Reply-To: References: Message-ID: Deep apologies to all. The full, correct, and sha-sum verified upload is now up: ghc-7.10.1-x86_64-apple-darwin.tar.bz2 - Mark On Sat, Mar 28, 2015 at 5:19 PM, Mark Lentczner wrote: > Verfied that the upload of the ghc bindist was cut short. > New upload in progress! > > I've double checked and the build of Platform, and it's upload is fine. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.macek.0 at gmail.com Sun Mar 29 11:56:38 2015 From: david.macek.0 at gmail.com (David Macek) Date: Sun, 29 Mar 2015 13:56:38 +0200 Subject: Automating GHC build for Windows In-Reply-To: References: <1413916715.326367.181663173.2FBCEE30@webmail.messagingengine.com> Message-ID: <5517E876.9070709@gmail.com> I hope you don't mind me posting to an old thread. I'm re-building ghc-7.10.1 a lot these days and there is one recurring permission issue that looks awfully similar to the ones mentioned here. The issue seems to be deterministic -- appears on every build IIRC and cannot be fixed by re-running make. My real-time malware scanner is disabled and I assume it's not caused by indexing services. The problem seems to be due to botched ACLs in/of the /tmp directory. Some of the files/directories inside are undeletable by the user which is running the build and some can't be deleted even with admin rights. To fix this, I have to force take ownership and grant myself permissions on the files/directories. The build can't continue even after emptying the /tmp directory, as the permissions on the directory itself seems to be broken -- so much that Windows Explorer refuses to show the Advanced Security Settings window for it. Deleting the directory and re-creating with correct permissions allows the build to continue. The tail of a failing build log follows. Unfortunately, it doesn't tell much about the operation that failed. I hope I'll be able to find some time to find out what's failing and what's causing the permissions change. "inplace/bin/ghc-cabal" check libraries/ghc-prim "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install "" --with-ghc="/inplace/bin/ghc-stage1" --with-ghc-pkg="/inplace/bin/ghc-pkg" --flag=include-ghc-prim --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --disable-shared --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --with-gcc="/mingw64/bin/gcc" --with-ld="/mingw64/bin/ld" --configure-option=--with-cc="/mingw64/bin/gcc" --with-ar="/mingw64/bin/ar" Configuring ghc-prim-0.4.0.0... ghc-cabal.exe: permission denied libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/package-data.mk' failed make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 (Paths starting with were shortened by me for the purpose of posting here.) -- David Macek -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4234 bytes Desc: S/MIME Cryptographic Signature URL: From mietek at bak.io Sun Mar 29 18:15:25 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Sun, 29 Mar 2015 19:15:25 +0100 Subject: OS X build of GHC 7.10.1 In-Reply-To: References: Message-ID: An OS X build of GHC 7.10.1 is now available, thanks to Mark Lentczner. I?ve mirrored the build in Halcyon public storage: https://halcyon.global.ssl.fastly.net/original/ghc-7.10.1-x86_64-apple-darwin.tar.bz2 A binary build of GHC 7.10.1, repackaged with documentation removed, is also available in Halcyon ? on OS X and Linux. https://halcyon.sh -- Mi?tek https://mietek.io On 2015-03-23, at 14:28, Mi?tek Bak wrote: > An OS X build of GHC 7.10.1-rc3 is now available, courtesy of Mark Lentczner. This is in addition to the GHC 7.8.4 and 7.10.1-rc2 builds Mark has made available on February 2. Thanks, Mark. > > > GHC 7.8.4 for OS X can already be downloaded from haskell.org, even though it?s not mentioned on the GHC 7.8.4 webpage: > https://downloads.haskell.org/~ghc/7.8.4/ghc-7.8.4-x86_64-apple-darwin.tar.xz > > > To avoid running up Mark?s bandwidth bill, I?m omitting the URL to his staging area. I?ve mirrored all three builds in Halcyon public storage: > > 7.8.4: > https://halcyon.global.ssl.fastly.net/original/ghc-7.8.4-x86_64-apple-darwin.tar.xz > > 7.10.1-rc2: > https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150123-x86_64-apple-darwin.tar.bz2 > > 7.10.1-rc3: > https://halcyon.global.ssl.fastly.net/original/ghc-7.10.0.20150316-x86_64-apple-darwin.tar.bz2 > > > Binary builds of GHC, repackaged with documentation removed, are also available in Halcyon ? on OS X 10.10, 10.9, 10.8, and a considerable number of Linux distributions. > > This includes GHC 7.10.1-rc3, 7.10.1-rc2, 7.8.4, 7.8.3, 7.8.2, 7.6.3, 7.6.1, 7.4.2, 7.2.2, and 7.0.4. > > Using Halcyon, installing GHC together with cabal-install is expected to take 20-30 seconds: > https://halcyon.sh/tutorial/#install-ghc-and-cabal > > > -- > Mi?tek > https://mietek.io > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From mark.lentczner at gmail.com Mon Mar 30 00:24:23 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 29 Mar 2015 17:24:23 -0700 Subject: Platform 2015.2.0.0 Alpha 2 for debian based systems Message-ID: I've uploaded a build of *Haskell Platform 2015.2.0.0 Alpha 2* for generic debian linux systems. It includes GHC 7.10.2, using the generic linux bindist. This is a tarball, not a package. Installation instructions: cd / sudo tar xvf ...downloaded-tarfile... sudo /usr/local/haskell/ghc-7.10.1-x86-64/bin/activate-hs Notes: - Built on Ubuntu 14.04LTS - Needs the following packages installed: build-essential libbsd-dev libgmp-dev libtinfo-dev zlib1g-dev - The OpenGL packages need the OpenGL libs, which on a non-GUI system like a server can be gotten by installing: freeglut3-dev libgl1-mesa-dev libglu1-mesa-dev - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.lentczner at gmail.com Mon Mar 30 01:13:08 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Sun, 29 Mar 2015 18:13:08 -0700 Subject: Platform 2015.2.0.0 Alpha 2 for debian based systems In-Reply-To: References: Message-ID: > > I've uploaded a build of *Haskell Platform 2015.2.0.0 Alpha 2* for > generic debian linux systems. > It includes GHC 7.10.2 > Ooops - GHC 7.10.1 - of course! -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.macek.0 at gmail.com Mon Mar 30 01:27:55 2015 From: david.macek.0 at gmail.com (David Macek) Date: Mon, 30 Mar 2015 03:27:55 +0200 Subject: MSYS2 package for GHC 7.10.1 Message-ID: <5518A69B.1080400@gmail.com> Hi everyone. After finally putting some uninterruped effort into it, I managed to create (hopefully) working prototypes of two GHC-related packages for MSYS2, namely ghc[1] and cabal-install[2]. I've prepared recipes (PKGBUILDs) for building from source, but 64-bit binaries[5][6] are also provided for those who'd like to test my build without building it themselves. With this post, I'd like to start some work towards the following goals (I hope we can get some Windows discussion going again): - verify that the build is reproducible (see below for instructions) - make tests pass - fix known issues (see below for list) - discover and fix unknown issues - review and upstream as many patches as possible - make it easier for people on Windows to start hacking on GHC I'll be glad to read any responses, notes, results, hints, comments and/or criticisms. Please note that I'm writing this after being submerged in the matter for some time, so don't be surprised to see any glaring omissions or obvious mistakes. Known issues ============ Configure has a problem with docbook - This mean Haddock is not built. It's probably some silliness on the part of MSYS2's docbook. Integer-gmp object file has a reference to __mingw_vsnprintf - Compiling seems to work fine, presumably because the final link command includes -lmingwex, but `runhaskell Setup.lhs` in the text package source tree gave me an undefined reference error, causing inability to load integer-gmp module. I don't know where to start fixing this, as I have not yet reached the depth of understanding of GHC source needed for that. Wildly untested - I didn't try building with LLVM and the testsuite is currently failing to start, giving some weird errors. Trying cross compiling or compiling a cross compiler didn't even cross my mind (har har). Patches ======= A lot of the patches deal with the directory structure -- I tried to mirror the common FHS layout as closely as possible while still retaining the advantages of relocatability. I also removed the bundled toolchain and perl, in favor of packages included with MSYS2. I assume these changes are somewhat controversial for upstreaming, but it'd be nice to see the official bindists to adopt this layout. There are several patches that I think are more of straight-forward fixes rather than design changes, namely numbers 0007, 0010, 0014 and 0015. Build instructions ================== General build instructions[3] are available at our wiki. For convenience, I've compiled a sequence of commands that should get you the ghc and cabal-install packages, given that you start with an up-to-date installation of MSYS2 and a working GHC in PATH. Refer to our guide[4] for correct way of getting/upgrading your MSYS2. ## start MSYS2 shell pacman --needed -S base-devel mingw-w64-x86_64-toolchain mingw-w64-i686-toolchain git clone https://github.com/elieux/mingw-packages cd mingw-packages git checkout ghc pushd mingw-w64-ghc makepkg-mingw -sLf pacman -U mingw-w64-*-ghc-*-any.pkg.tar.xz ## remove old GHC from PATH popd pushd mingw-w64-cabal-install makepkg-mingw -sLf pacman -U mingw-w64-*-cabal-install-*-any.pkg.tar.xz popd If you prefer to build only for one architecture, export a variable named MINGW_INSTALLS with a value of "mingw32" or "mingw64" before building. == [1] https://github.com/elieux/mingw-packages/tree/ghc/mingw-w64-ghc [2] https://github.com/elieux/mingw-packages/tree/ghc/mingw-w64-cabal-install [3] http://sourceforge.net/p/msys2/wiki/Contributing%20to%20MSYS2/ [4] http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ [5] https://dl.dropboxusercontent.com/u/59899181/mingw-w64-x86_64-cabal-install-1.22.2.0-1-any.pkg.tar.xz [6] https://dl.dropboxusercontent.com/u/59899181/mingw-w64-x86_64-ghc-7.10.1-1-any.pkg.tar.xz -- David Macek -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4234 bytes Desc: S/MIME Cryptographic Signature URL: From fuuzetsu at fuuzetsu.co.uk Mon Mar 30 02:23:26 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 30 Mar 2015 03:23:26 +0100 Subject: HP 2015.2.0.0 and GHC 7.10 In-Reply-To: References: , <5516C4E2.3080303@fuuzetsu.co.uk> Message-ID: <5518B39E.3080108@fuuzetsu.co.uk> On 03/28/2015 04:27 PM, Randy Polen wrote: > Mateusz, > > > Haddock issue #285 indeed sounds like a win (or Win-dows). > > > A logistical wrinkle I worry about for the short-term is that > > the HP uses the GHC release, and haddock is part of that release. I can certainly > > incorporate a newer haddock, but I want to mention this GHC-related release > > issue in case others here have a better approach for this part of the plan (e.g., > > "yes, go ahead and augment GHC 7.10.1 release with a custom haddock" or > > "no, let's spin up a 7.10.1.1 (?)"). > > > There is also the Cabal piece as well, but that is separate from GHC and thus > > a bit easier to incorporate into the HP build. > > > Randy > We cut a Haddock release when GHC comes out so that it's easy to track versions but that's simply to try to keep some sanity when users report --version. But there is nothing stopping us from releasing a new Haddock version without forcing a GHC release. If I release 2.16.1 tomorrow with the argument list thing, you can just cabal install install it. As long as your system knows to look into binaries built through cabal first and binaries shipped with GHC second, you'll be golden. For HP purposes, you probably want to ship 2.16.1 (or whatever version) when that comes out because tools like cabal-install depend on the version number to determine what features (such as response files) are available. I don't have a date for next point release. Do you have a date for HP? -- Mateusz K. From kazu at iij.ad.jp Mon Mar 30 04:04:11 2015 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon, 30 Mar 2015 13:04:11 +0900 (JST) Subject: traverse_ Message-ID: <20150330.130411.864301235614584798.kazu@iij.ad.jp> Hi, I have just installed GHC 7.10.1. I'm a little bit surprised because 'traverse_' is not exported from Prelude. But 'traverse' is exported. Is this intentional? I expected that I can forget xxxM, xxxM_, xxxA, and xxxA_ functions with GHC 7.10.1. I want to use 'traverse_' instead of 'mapM_'. --Kazu From hvr at gnu.org Mon Mar 30 07:54:36 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 30 Mar 2015 09:54:36 +0200 Subject: traverse_ In-Reply-To: (Fumiaki Kinoshita's message of "Mon, 30 Mar 2015 14:05:56 +0900") References: Message-ID: <87y4mehqdf.fsf@gnu.org> On 2015-03-30 at 07:05:56 +0200, Fumiaki Kinoshita wrote: [...] > I found out that (<>) (in Data.Monoid) is missing, also. It would be nice > to reexamine Prelude to export things we want to export. Fwiw, (<>) was actually left-out as it wasn't required (it's just a an alias for `mappend`), *and* to keep our options open (or at least not make it more difficult) in terms of possible migration-plans available for the case we'd be moving 'Semigroup' to base/Prelude at some point in the future. From kazu at iij.ad.jp Mon Mar 30 13:21:55 2015 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon, 30 Mar 2015 22:21:55 +0900 (JST) Subject: DynFlags.hs Message-ID: <20150330.222155.554427425406328754.kazu@iij.ad.jp> Hi, I cannot build GHC 7.10.1 on CentOS 6.5 whose memory is just 1G. This is because compiler/main/DynFlags.hs is huge. It would be nice if this file could be split. --Kazu From mail at joachim-breitner.de Mon Mar 30 13:30:51 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 30 Mar 2015 15:30:51 +0200 Subject: DynFlags.hs In-Reply-To: <20150330.222155.554427425406328754.kazu@iij.ad.jp> References: <20150330.222155.554427425406328754.kazu@iij.ad.jp> Message-ID: <1427722251.1537.16.camel@joachim-breitner.de> Hi, Am Montag, den 30.03.2015, 22:21 +0900 schrieb Kazu Yamamoto: > I cannot build GHC 7.10.1 on CentOS 6.5 whose memory is just 1G. This > is because compiler/main/DynFlags.hs is huge. It would be nice if > this file could be split. this has been reported as https://ghc.haskell.org/trac/ghc/ticket/7258 It would be great to be able to make the compiler cope with the file gracefully, instead of working around the issue. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From fumiexcel at gmail.com Tue Mar 31 03:33:30 2015 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Tue, 31 Mar 2015 12:33:30 +0900 Subject: traverse_ In-Reply-To: <87y4mehqdf.fsf@gnu.org> References: <87y4mehqdf.fsf@gnu.org> Message-ID: Well, I see. It'd be nice. That aside, the absence of traverse_ doesn't seem to be intended (even the documentation for mapM_ says "mapM_ is just traverse_"!) 2015-03-30 16:54 GMT+09:00 Herbert Valerio Riedel : > On 2015-03-30 at 07:05:56 +0200, Fumiaki Kinoshita wrote: > > [...] > > > I found out that (<>) (in Data.Monoid) is missing, also. It would be nice > > to reexamine Prelude to export things we want to export. > > Fwiw, (<>) was actually left-out as it wasn't required (it's just a an > alias for `mappend`), *and* to keep our options open (or at least not > make it more difficult) in terms of possible migration-plans available > for the case we'd be moving 'Semigroup' to base/Prelude at some point in > the future. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Tue Mar 31 09:38:52 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 31 Mar 2015 11:38:52 +0200 Subject: traverse_ In-Reply-To: (Chris Wong's message of "Tue, 31 Mar 2015 17:27:32 +1300") References: <87y4mehqdf.fsf@gnu.org> Message-ID: <871tk5v74j.fsf@gnu.org> On 2015-03-31 at 06:27:32 +0200, Chris Wong wrote: [...] > While it would be useful to have it in the Prelude, traverse_ doesn't > fit either of the motivations above. So I think its omission is > intended here. That is not to say that it can't be proposed for inclusion... IOW, just turn the cautious "'traverse_' is not exported from Prelude [..] Is this intentional?"-question into an explicit/proper library proposal! Cheers, hvr From ekmett at gmail.com Tue Mar 31 10:41:27 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 31 Mar 2015 06:41:27 -0400 Subject: traverse_ In-Reply-To: References: <87y4mehqdf.fsf@gnu.org> Message-ID: We deliberately took no more symbols than we needed in 7.10 from Prelude as part of the Foldable/Traversable Proposal. There are multiple combinators in Data.Foldable and Data.Traversable that we do not export. traverse_ is one of them as, strictly speaking, traverse_ was a symbol we didn't have to take. If we had would anybody have complained any more loudly? Not sure... but it was a deliberate choice to not bring in any symbols into Prelude that weren't already there that weren't part of the definition of a class or needed to define instances that already existed. -Edward On Mon, Mar 30, 2015 at 11:33 PM, Fumiaki Kinoshita wrote: > Well, I see. It'd be nice. > > That aside, the absence of traverse_ doesn't seem to be intended (even the > documentation for mapM_ says "mapM_ is just traverse_"!) > > 2015-03-30 16:54 GMT+09:00 Herbert Valerio Riedel : > >> On 2015-03-30 at 07:05:56 +0200, Fumiaki Kinoshita wrote: >> >> [...] >> >> > I found out that (<>) (in Data.Monoid) is missing, also. It would be >> nice >> > to reexamine Prelude to export things we want to export. >> >> Fwiw, (<>) was actually left-out as it wasn't required (it's just a an >> alias for `mappend`), *and* to keep our options open (or at least not >> make it more difficult) in terms of possible migration-plans available >> for the case we'd be moving 'Semigroup' to base/Prelude at some point in >> the future. >> >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fumiexcel at gmail.com Tue Mar 31 14:11:40 2015 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Tue, 31 Mar 2015 23:11:40 +0900 Subject: traverse_ In-Reply-To: References: <87y4mehqdf.fsf@gnu.org> Message-ID: I understand the ground. It seems reasonable not to add symbols facilely. But in this case, the "too specialized" version is exported while more fundamental one is not. Although folks (including me) use mapM_ mostly today, someday we will like to have traverse_, I guess. 2015-03-31 19:41 GMT+09:00 Edward Kmett : > We deliberately took no more symbols than we needed in 7.10 from Prelude > as part of the Foldable/Traversable Proposal. There are multiple > combinators in Data.Foldable and Data.Traversable that we do not export. > traverse_ is one of them as, strictly speaking, traverse_ was a symbol we > didn't have to take. > > If we had would anybody have complained any more loudly? Not sure... but > it was a deliberate choice to not bring in any symbols into Prelude that > weren't already there that weren't part of the definition of a class or > needed to define instances that already existed. > > -Edward > > On Mon, Mar 30, 2015 at 11:33 PM, Fumiaki Kinoshita > wrote: > >> Well, I see. It'd be nice. >> >> That aside, the absence of traverse_ doesn't seem to be intended (even >> the documentation for mapM_ says "mapM_ is just traverse_"!) >> >> 2015-03-30 16:54 GMT+09:00 Herbert Valerio Riedel : >> >>> On 2015-03-30 at 07:05:56 +0200, Fumiaki Kinoshita wrote: >>> >>> [...] >>> >>> > I found out that (<>) (in Data.Monoid) is missing, also. It would be >>> nice >>> > to reexamine Prelude to export things we want to export. >>> >>> Fwiw, (<>) was actually left-out as it wasn't required (it's just a an >>> alias for `mappend`), *and* to keep our options open (or at least not >>> make it more difficult) in terms of possible migration-plans available >>> for the case we'd be moving 'Semigroup' to base/Prelude at some point in >>> the future. >>> >>> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Mar 31 15:27:34 2015 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 31 Mar 2015 11:27:34 -0400 Subject: traverse_ In-Reply-To: References: <87y4mehqdf.fsf@gnu.org> Message-ID: I have no objection to having the discussion about widening the set of symbols to shave off warts like this in 7.12. -Edward On Tue, Mar 31, 2015 at 10:11 AM, Fumiaki Kinoshita wrote: > I understand the ground. It seems reasonable not to add symbols facilely. > > But in this case, the "too specialized" version is exported while more > fundamental one is not. > Although folks (including me) use mapM_ mostly today, someday we will like > to have traverse_, I guess. > > 2015-03-31 19:41 GMT+09:00 Edward Kmett : > >> We deliberately took no more symbols than we needed in 7.10 from Prelude >> as part of the Foldable/Traversable Proposal. There are multiple >> combinators in Data.Foldable and Data.Traversable that we do not export. >> traverse_ is one of them as, strictly speaking, traverse_ was a symbol we >> didn't have to take. >> >> If we had would anybody have complained any more loudly? Not sure... but >> it was a deliberate choice to not bring in any symbols into Prelude that >> weren't already there that weren't part of the definition of a class or >> needed to define instances that already existed. >> >> -Edward >> >> On Mon, Mar 30, 2015 at 11:33 PM, Fumiaki Kinoshita >> wrote: >> >>> Well, I see. It'd be nice. >>> >>> That aside, the absence of traverse_ doesn't seem to be intended (even >>> the documentation for mapM_ says "mapM_ is just traverse_"!) >>> >>> 2015-03-30 16:54 GMT+09:00 Herbert Valerio Riedel : >>> >>>> On 2015-03-30 at 07:05:56 +0200, Fumiaki Kinoshita wrote: >>>> >>>> [...] >>>> >>>> > I found out that (<>) (in Data.Monoid) is missing, also. It would be >>>> nice >>>> > to reexamine Prelude to export things we want to export. >>>> >>>> Fwiw, (<>) was actually left-out as it wasn't required (it's just a an >>>> alias for `mappend`), *and* to keep our options open (or at least not >>>> make it more difficult) in terms of possible migration-plans available >>>> for the case we'd be moving 'Semigroup' to base/Prelude at some point in >>>> the future. >>>> >>>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randyhaskell at outlook.com Tue Mar 31 18:20:49 2015 From: randyhaskell at outlook.com (Randy Polen) Date: Tue, 31 Mar 2015 11:20:49 -0700 Subject: GHC 7.10.1 html docs all flat? Message-ID: The HP build expects that the html docs for the ghc-bundled packages will be in heirarchical directories, based on the package name (e.g., GHC.Magic docs in libraries/ghc-prim-0.3.1.0/GHC-Magic.html) which is how it has been for many ghc releases. In 7.10.1, I thought it was an error but it seems the haskell.org docs reflect this new, flat way (e.g,. GHC.Magic docs in libraries/GHC-Magic.html). Just want to make sure this is what is expected, and then change the HP build code accordingly. Follow up question: should the HP-bundled docs do the same thing? Is the flat model the way to go for all the docs? Won't this cause collisions for updated packages? Randy