- ghc-devs - Haskell.org

Re: Status of Haskell Platform 2014.2.0.0
by Johan Tibell 15 Jul '14

15 Jul '14

This was discussed earlier. We need to stick with the Cabal that ships with the GHC version we're using and thus we need to stick with cabal-install-1.18. On Tue, Jul 15, 2014 at 9:33 AM, Alois Cochard <alois.cochard(a)gmail.com> wrote: > Why not directly to 1.20.x? > On Jul 15, 2014 7:59 AM, "Andres Löh" <andres.loeh(a)googlemail.com> wrote: > >> Hi. >> >> > Check the version list in Release2014.hs >> >> Would it still be possible to bump cabal-install to 1.18.0.5? >> >> Cheers, >> Andres >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries > >

4 8

GhcLibHcOpts: -O or -O2?
by Joachim Breitner 15 Jul '14

15 Jul '14

Hi, I found that some performance tests cases fail in some setting, and not in another, and after a while I found the cause: The default settings (i.e. no mk/build.mk) have GhcLibHcOpts=-O2, while most development profiles (e.g. devel2) _and the validate settings_ have GhcLibHcOpts=-O1. It doesn’t make a lot of sense to have performance tests cases without fixing this parameter. And I think we really should be validating the settings that we actually used in the final build that we release. Hence three questions: 1. Are the default settings really the settings used when producing the final build? 2. Do we want to use GhcLibHcOpts=-O2 or GhcLibHcOpts=-O for releases? 3. Once 2. is answered, may I change the validate settings to that value, and update the performance tests to expect the number produced with that value? (This was first observed in https://ghc.haskell.org/trac/ghc/ticket/9315#comment:5 but I wanted to the wider audience of the mailing list for such a design decision.) Thanks, Joachim -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata(a)joachim-breitner.de

1 0

ANN: New source documentation policy for GHC
by Johan Tibell 15 Jul '14

15 Jul '14

Hi all! After some discussion [1] we've decided to require Haddock comments for all top-level entities (i.e. functions, classes, and data types) in new [2] GHC code. If you're writing new code, please try to add at least a sentence of two documenting what the function does and why. When you're reviewing patches, please ask the author to add comments. This policy doesn't replace GHC's use of [Notes], which talk mostly about implementation details, but instead compliments it by making it clearer how to *use* the code. See the original thread [1] for some example comments. We will use Haddock for our comments, in order to make the generated Haddock docs more useful, but we don't require that you use any special markup in the comments themselves or required that you validate that your docs render nicely [3]. We're not adding any technical enforcement [4], to avoid extending the compile/validate cycle, instead rely on social enforcement; please encourage people to write comments and remind them during code review! Cheers, Johan 1. https://www.mail-archive.com/ghc-devs@haskell.org/msg05135.html 2. Documenting old code is of course also much appreciated! 3. This is a pragmatic trade-off to not add too much extra work for frequent contributions. It's easy for anyone to fix up bad markup, so allowing some bad markup to slip in temporarily isn't a big issue. 4. We might try to add lint warning to Phabricator, to serve as an extra reminder to patch authors.

2 2

Building GHC API Documentation?
by Andrew Gibiansky 15 Jul '14

15 Jul '14

Hello, I am trying to create my first patch, for #9294, where I want to export some extra things from Parser along with a bit of documentation. However, I cannot figure out how to regenerate the documentation for the GHC API (not for the libraries). I tried running `make html stage=0 FAST=YES` in `./compiler`, and got the following helpful message: make[2]: *** No rule to make target `html_compiler'. Stop. make[1]: *** [html_compiler] Error 2 make: *** [html] Error 2 So I'm a bit stumped. How do I regenerate Haddock documentation for the GHC API? Thanks! Andrew

3 5

HEAD build fails on compiling haddoc
by Karel Gardas 15 Jul '14

15 Jul '14

Hello, I'm trying to compile HEAD on amd64-solaris2 platform, but the build fails with: "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/haddock-library/vendor/attoparsec-0.10.4.0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.20.0.1 -package array-0.5.0.0 -package base-4.7.1.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.9.20140715 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/src/Haddock/GhcUtils.hs -o utils/haddock/dist/build/Haddock/GhcUtils.dyn_o utils/haddock/src/Haddock/GhcUtils.hs:105:21: Not in scope: data constructor ‘TyFamInstEqn’ Perhaps you meant ‘TyFamInstD’ (imported from GHC) utils/haddock/src/Haddock/GhcUtils.hs:105:36: ‘tfie_rhs’ is not a (visible) constructor field name gmake[1]: *** [utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Error 1 gmake: *** [all] Error 2 is this just issue on my system or general issue which waits for someone to resolve it? Since I built HEAD successfully just two days ago, this patch may looks suspiciously: commit 9b8ba62991ae22420a0c4486127a3b22ee7f22bd Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Jul 15 07:43:55 2014 +0100 Entirely re-jig the handling of default type-family instances (fixes Trac #9063) In looking at Trac #9063 I decided to re-design the default instances for associated type synonyms. Previously it was all jolly complicated, to support generality that no one wanted, and was arguably undesirable. Specifically * The default instance for an associated type can have only type variables on the LHS. (Not type patterns.) * There can be at most one default instances declaration for each associated type. To achieve this I had to do a surprisingly large amount of refactoring of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type of the LHS patterns. That change in HsDecls has a (trivial) knock-on effect in Haddock, so this commit does a submodule update too. The net result is good though. The code is simpler; the language specification is simpler. Happy days. Trac #9263 and #9264 are thereby fixed as well. but I'm not expert so no offense! And if this is a mistake on my side, then I'm really sorry for false alarm. Thanks! Karel

2 2

Core-to-core transformations: current state-of-the-art?
by Jan Stolarek 15 Jul '14

15 Jul '14

Hi devs, I'm curious about the current state of core-to-core transformations inside GHC. I know about following papers that cover this subject: 1. "Compilation by Transformation in Non-Strict Functional Languages", a PhD dissertation by Santos (I assume this summarizes earlier papers by Santos and SPJ). 2. "A transformation-based optimiser for Haskell", paper by SPJ and Santos. 3. "Let-floating: moving bindings to give faster programs", paper by SPJ, Partain and Santos. 4. "Modular, Higher-Order Cardinality Analysis in Theory and Practice", paper by Sergey, Vytiniotis and SPJ. Is there any other work that I should be aware of? Are there transformations implemented in GHC that were not described in any paper? Janek PS. I'm aware of the wiki pages that list the GHC papers.

2 1

Phab vs. Trac
by Richard Eisenberg 15 Jul '14

15 Jul '14

Hi all, Sometimes, the progress on a particular issue is tracked both on Trac and on Phab. What posts should go where? I know Austin is trying to get Trac to be notified when a relevant post happens on Phab -- great. But, if I have a comment, where should I put it? Here is my proposed answer: The Phab reviews are a good place for code-specific commentary/feedback but Trac is better for design issues. A rule of thumb might be to pretend that Phab comments are all forgotten in a month or two, whereas Trac comments are expected to be around in 5 years. Another feature request around Phab/Trac: Is it possible to have a field *at the top of a Trac ticket* that links to the Differential page? Thanks! Richard

3 6

RE: how to get ghci to load compiled modules in 7.8?
by Simon Peyton Jones 14 Jul '14

14 Jul '14

| One thing, how about an addition to the release notes in the | -dynamic-too section saying "By the way, this doesn't actually work, | see https://ghc.haskell.org/trac/ghc/ticket/8736." Not a bad idea. Austin can we conveniently do that retrospectively?

1 0

T9203
by Simon Peyton Jones 14 Jul '14

14 Jul '14

Joachim In commit 194107ea9333c1d9d61abf307db2da6a699847af you reduced the allocation of T9203 by half. Butbut I get allocation of 95747304 on my 64 bit machine, so the test fails. Any idea why? Simon diff --git a/testsuite/tests/perf/should_run/all.T b/testsuite/tests/perf/should_run/all.T index 4fa77a5..e9e7ef3 100644 --- a/testsuite/tests/perf/should_run/all.T +++ b/testsuite/tests/perf/should_run/all.T @@ -371,7 +371,9 @@ test('InlineCloneArrayAlloc', test('T9203', [stats_num_field('bytes allocated', [ (wordsize(32), 50000000, 5) - , (wordsize(64), 95747304, 5) ]), + , (wordsize(64), 42946176, 5) ]), + # previously: 95747304 + # 2014-07-14: 42946176 (amd64/Linux)

2 1

Status updates
by Austin Seipp 14 Jul '14

14 Jul '14

Hello all, I've been lax on the status updates, but better late than never. :) Here are some things that I've been up to. - 7.8.3 is released! Hooray! - Phabricator can now build code reviews if you submit them. I sent an email about this earlier in the week[1] in case you missed it. Unfortunately it has a rather stupid bug that it doesn't catch stderr properly, but I'll fix that soon. :) - I also spent some time on trying to get Phabricator to post to Trac (when a code review for a ticket is posted), but to no avail yet. Hopefully I'll have this done in the next few days. - I spent a few hours yesterday and on Saturday on the AMP work still, because I missed a few things actually (broken deriving mechanism due to forgetting some changes). I also need to send one more patch to Cabal upstream I believe, but otherwise things look OK. I'll post a new code review today when I've finished. - This morning I've combed some tickets and remilestoning stuff, since there was a *lot* left around for 7.6.2 still! This should all be fixed. I'll keep doing this today and this morning probably. - I want to reorganize the wiki pages around the Git repository, and I have been meaning to do this, but not gotten around to it yet. :( Some other things on my mind: - When I released 7.8.3, I noticed we have a whole bunch of new upstream distribution packages now, but the download page for those is pretty out of date I think.[2] That should probably be updated. - There are patches in the Trac queue I need to get done with. If I've ignored your patch I'm sorry! I'll try to get this done quickly. - Johan reminded me about D4 this morning[3] which I still need to merge upstream after addressing the details in the review. [1]: https://www.haskell.org/pipermail/ghc-devs/2014-July/005509.html [2]: https://www.haskell.org/ghc/download_ghc_7_8_3#distros [3]: https://phabricator.haskell.org/D4 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1