October 2014 - ghc-devs

Fwd: ASCIIDoc Grammar
by Carter Schonwald 19 Oct '14

19 Oct '14

Levi, thanks for sharing this! @herbert and austin, how much should we care about the doc format being easy to reparse? ---------- Forwarded message ---------- From: Levi Pearson <levipearson(a)gmail.com> Date: Sat, Oct 18, 2014 at 6:50 PM Subject: ASCIIDoc Grammar To: carter.schonwald(a)gmail.com I saw your question in the ghc-devs archive about asciidoc, and I figured I'd reply out-of-band since I don't subscribe to ghc-devs. Feel free to forward it there if you think it'd be useful. I have looked pretty deeply into the implementation of the canonical asciidoc as well as asciidoctor, which is a re-implementation in Ruby and which serves as the translator for github. There's no formal grammar, and it would be difficult to construct one, as it's not actually a fixed format. The asciidoc engine is actually a macro-processing engine that's designed to translate both in-line patterns and block-style patterns based on delimiters and attributes. It's driven to a large extent by a set of configuration files that define a lot of macros in a fairly general way, with just a couple of special-purpose parsing mechanisms. The macros can all be parameterized by "attributes" that can have default values, and this allows you to inject semantic tags or create new inline or block patterns that essentially expand to lower-level inlines/blocks with specific attributes. The back-ends can also use attributes to select how spans and blocks are rendered. It's a very flexible system, and lines up pretty well with the semantics of DocBook and XML in general. Its main advantage over something like Markdown (and it can actually be reconfigured to be very Markdown-like simply by changing regular expressions in the config files) is that it allows you to add semantic markup and higher-level document structure that's specific to your documentation project without having to touch the main engine code. That's an especially good thing as it's a bit messy and hard-to-follow.

1 0

panic when building ghc head
by Carter Schonwald 19 Oct '14

19 Oct '14

