- ghc-devs - Haskell.org

Re: GitHub pull requests
by Merijn Verstraaten 21 Oct '14

21 Oct '14

Whoops, accidentally only addressed Ben instead of the list: On 20 Oct 2014, at 12:13 , Ben Gamari <bgamari.foss(a)gmail.com> wrote: > a) Confusion between Github issue numbers, Trac bug numbers, and > Phabricator identifiers It is possible to disable GitHub issues on a repository, would this not at least solve the issue number confusion? I only figured this out today when trying to *enable* issues on my personal fork of another project. Cheers, Merijn

1 0

Help understanding Specialise.lhs
by David Feuer 20 Oct '14

20 Oct '14

I'm trying to figure out how to address #9701, but I'm having an awfully hard time figuring out what's going on in Specialise.lhs. I think I get the vague general idea of what it's supposed to do, based on the notes, but the actual code is a mystery to me. Is there anyone who might be able to help me get enough of a sense of it to let me do what I need? Many thanks in advance. David Feuer

2 5

GHC Weekly News - 2014/10/20
by Austin Seipp 20 Oct '14

20 Oct '14

Hi *, Here's a weekly news update covering the past several weeks, covering some of our discussions we've had - please let me know if I missed out on something important so I can update the post. https://ghc.haskell.org/trac/ghc/blog/edit/weekly20141020 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 4

Re: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
by Alan & Kim Zimmerman 20 Oct '14

20 Oct '14

For the review process I updated the phabricator summary to capture the current implementation, I will move it on to the wiki too. The ExtraCommas have been removed as unworkable, they are an abandoned point in the design space. The lessons learned are being transferred to Alexander Berntsen for his record syntax extension proposal. I did consider bringing comments in directly, as being a natural part of things, but did not want to confuse the issue too much in one go. It should be possible to capture them in a similar process, and it will definitely help with round tripping. At the moment tooling has to access them via `getRichTokenStream` and then work them in to the correct place. In terms of haddock usage, I would have to discuss with them what they do/need, to find out if this will serve as a replacement. On Mon, Oct 20, 2014 at 9:55 AM, GHC <ghc-devs(a)haskell.org> wrote: > #9628: Add Annotations to the AST to simplify source to source conversions > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: feature | Status: new > request | Milestone: > Priority: normal | Version: 7.9 > Component: Compiler | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: | Related Tickets: > None/Unknown | > Test Case: | > Blocking: | > Differential Revisions: D297 | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > Well done for making progress. Some thoughts > > * If the patch is ready for review, is [wiki:GhcAstAnnotations] also > fully up to date? Could you move any discussion of alternatives to the > end, under "Other possible design alternatives" so that what remains is > actually a description of the feature you propose, and a sketch of its > implementation? I'm unsure about which bits of the wiki page are rejected > ideas and which are the ones you adopted. > > * Floating around is also `ExtraCommas`. I think the two are somewhat > orthogonal, right? > > * Does your design say where comments are? That is, can you really > round-trip source code? > > In particular, an excellent criterion could be: can you do Haddock this > way? Currently Haddock has a lot of Haddock-specific fields in HsSyn. > Could they all be replaced with annotations in your style? If not, what > would take to make that possible? It would be highly cool; after all, > Haddock may be privileged, but the more we can make it possible for others > to do Haddock-like things without changing GHC itself, the better. > > * You outlined a number of "customers" in an earlier post. Would it be > worth adding them to the wiki page? > > Simon > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628#comment:30> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

A simpler remove HEAP_ALLOCED check
by Edward Z. Yang 20 Oct '14

20 Oct '14

Hey Simon, I was chatting with Sergio Benitez about GHC's HEAP_ALLOCED woes and he suggested an alternate fix which I'm not sure we have considered. The idea is simple: pre-assign some portion of the virtual address space for the dynamic heap, and then have HEAP_ALLOCED check if it's inside this space. Now, *obviously* this doesn't work for 32-bit (and I assume this is why we didn't go this route), but that's fine: the bitmap we use for 32-bit works pretty great and isn't a bottleneck. For 64-bit, we have a lot more address space to play with. Certainly we have to make sure the system linker never puts segments inside our pre-assigned space, but this seems far more manageable. I'm not particularly wedded to the indirections patchset, so if we can make this work for 64-bit, it seems good enough to me. Edward

1 0

Fwd: ASCIIDoc Grammar
by Carter Schonwald 18 Oct '14

18 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 18 Oct '14

18 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 18 Oct '14

18 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 17 Oct '14

17 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