hey all, when doing a devel1 build i got the following panic "inplace/bin/genapply" >rts/dist/build/AutoApply.cmm"inplace/bin/ghc-stage1" -static -H64m -O -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/dist/build/AutoApply.cmm -o rts/dist/build/AutoApply.o"inplace/bin/ghc-stage1" -fPIC -dynamic -H64m -O -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/dist/build/AutoApply.cmm -o rts/dist/build/AutoApply.dyn_o"inplace/bin/ghc-stage1" -static -eventlog -H64m -O -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/dist/build/AutoApply.cmm -o rts/dist/build/AutoApply.l_o"inplace/bin/ghc-stage1" -static -optc-DDEBUG -ticky -DTICKY_TICKY -H64m -O -fasm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -O0 -c rts/dist/build/AutoApply.cmm -o rts/dist/build/AutoApply.debug_o*** Core Lint warnings : in result of Desugar (after optimization) ***{-# LINE 101 "libraries/ghc-prim/GHC/Classes.hs #-}: Warning: [RHS of $c/=_a1qs :: GHC.Types.Float -> GHC.Types.Float -> GHC.Types.Bool] INLINE binder is (non-rule) loop breaker: $c/=_a1qs{-# LINE 104 "libraries/ghc-prim/GHC/Classes.hs #-}: Warning: [RHS of $c/=_a1ql :: GHC.Types.Double -> GHC.Types.Double -> GHC.Types.Bool] INLINE binder is (non-rule) loop breaker: $c/=_a1ql{-# LINE 85 "libraries/ghc-prim/GHC/Classes.hs #-}: Warning: [RHS of $c/=_a1qZ :: forall a_a1X. GHC.Classes.Eq a_a1X => [a_a1X] -> [a_a1X] -> GHC.Types.Bool] INLINE binder is (non-rule) loop breaker: $c/=_a1qZ ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20141018 for x86_64-apple-darwin): tyConAppTyCon a_12 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug any ideas of how I could debug this? Or what it might be?

1 1

GHC 7.8.4: call for tickets, show stoppers, and timelines - oh my!
by Austin Seipp 19 Oct '14

19 Oct '14

Hi *, After some discussion with Simon & Mikolaj today, I'd like to direct you all at this: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4 This status page is the basic overview of what we plan on doing for 7.8.4. There are two basic components to this page: - Show stopping bugs. - Everything else, which is "nice to have". Show stoppers are listed at the top of the page, in the first paragraph. Right now, this includes: - #9439 - LLVM mangling too vigorously. - #8819 - Arithmetic failures for unregistered systems - #8690 - SpecConstr blow-up And that's all. But what's all the other stuff? That's "everything else". Aside from these tickets listed here - and any future amendments to it - all other tickets will only be considered nice-to-have. What does that mean? - It's low risk to include. - It clearly fixes the problem - It doesn't take Austin significant amounts of time to merge. For example, "Tickets marked merge with no milestone" are all nice-to-have. Similarly, all the *closed tickets* on this page may be re-opened and merged again[1], since most didn't make it to 7.8.4. Ditto with the remaining categories. OK, so that's the gist. Now I ask of you the following: - If you have a show-stopping bug with GHC 7.8.3, **you really, _positively_ need to file a bug, and get in contact with me ASAP**. Otherwise you'll be waiting for 7.10 most likely. - Again: if you have a show stopper, contact me. Very soon. - If there are bugs you *think* are showstoppers, but we didn't categorize them properly, let me know. Anything we accept as a show-stopper will delay the release of 7.8.4. Anything else can (and possibly will) be left behind. Luckily, almost all of the show stoppers have patches. Only #8819 does not, but I have asked Sergei to look into it for me if he has time today. Finally, I would please ask that users/developers do not include their own personal pet tickets under "show stoppers" without consulting me first, at least. :) If it's just nice to have, you can still pester me, of course, and I'll try to make it happen. I would like to have 7.8.4 out and done with by mid November, before we freeze the new STABLE branch for 7.10.1. That's not a hard deadline; just a timeframe I'd like to hit. Let me know if you have any questions or comments; thanks! [1] A lot of the closed tickets on this page had an improper milestone set, which is why they show up. You can mostly ignore them, I apologize. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Build on Windows fails
by David Macek 18 Oct '14

18 Oct '14

Hi all. My build fails, log: https://gist.github.com/elieux/2b2a074e03005f7754d6 I'm working on Windows x64, using msys2 with mingw64-x86_64 4.9.1. What I did: download the official 7.6.3 x64 build without included toolchain download x64 msys2, install x64 toolchain and set ghc to use it build Cabal, install Alex and Happy set paths to relevant binaries download http://www.haskell.org/ghc/dist/7.8.3/ghc-7.8.3-src.tar.xz extract cp mk/build.mk.sample mk/build.mk ./boot patch configure to remove the in-tree toolchain ./configure with some parameters make I have a PKGBUILD, but since I'm bootstrapping with the manually configured ghc, the environment is not 100% reproducible at the moment. Can you point me at what should I try changing to build successfully? -- David Macek

2 1

Request: Phab Differentials should include road maps
by Richard Eisenberg 18 Oct '14

18 Oct '14

Hi devs, I have what I hope is a simple request: that patch submissions contain a "road map" describing the patch. I'll illustrate via example: I just took a quick look at D323, about updating the design of Uniques. Although this patch was fairly straightforward, I would have been helped by a comment somewhere saying "All the important changes are in Unique.lhs. The rest of the changes are simply propagating the new UniqueDomain type." Then, I would just look at the one file and skim the rest very briefly. The reason I'm requesting this comment from the patch author is that my assumption above -- that all the action is in Unique.lhs -- might be quite wrong. Maybe there's a really important (perhaps one-line) change elsewhere that deserves attention. Or, maybe there's a function/type in Unique.lhs that the patch author is very uncertain about and wants extra scrutiny. In any case, a few sentences at the top of the patch would help focus reviewers' time where the author thinks it is most needed. What do we think? Is this a behavior we wish to adopt? Thanks! Richard

4 4

T3064 failures
by David Feuer 17 Oct '14

17 Oct '14

I don't know what's going on, but T3064 is giving some substantial performance trouble, making all the validations fail: max_bytes_used value is too high: Expected T3064(normal) max_bytes_used: 13251728 +/-20% Lower bound T3064(normal) max_bytes_used: 10601382 Upper bound T3064(normal) max_bytes_used: 15902074 Actual T3064(normal) max_bytes_used: 17472560 Deviation T3064(normal) max_bytes_used: 31.9 % bytes allocated value is too high: Expected T3064(normal) bytes allocated: 385145080 +/-5% Lower bound T3064(normal) bytes allocated: 365887826 Upper bound T3064(normal) bytes allocated: 404402334 Actual T3064(normal) bytes allocated: 1372924224 Deviation T3064(normal) bytes allocated: 256.5 % I don't know what's allocating an extra gigabyte, but unless there's a good reason, someone probably needs to tighten something up.

3 2

Merging a branch
by Simon Peyton Jones 17 Oct '14

17 Oct '14

Friends I have a branch, wip/new-flatten-skolems-Aug14, which has a long succession of work-in progress patches. Plus a couple of merges from HEAD. I'd like to completely re-organise the patches before committing to HEAD. How do I do that? Some kind of rebase? Clearly I want to start from current HEAD, rather than having weird merge patches involved. I was thinking of starting a new branch and doing a manual diff/patch, but that seems crude. I think that one other person (Iavor) has pulled from this branch, but he has not modified it. Thanks Simon

6 5

RTS validate failures on Linux
by Jan Stolarek 17 Oct '14

17 Oct '14

Simon, I'm getting this error when validating HEAD on 64 bit Linux: =================== "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Werror -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissi ng-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnest ed-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist -ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fom it-frame-pointer -optc-DRtsWay=\"rts_thr\" -static -optc-DTHREADED_RTS -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iin cludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/posix/OSThreads.c -o rts/dist/build/posix/OSThreads.thr_o cc1: warnings being treated as errors rts/posix/OSThreads.c: In function ‘createOSThread’: rts/posix/OSThreads.c:132:40: error: unused parameter ‘name’ gmake[1]: *** [rts/dist/build/posix/OSThreads.thr_o] Error 1 =================== I believe this might be a result of your commit 674c631ea111233daa929ef63500d75ba0db8858 from Friday. Janek

2 1

RFC: Source-markup language for GHC User's Guide
by Herbert Valerio Riedel 16 Oct '14

16 Oct '14

Hello GHC Developers & GHC User's Guide writers, I assume it is common knowledge to everyone here, that the GHC User's Guide is written in Docbook XML markup. However, it's a bit tedious to write Docbook-XML by hand, and the XML markup is not as lightweight as modern state-of-the-art markup languages designed for being edited in a simple text-editor are. Therefore I'd like to hear your opinion on migrating away from the current Docbook XML markup to some other similarly expressive but yet more lightweight markup documentation system such as Asciidoc[1] or ReST/Sphinx[2]. There's obviously some cost involved upfront for a (semi-automatic) conversion[3]. So one important question is obviously whether the long-term benefits outweight the cost/investment that we'd incur for the initial conversion. All suggestions/comments/worries welcome; please commence brainstorming :) [1]: http://www.methods.co.nz/asciidoc/ [2]: http://sphinx-doc.org/ [3]: There's automatic conversion tools to aid (though manual cleanup is still needed) the initial conversion, such as https://github.com/oreillymedia/docbook2asciidoc As an example, here's the conversion of http://git.haskell.org/ghc.git/blob/HEAD:/docs/users_guide/extending_ghc.xml to Asciidoc: https://phabricator.haskell.org/P24 to give an idea how XML compares to Asciidoc

9 12

I'm going to disable DPH until someone starts maintaining it
by Austin Seipp 16 Oct '14

16 Oct '14

Everyone, I'm still working on the AMP, and of course, things aren't going as planned. Why is that? I'm attempting to update `vector` to the latest version from GitHub, as it has some fixes we need for AMP. Mostly, it has some instances we need. Unfortunately, this is basically impossible because dph is locked into a vector fork of ours that we have been maintaining for *months*, and doesn't work with the latest vector upstream (0.11) due to changes in the stream representation. This means I can either: 1) Fix everything in DPH to work with vector 0.11, which is probably going to take a lot of work. 2) Merely fix our fork of vector and let things continue working. This is much easier than #1. Now, you might say that #2 is clearly a preferable solution, and it's very easy - so just do that, Austin! But I don't want to do it. You could say this is the straw that has broken the camel's back. Why? Because I'm afraid I just don't have any more patience for DPH, I'm tired of fixing it, and it takes up a lot of extra time to build, and time to maintain. In fact I'm the only person who's committed to it in *months*, and that has only been to fix breakage. The hackage packages are out of date and sync with what's in the repository (I can't upload them, nor can anyone else besides Ben I believe). So - why are we still building it, exactly? We had a conversation about this months ago. The concern was that things would break and we don't want it to fall out of sync. We're at that point right now - things are breaking, it's out of sync, and it's a pain to keep fixing it, and the actual *benefits* we get from doing so are completely unclear to me. It basically just seems like extra work for nothing, honestly. Unless someone speaks[1] up *very* soon, I'm going to disable DPH during ./validate and the regular build. It will be possible to build it with a '--dph' flag (the dual of the current '--no-dph' flag), although it will be broken very soon with these incoming changes. Providing someone starts fixing it, I'm completely, 100% open to re-enabling it in ./validate by default. But I'm personally tired of fixing it. I'm CC'ing Manuel, Geoff & Ben for their inputs. [1] And by 'speak up', I mean I'd like to see someone actively step forward address my concerns above in a decisive manner. With patches. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 9