Re: DKIM failures for gitlab mail
Hi Ben,
gentle reminder about this issue? I’m worried I (and maybe others) are
going to miss gitlab notifications.
Cheers,
Joachim
Am Donnerstag, dem 01.12.2022 um 10:21 +0200 schrieb Bryan Richter via
ghc-devs:
> Thanks for noticing, Joachim!
>
> Ben Gamari is still the primary contact for GitLab configuration...
> Ben, maybe you know something about this?
>
> On Wed, Nov 30, 2022 at 7:12 PM Viktor Dukhovni
> wrote:
> >
> > On Wed, Nov 30, 2022 at 05:33:44PM +0100, Joachim Breitner wrote:
> >
> > > I noticed that a small number of Gitlab notification emails end up in
> > > my spamfilter. While there is not much you can do about triggering some
> > > bayesian style spam filter at my email provider (mailbox.org), I did
> > > notice this in the headers:
> > >
> > > X-Spam-Status: No, score=2.704 tagged_above=2 required=6
> > > tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HS_RSPAMD_10_11=2.5,
> > > HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001,
> > > URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
> > > Authentication-Results: spamfilter01.heinlein-hosting.de (amavisd-new);
> > > dkim=fail (1024-bit key) reason="fail (bad RSA signature)"
> > > header.d=gitlab.haskell.org
> > > DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
> > > d=gitlab.haskell.org;
> > > s=mail; t=1669733134;
> > > bh=D0NUcHiskEnwSP99umP3zo8Fz8fl74OgAJ8NRDKCsp4=;
> > > h=Date:From:Reply-To:To:In-Reply-To:References:Subject:List-Id:
> > > List-Unsubscribe;
> > >
> > > b=R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvEK
> > >
> > > M7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD02NS
> > > ouI3tvQ9mddNdaEK7retq8N+29hzs/ezf9cpgy+Q=
> >
> > Indeed the signature in "b=" was not made by the key at
> > mail._domainkey.gitlab.haskell.org. Running the below:
> >
> > sig=$(
> > printf "%s\n%s\n%s\n" \
> >
> > R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvE \
> >
> > KM7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD0 \
> > 2NSouI3tvQ9mddNdaEK7retq8N+29hzs/ezf9cpgy+Q=
> > )
> >
> > pkey=$(
> > dig +short -t txt mail._domainkey.gitlab.haskell.org |
> > perl -MMIME::Base64 -ne '
> > /^"v=DKIM1;/ or next;
> > print decode_base64($1) if m{;\s*p=(\S+?)(?:;|$)}
> > ' |
> > openssl pkey -pubin -inform DER
> > )
> >
> > openssl rsautl -raw -encrypt -pubin \
> > -inkey <( printf "%s\n" "$pkey" ) \
> > -in <(printf "%s\n" "$sig" | openssl base64 -d) |
> > xxd -p
> >
> > the output is:
> >
> > 509bfc93a492f1b5328308e51624d9a7ed1378861f577b11413c5034bc0c
> > 673d61660434d4bc30844e7648da0f9605923805973a313a8c3bc82215cc
> > ac447e47551087c544a0592ac3ae48474584bad7d9ca5b850a67493a7977
> > d28aaa3a9a7580d165dc4f31ff484bdbc40e94a2be1750e71c51c555b5c1
> > 6bc051947bb07ae4
> >
> > Which is not a PKCS#1.5 padded signature block. So either the
> > "b=" value was corrupted in transit, or it was signed by a key
> > that is different from what is published in DNS.
> >
> > > but maybe Postfix is not using the right key?
> >
> > Strictly speaking that's not Postfix itself, but some DKIM milter, but
> > nits aside, more likely a stale public key is published in DNS.
> >
> > --
> > Viktor.
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Joachim Breitner
m...@joachim-breitner.de
http://www.joachim-breitner.de/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
DKIM failures for gitlab mail
Hi Bryan (I assume), I noticed that a small number of Gitlab notification emails end up in my spamfilter. While there is not much you can do about triggering some bayesian style spam filter at my email provider (mailbox.org), I did notice this in the headers: X-Spam-Status: No, score=2.704 tagged_above=2 required=6 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HS_RSPAMD_10_11=2.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: spamfilter01.heinlein-hosting.de (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=gitlab.haskell.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gitlab.haskell.org; s=mail; t=1669733134; bh=D0NUcHiskEnwSP99umP3zo8Fz8fl74OgAJ8NRDKCsp4=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:List-Id: List-Unsubscribe; b=R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvEK M7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD02NS ouI3tvQ9mddNdaEK7retq8N+29hzs/ezf9cpgy+Q= It seems the DKIM configuration is broken? There is a DKIM record for the domain that’s valid acccording to https://www.dmarcanalyzer.com/de/dkim-de/dkim-record-check/?dmarcdns%5Btype%5D=dkim&dmarcdns%5Bselector%5D=mail&dmarcdns%5Bdomain%5D=gitlab.haskell.org&g-recaptcha-response=03AEkXODBDl43rk3Ww0q4J1LNooZNlqBYhWGd3spu68KM7nc3js92zXASAuHqVAek5IJj2iV26sx7LzrDQYX08fq2lnL5CvX4P4x7GOekNSV9yG9J48z0I3SxPzy5tQomgP4u9YR8yQqsmZwezj8coIagpBTce9Ubytv_nRg3oKmJjSYsJP5Pwc4Jmgn___e1nbsHUEqNWabdCJHX0Q02oZ3n3sRS5K8LpYOAFhYhOhMQF9QPQ74Uy8fc38lcuK3LJP6Dk5Z2xmgLJypXJiW4svbNTqnndkSehXM-Y5HJ7xdFZ3aMA4yiOwOOYjZwKc2reQDQ6v6TLrYnigFYgA6D4MM2PBRoc6-D5Zr3xbkjPMOlFVXNMGHpu_w4_nTIaTyRhYaBb1ilz7lYa15f8si5-vVuqT-XFe0U1nVsYHWBj-ejC3Ih7QQzaXdlegM3VMLZ94qBeK5b6uA7fbJv_EpMx3K6EbwVyfmsElNx9KnHOciAcQguIXUxU-EOTN900w-lAoqhxVG-VyqIQe8L99_eW6Ns5IV2tLp4qSg but maybe Postfix is not using the right key? Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Request for Nominations to the GHC Steering Committee
Sorry for that, but Am Donnerstag, dem 06.10.2022 um 14:28 +0200 schrieb Joachim Breitner: > To nominate yourself, please send an email to me (as the committee > secretary) at m...@joachim-breitner.de until February 11th. > should be October 16th. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Request for Nominations to the GHC Steering Committee
Dear Haskell community, the GHC Steering committee is seeking nominations for one or more new members. The committee scrutinizes, nitpicks, improves, weighs and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. In particular, please have a look at the bylaws at https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to maintain in perpetuity in GHC's code base, to learn, and to deal with its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore seek a balance of background, expertise, and views on the committee. Membership of the committee gives you the chance to influence the future direction of Haskell, and to serve the Haskell community. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. To nominate yourself, please send an email to me (as the committee secretary) at m...@joachim-breitner.de until February 11th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. On behalf of the committee, Joachim Breitner -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ambiguous record field (but not *that* kind of ambiguous record field)
Hi,
Am Montag, dem 16.05.2022 um 19:09 + schrieb Richard Eisenberg:
> Hi all,
>
> On a project I'm working on, I wish to declare something like
>
> data Rec = MkRec { field :: forall a. SomeConstraint a => ... }
>
> where the ... contains no mention of `a`.
>
> Even with https://github.com/ghc-proposals/ghc-proposals/pull/448, I
> think there is no way to avoid the ambiguity when setting `field`. Is
> that correct? If so, what shall we do about it? The natural answer is
> somehow to write ... MkRec { field @a = ... } ... but that would
> break significant new syntactic ground. (Maybe it's good new
> syntactic ground, but it would still be very new.)
I’m probably revealing ignorance of #448 this way, but why would
MkRec { field = \@a -> ...}
not work with -XTypeAbstractions
Cheers,
Joachim
--
Joachim Breitner
m...@joachim-breitner.de
http://www.joachim-breitner.de/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Could margebot squash?
Hi, as Richard rightfully says, this is not an aspect of our workflow that we should change right now, so consider this thread now a leisurely coffee machine chat full of hypotheticals, not a concrete call for action. But I’m happy to elaborate the technical details here. Am Montag, dem 04.04.2022 um 09:04 +0100 schrieb Simon Peyton Jones: > One downside of this approach is that it requires destructive changes > to work-in-progres branches: I might think the MR is ready, squash the > commit sequence into a single commit, but then more work is ready. Now > it’s hard to revert individual patches, or collaborate with others, > because the git history was disrupted. > > Another is that the commit message itself isn’t very easily visible to > reviewers. > > I couldn't parse this. What does "but then more work is ready" mean? > Why is it hard to collaborate with others? I think I meant “more work is needed”. Consider the no-app-invariant- MR. I asked Sebastian to collaborate with me on the branch. It could have happened that he was making anther refinement to the DmdAnal while I was preparing the branch for merging. If I made final adjustments, squashed the commits and force-pushed the branch while he was working on it, then he can’t push his branch anymore and has a hell of a time of figuring out what went wrong, because by squashing and force-pushing (the “force” is telling) git lost the history it needs to cleanly merge my changes into his branch to push it again. In “my” workflow, you never have to force-push a feature-branch, so this problem does not occur. > Which commit message "itself isn’t very easily visible to reviewers."? Again, consider the no-app-invariant MR. You approved it, without even knowing what the final commit message would be, because I didn’t squash yet. So the commit message that will end up on master was not visible to you as a reviewer. In “my” workflow, the final commit message will be taken from the MR description, very visible to a reviewer and easily editable by all. Maybe a minor point (commit messages are not as important as, say, good Notes) but still. Also, I often see that MR descriptions are not kept up-to-date as the MR changes; this workflow creates more incentives to keep the MR description good. > I regard squashing as a positive bonus. I take a long series of > commits with messages like "bugfix" and "fix comments" and put them > into one or more logical commits, each doing (so far as poss) as > single thing, each with a comprehensible commit message. I do too! There is still squashing happening, but it is done by margebot, not you manually, and only “in transit” to master – your feature branch is left alone in the process. (This means there would only be _one_ logical commit per MR, not multiple, which may be the biggest downside of this. I thought I disliked the workflow for that reason as well, until I worked with it in a few projects, and I no longer missed it. Multiple logical commits didn’t seem that useful after all, especially since they are no longer individually CI-checked, etc.) Anyways, probably these things become easier and prettier (or simply different) once we can use Gitlab’s native merge train. And unfortunately every workflow is a compromise in one way or another with git… Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Could margebot squash?
04.04.2022 04:21:01 Ben Gamari : > Thankfully there > appears [1] to be a recent uptick in activity; here's to hoping that it > will happen in the next few releases. Thanks, that's a good prospect then :-) ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Could margebot squash?
Hi, as far as I understand, the expected workflow for MRs is that when they are ready, the developer manually squashes the chronological commit history of the MR into a logical one with polished commit messages, typically consisting of a single commit, but could be multiple ones, and then assigns the MR to margebot, which will rebase that sequence of commits onto the staging branch and eventually merges that into master. One downside of this approach is that it requires destructive changes to work-in-progres branches: I might think the MR is ready, squash the commit sequence into a single commit, but then more work is ready. Now it’s hard to revert individual patches, or collaborate with others, because the git history was disrupted. Another is that the commit message itself isn’t very easily visible to reviewers. In other similarly sized projects (e.g. mathlib) I often see a mode where the actual commits of the MR are ignored (so they can represent the true git history of the branch, including merges and all that grit, which is good for collaboration and for reviewers to understand what has happened, without requiring developers to spend cosmetics effort on them), and upon merging by margebot/bors/mergify/whatever, the MR is merged as a single commit with the description taken from the MR description (which encourages developers to keep the MR description up to date as the MR develops, reviewers can easily see that). A downside of this that you’ll always get one commit on master per MR. If you like to submit a curated list of logical commits within one MR, then this would not work, and you’d have to use multiple MRs. Has this been considered? (I don’t want to cause unnecessary disruption with a presumptious call for action here; take it as a comment to weigh in in if and when this part of our infrastructure is about to change anyways, or maybe a careful probe if my sentiment may be shared widely.) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Request for Nominations to the GHC Steering Committee
Dear Haskell community, the GHC Steering committee is seeking nominations for at least two new members. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. In particular, please have a look at the bylaws at https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at m...@joachim-breitner.de until February 11th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: What's the benefit of taking "do" blocks apart? Is there a way to turn that off?
Hi Gergo, Am Dienstag, dem 28.12.2021 um 15:57 + schrieb Erdi, Gergo via ghc- devs: > PUBLIC phew > I’m seeing ‘do’ blocks getting taking apart into top-level > definitions, so e.g. > > main = do > some complicated expression 1 > some complicated expression 2 > > is compiled into > > sat_sKv = some complicated expression 1 > sat_sKw = \_ -> some complicated expression 2 > main = bindIO sat_sKv sat_sKw > > This seems to happen regardless of any common subexpressions, i.e. it > is not the case that sat_sKv or sat_sKw are used anywhere else. > > What is the intended benefit of this floating-out? Is there a > particular Core-to-Core pass that causes this? Is it possible to turn > it off? didn’t investigate deeper (maybe if you provide a small example I would), but just from looking at this: * It is generally preferable to turn local lambda expressions into top-level functions. This way, instead of dynamically allocating a FUN heap object, it’s just a static function. * sat_sKv is an IO expression? Then it is actually a function in a way (taking the “State token” as an argument). So the above applies. * I think this is the FloatOut pass. You can turn it out using -fno-full-laziness. Not sure if some others passes might do similar things, though. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: CI: Choice of base commit for perf comparisons
Thanks! I like it when my feature suggestions are implemented even before I voice them ;-) 22.12.2021 14:13:24 Richard Eisenberg : > It seems to be that this thought is in the air right now. This was done just > a few days ago: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7184 > > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7231 also looks relevant. > > Richard > >> On Dec 22, 2021, at 7:19 AM, Joachim Breitner >> wrote: >> >> Hi, >> >> the new (or “new”?) handling of perf numbers, where CI just magically >> records and compares them, without us having to manually edit the >> `all.T` files, is a big improvement, thanks! >> >> However, I found the choice of the base commit to compare against >> unhelpful. Assume master is at commit M, and I start a feature branch >> and MR with commit A. CI runs, and tells me about a performance >> regressions, and CI is red. I now fix the issue and push commit B to >> the branch. CI runs, but it picks A to compare against, and now it is >> red because of an seemingly unexpected performance improvement! >> >> I would have expected that all CI runs for this MR to compare the >> performance against the base branch on master, and to look for perf >> change notices in all commit messages in between. >> >> I see these advantages: >> >> * The reported perf changes correspond to the changes shown on the MR >> page >> * Green CI = the MR is ready (after squashing) >> * CI will have numbers for the base commit more reliably >> (else, if I push commit C quickly after B, then the job for B might >> be cancelled and Ci will report changes of C against A instead of B, >> which is unexpected). >> >> I have used this logic of reporting perf changes (or any other >> “differential CI”) against the base branch in the Motoko project and it >> was quite natural. >> >> Would it be desirable and possible for us here, too? >> >> >> (A possible rebuttal might be: we don’t push new commits to feature >> branches, but always squash and rebase, as that’s what we have to do >> before merging anyways. If that’s the case then ok, although I >> generally lean to having chronological commits on feature branches and >> a nice squashed commit on master.) >> >> Cheers, >> Joachim >> >> >> -- >> Joachim Breitner >> m...@joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
CI: Choice of base commit for perf comparisons
Hi, the new (or “new”?) handling of perf numbers, where CI just magically records and compares them, without us having to manually edit the `all.T` files, is a big improvement, thanks! However, I found the choice of the base commit to compare against unhelpful. Assume master is at commit M, and I start a feature branch and MR with commit A. CI runs, and tells me about a performance regressions, and CI is red. I now fix the issue and push commit B to the branch. CI runs, but it picks A to compare against, and now it is red because of an seemingly unexpected performance improvement! I would have expected that all CI runs for this MR to compare the performance against the base branch on master, and to look for perf change notices in all commit messages in between. I see these advantages: * The reported perf changes correspond to the changes shown on the MR page * Green CI = the MR is ready (after squashing) * CI will have numbers for the base commit more reliably (else, if I push commit C quickly after B, then the job for B might be cancelled and Ci will report changes of C against A instead of B, which is unexpected). I have used this logic of reporting perf changes (or any other “differential CI”) against the base branch in the Motoko project and it was quite natural. Would it be desirable and possible for us here, too? (A possible rebuttal might be: we don’t push new commits to feature branches, but always squash and rebase, as that’s what we have to do before merging anyways. If that’s the case then ok, although I generally lean to having chronological commits on feature branches and a nice squashed commit on master.) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Plan for GHC 9.2
Hi, Am Donnerstag, den 04.02.2021, 13:56 -0500 schrieb Ben Gamari: > If you see something that you would like to see in 9.2.1 please do > holler. it’s hopefully not big deal technically, but support for GHC2021 would be desirable. There is a MR https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4853 that “just” needs chaising test suite failures when rebasing on latest master (and I’d be grateful if someone more fluent with today’s GHC development than me would take the MR over at this point) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC Logo
Quite a convincing plea :) Am Mittwoch, den 02.09.2020, 12:07 -0400 schrieb John Cotton Ericson: > Yeah I think the old "functional programming is slow" memes died off about > when the rest of the industry went on its JavaScript bender, so I am not > really worried about the negative connotations of turtles. > The positive connotations of turtles sounds very good to me. Besides safety, > the longevity of at least giant tortoises also speaks to GHC's rare ability > to stay at the vanguard of research while still being wildly used. > Their ability to walk and swim speaks to the diverse backends that can be > attached to GHC (NCG, LLVM, GHCJS, Asterius, Clash's, etc.). > Even the fable, from which the slowness myth comes from I guess, goes well > with "avoid success at all costs". > Conversely I am not a fan of choosing a Cat. I like Cats fine in real life, > don't get be wrong, but Cats are so popular on the internet that this would > be the the unmarked animal choice, with no clear connotations or > memorability. I think that would be the juvenile choice, per Ben's slippery > slope. > Foxes are nice, but I think Firefox has that for life. > Octopuses are alright. GitHub's Octocat doesn't doesn't pose nearly as much > of a problem as Firefox for foxes. Still, while Octopuses are smart, they are > usually solitary and mischievous. GHC is very much a long-term group effort, > belying the solitary connotation, and I certainly hope any compiler I use > isn't mischievous! > A turtle for a compiler is a bold choice that indicates our values, > confidence that the performance of compiled code is immune to cheap derision, > and humor. > John > P.S. The funny patterns on turtles' backs could be made of lambdas?... > P.P.S. and yes, if it does compel us to fix rampant list appending just so > we're fast on all fronts, that would be nice too :). > On 9/2/20 11:47 AM, Ben Gamari wrote: > > Richard Eisenberg writes: > > > > > I'm oddly drawn to the idea of a turtle -- except that turtles are > > > slow. But animals are cute. Maybe something involving a fox, given > > > that foxes can be clever? Octopuses are also known to be very clever, > > > but maybe GitHub has octopuses covered. > > > > > > > In general I'm rather neutral on the logo question. There is a fine line > > between "juvenile" (which may detract from the project's credibility in > > the eyes of some) and "cute" (which I think is universally a Good > > Thing); the current rather boring logo was a quick attempt to satisfy > > the need for some logo while recognizing that I lack the artistic > > ability to walk that line. I don't think it's a bad logo but it's quite > > dull and far from being a *good* logo. I do hope someone steps up to do > > better. > > > > Logos aside, I do feel the need to correct the record here: you > > clearly have not seen how quickly a turtle can move when offered banana > > or shrimp. They can be quite quick when suitably incentivized! > > > > Cheers, > > > > - Ben > > > > > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: COMPLETE pragmas
Am Dienstag, den 01.09.2020, 10:11 +0200 schrieb Sebastian Graf: > > 2.) Another scenario that I'd really love to see supported with > > COMPLETE pragmas is a way to use | notation with them like you can > > with MINIMAL pragmas. > > (2) is a neat idea, but requires a GHC proposal I'm not currently > willing to get into. I can also see a design discussion around > allowing arbitrary "formulas" (e.g., not only what is effectively > CNF). > > A big bonus of your design is that it's really easy to integrate into > the current implementation, which is what I'd gladly do in case such > a proposal would get accepted. in the original ticket where a COMPLETE pragma was suggested ( https://gitlab.haskell.org/ghc/ghc/-/issues/8779) the ability to specify arbitrary boolean formulas was already present: “So here is what I think might work well, inspired by the new MINIMAL pragma: … The syntax is essentially the same as for MINIMAL, i.e. a boolean formula, with constructors and pattern synonyms as atoms. In this case” So one _could_ say that this doesn’t need a proposal, because it would just be the implementation finishing the original task ;-) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC 9.0!
Am Freitag, den 24.07.2020, 11:37 -0400 schrieb Ben Gamari: > As no one has objected, let's move ahead with this proposal. GHC 8.12.1 > shall henceforth be 9.0.1. Allow me to fix the Subject of this mail thread then ;-) -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Measuring compiler performance
Hi, Am Montag, den 06.04.2020, 11:03 +0200 schrieb Andreas Klebinger: > > Also, what's the status of gipeda? The most recent commit at > > https://perf.haskell.org/ghc/ is from "about a year ago"? > > > I think the author stopped maintaining it after he switched jobs. So > it's currently not useful > for investigating performance. I think a few things happened. For a while, the dedicated builder (which was a machine on Richard’s university) was down. Then there was a phase where data was collected and the page was generated, but somehow the upload to the web hosting stopped working. Ben started to work on running these things “more properly” as part of Circle CI (but that never finished). And then there is the ways of recording performance data via git notes, which maybe was meant to be fed into gipeda somehow? Somewhere in this confusion (and the fact that there wasn’t much complaining about the lack of this service) it fell off the table. > But I'm sure he wouldn't object if anyone were to pick it up. Definitey not! It seems that “the other” solutions didn’t materialize as quickly as we hoped for, so reactivating perf.haskell.org might be useful. Anybody willing to drive this? Happy to advise! Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Fusing loops by specializing on functions with SpecConstr?
t; > add1rec = SF (\a -> let !b = a+1 in (b,add1rec))
> > add1 = SF (\a -> let !b = a+1 in (b,add1rec))
>
>
> Yes, I was playing with the idea at one point of some kind of RULE that
> inserts GHC.Magic.inline on the specialized RHS. That way the programmer
> could ask for the unrolling explicitly, as otherwise it seems unreasonable to
> ask the compiler to figure it out.
>
> > On Mar 31, 2020, at 08:08, Sebastian Graf wrote:
> >
> > We can formulate SF as a classic Stream that needs an `a` to produce its
> > next element of type `b` like this (SF2 below)
>
>
> This is a neat trick, though I’ve had trouble getting it to work reliably in
> my experiments (even though I was using GHC.Types.SPEC). That said, I also
> feel like I don’t understand the subtleties of SpecConstr very well, so it
> could have been my fault.
>
> The more fundamental problem I’ve found with that approach is that it doesn’t
> do very well for arrow combinators like (***) and (|||), which come up very
> often in arrow programs but rarely in streaming. Fusing long chains of
> first/second/left/right is actually pretty easy with ordinary RULEs, but
> (***) and (|||) are much harder, since they have multiple continuations.
>
> It seems at first appealing to rewrite `f *** g` into `first f >>> second g`,
> which solves the immediate problem, but this is actually a lot less efficient
> after repeated rewritings. You end up rewriting `(f ||| g) *** h` into `first
> (left f) >>> first (right g) >>> second h`, turning two distinct branches
> into four, and larger programs have much worse exponential blowups.
>
> So that’s where I’ve gotten stuck! I’ve been toying with the idea of thinking
> about expression “shells”, so if you have something like
>
> first (a ||| b) >>> c *** second (d ||| e) >>> f
>
> then you have a “shell” of the shape
>
> first (● ||| ●) >>> ● *** second (● ||| ●) >>> ●
>
> which theoretically serves as a key for the specialization. You can then
> generate a specialization and a rule:
>
> $s a b c d e f = ...
> {-# RULE forall a b c d e f.
> first (a ||| b) >>> c *** second (d ||| e) >>> f = $s a b c d e f
> #-}
>
> The question then becomes: how do you specify what these shells are, and how
> do you specify how to transform the shell into a specialized function? I
> don’t know, but it’s something a Core plugin could theoretically do. Maybe it
> makes sense for this domain-specific optimization to be a Core pass that runs
> before the simplifier, like the typeclass specializer currently is, but I
> haven’t explored that yet.
>
> Alexis
--
Joachim Breitner
m...@joachim-breitner.de
http://www.joachim-breitner.de/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
[ghc-steering-committee] The GHC Committee welcomes its new members
Dear Haskell community, the GHC Steering committee welcomes three new members, Alejandro Serrano Mena, Cale Gibbard and Tom Harding. We are happy to see that there is continued interest in our work, and are looking forward to having fresh insights and energy on the committee. They take the seat of Sandy Maguire, who we thank for this productive work during his tenure. As you might notice, we picked more candidates than we filled slots. This is not because Sandy’s productivity need three people to fill. The idea is that there is no reason to turn away a motivated contributor just to stick to the arbitrary 10 members. Instead, we will aim at “roughly 10”, and probably not call for new members until we have dropped below that number again. On behalf of the committee, Joachim Breitner PS: Alejandro, Cale and Tom, please send me your github handles and subscribe to the mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Request for Nominations to the GHC Steering Committee
Dear Haskell community, the GHC Steering committee is seeking nominations for one new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at m...@joachim-breitner.de until January 2nd. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Question about negative Integers
Hi, Am Freitag, den 15.11.2019, 17:04 +0100 schrieb Sylvain Henry: > However integer-gmp and > integer-simple fake two's complement encoding for Bits operations. just a small factoid: the Coq standard library provide the same semantics. I’d lean towards leaving it as it is. If someone need the “other” semantics, they can easily throw in a (very efficient) `abs` in the right places. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
The GHC Committee welcomes its new members
Dear Haskell community, the GHC Steering committee welcomes its new two members, Sandy Maguire and Arnaud Spiwack. We are happy to see that there is continued interest in our work, and are looking forward to the insights and energy that are brought to the committee by Sandy and Arnaud. They take the seats of Ben Gamari and Manuel Chakravarty. A big thanks to Ben and Manuel for their contributions to GHC and the proposal committee. In particular Ben, who created the initials draft of the proposal process. We had four nominations in total, and I would like to preserve their privacy. Since we only had two seats to fill, we had to make a pick; nevertheless I am grateful for all nominations, and encourage everyone, including those who did not make it this time, to try again next time. Neither the committee nor its process is perfect, as the way two recent proposals went show, but we are constantly trying to refine and improve. Your feedback is always welcome, either at the committee mailing list, or in private communication with the Chairs (the two Simons), me, or any other member. On behalf of the committee, Joachim Breitner PS: Sandy and Arnaud, please subscribe to the mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Request for Nominations to the GHC Steering Committee
Dear Haskell community, the GHC Steering committee is seeking nominations for two or three new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at m...@joachim-breitner.de until June 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Website for viewing proposals
Hi, we have a solution that needed 10 mins of setup and is completely self- hosting otherwise, with a proven, open-source friendly provider, at the expense of a possibly odd (but custom) domain name. I think this is very good effort to result ratio. If someone wants do to recreate that manually, that’s ok with it, but maybe I’m too old and lazy to be excited by the process. Anyways, bedtime here. I’ll read tomorrow if we shall use this, of if someone else steps up to be the master of the accepted ghc proposals webpage deployment, and has created something more bespoke (in which I case I can remove the readthedocs setup again). Cheer, Joachim Am Freitag, den 10.05.2019, 23:34 +0100 schrieb Matthew Pickering: > The GHC website is already deployed by gitlab. It could be possible to > set up a nightly job which clones the ghc-proposals repo and deploys > it in a similar manner. > > I do feel that it would be very unfortunate if the proposals were > distant from the supposed official GHC homepage. > > Matt > > On Fri, May 10, 2019 at 11:33 PM Joachim Breitner > wrote: > > Hi, > > > > unfortunately it has to be a dedicated domain, not an URL on some other > > domain, to get the easy, no-additional-work hosting from readthedocs. > > > > Cheers, > > Joachim > > > > Am Freitag, den 10.05.2019, 23:30 +0100 schrieb Matthew Pickering: > > > Perhaps the correct URL should be > > > > > > ghc.haskell.org/proposals > > > > > > but that redirects to https://www.haskell.org/ghc/ > > > > > > So is the correct URL https://www.haskell.org/ghc/proposals ? > > > > > > Anyway, there should probably be some mention of the proposals process > > > on the GHC website which is sorely unloved. > > > > > > Matt > > > > > > On Fri, May 10, 2019 at 11:26 PM Gershom B wrote: > > > > Joachim -- will the readthedocs settings automatically know how to > > > > direct things once the cname is set? > > > > > > > > Also, I'd note that the documentation needs a little cleanup to make > > > > clear that this is the page for _accepted_ proposals, not all > > > > proposals -- perhaps it should also link back to the PR tracker as > > > > well? (And also the nice generation makes obvious that there are a few > > > > too many proposals numbered "1" :-)). Along those lines too, perhaps > > > > the name should be bikeshedded a bit for that reason -- > > > > ghc-proposals.haskell.org makes it look like that's where I'd go to > > > > get all proposals, not just the accepted ones. > > > > > > > > Cheers, > > > > Gershom > > > > > > > > On Fri, May 10, 2019 at 6:22 PM Matthew Pickering > > > > wrote: > > > > > Thanks Joachim, that looks good. > > > > > > > > > > I might have a go styling the site this weekend to make it fit in more > > > > > with the Haskell.org theme. > > > > > > > > > > Matt > > > > > > > > > > On Fri, May 10, 2019 at 11:13 PM Joachim Breitner > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > given that Matthew already created a sphinx setup, GitHub pages > > > > > > isn’t > > > > > > optimal. You need to use some other CI system like Travis to > > > > > > actually > > > > > > build the page and push it, which I have set up a few times and is > > > > > > possible, not completely straight-forward. What is straight-forward > > > > > > is > > > > > > readthedocs.io, where I essentially just pressed one button and got > > > > > > this: > > > > > > > > > > > >https://ghc-proposals.readthedocs.io/en/latest/ > > > > > > > > > > > > Neat, isn’t it? I will clean up the section numbering. > > > > > > > > > > > > > > > > > > The only thing I’d like to do before making this official is to use > > > > > > a > > > > > > more permanent URL, in case we move this somewhere else. For that > > > > > > I’d > > > > > > need a haskell.org admin to add a CNAME from > > > > > > > > > > > >ghc-proposals.haskell.org > > > > > > > > > > > > to > > > > >
Re: Website for viewing proposals
Hi, unfortunately it has to be a dedicated domain, not an URL on some other domain, to get the easy, no-additional-work hosting from readthedocs. Cheers, Joachim Am Freitag, den 10.05.2019, 23:30 +0100 schrieb Matthew Pickering: > Perhaps the correct URL should be > > ghc.haskell.org/proposals > > but that redirects to https://www.haskell.org/ghc/ > > So is the correct URL https://www.haskell.org/ghc/proposals ? > > Anyway, there should probably be some mention of the proposals process > on the GHC website which is sorely unloved. > > Matt > > On Fri, May 10, 2019 at 11:26 PM Gershom B wrote: > > Joachim -- will the readthedocs settings automatically know how to > > direct things once the cname is set? > > > > Also, I'd note that the documentation needs a little cleanup to make > > clear that this is the page for _accepted_ proposals, not all > > proposals -- perhaps it should also link back to the PR tracker as > > well? (And also the nice generation makes obvious that there are a few > > too many proposals numbered "1" :-)). Along those lines too, perhaps > > the name should be bikeshedded a bit for that reason -- > > ghc-proposals.haskell.org makes it look like that's where I'd go to > > get all proposals, not just the accepted ones. > > > > Cheers, > > Gershom > > > > On Fri, May 10, 2019 at 6:22 PM Matthew Pickering > > wrote: > > > Thanks Joachim, that looks good. > > > > > > I might have a go styling the site this weekend to make it fit in more > > > with the Haskell.org theme. > > > > > > Matt > > > > > > On Fri, May 10, 2019 at 11:13 PM Joachim Breitner > > > wrote: > > > > Hi, > > > > > > > > given that Matthew already created a sphinx setup, GitHub pages isn’t > > > > optimal. You need to use some other CI system like Travis to actually > > > > build the page and push it, which I have set up a few times and is > > > > possible, not completely straight-forward. What is straight-forward is > > > > readthedocs.io, where I essentially just pressed one button and got > > > > this: > > > > > > > >https://ghc-proposals.readthedocs.io/en/latest/ > > > > > > > > Neat, isn’t it? I will clean up the section numbering. > > > > > > > > > > > > The only thing I’d like to do before making this official is to use a > > > > more permanent URL, in case we move this somewhere else. For that I’d > > > > need a haskell.org admin to add a CNAME from > > > > > > > >ghc-proposals.haskell.org > > > > > > > > to > > > > > > > >readthedocs.io > > > > > > > > CC’ing gershom, hope he is the right contact for this task. > > > > > > > > Cheers, > > > > Joachim > > > > > > > > > > > > Am Freitag, den 10.05.2019, 13:33 -0700 schrieb Iavor Diatchki: > > > > > Having a read-only rendered version of all accepted proposals should > > > > > probably be pretty simple---we can even host it in the same repo using > > > > > "Github Pages".I don't know that we need anything more complex > > > > > than that. > > > > > > > > > > On Thu, May 9, 2019 at 5:41 AM Joachim Breitner > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > I looked into getting doi’s for our accepted proposals, but it > > > > > > looked > > > > > > harder than it should be. > > > > > > > > > > > > Building a nice web page from our repository and publishing it on > > > > > > GitHub pages, which can serve a custom domain like > > > > > > ghc-proposals.haskell.org would not be hard. Matthew even started a > > > > > > Makefile at some point that produces a reasonably nice output using > > > > > > sphinx. > > > > > > > > > > > > Maybe only reason why I am hesitant to do so is that there is a > > > > > > feature > > > > > > creep risk: > > > > > > We start with a webpage that shows accepted proposals, > > > > > > soon we’ll add functionality to list pending proposals and their > > > > > > status > > > > > > (why not? They are just a GitHub API call away
Re: Website for viewing proposals
Hi, Am Freitag, den 10.05.2019, 23:22 +0100 schrieb Matthew Pickering: > I might have a go styling the site this weekend to make it fit in more > with the Haskell.org theme. that’d be awesome. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Website for viewing proposals
Hi, Am Freitag, den 10.05.2019, 18:26 -0400 schrieb Gershom B: > Joachim -- will the readthedocs settings automatically know how to > direct things once the cname is set? yes I have configured things on that side already. Should work right away. > Also, I'd note that the documentation needs a little cleanup to make > clear that this is the page for _accepted_ proposals, not all > proposals -- perhaps it should also link back to the PR tracker as > well? (And also the nice generation makes obvious that there are a few > too many proposals numbered "1" :-)). Reload, both fixed a few minutes ago. > Along those lines too, perhaps > the name should be bikeshedded a bit for that reason -- > ghc-proposals.haskell.org makes it look like that's where I'd go to > get all proposals, not just the accepted ones. accepted-ghc-proposals.haskell.org doesn’t make a pretty domain name. We will add a intro to that page explaining what this page is, and point to the GitHub repo for more details. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Website for viewing proposals
Hi, given that Matthew already created a sphinx setup, GitHub pages isn’t optimal. You need to use some other CI system like Travis to actually build the page and push it, which I have set up a few times and is possible, not completely straight-forward. What is straight-forward is readthedocs.io, where I essentially just pressed one button and got this: https://ghc-proposals.readthedocs.io/en/latest/ Neat, isn’t it? I will clean up the section numbering. The only thing I’d like to do before making this official is to use a more permanent URL, in case we move this somewhere else. For that I’d need a haskell.org admin to add a CNAME from ghc-proposals.haskell.org to readthedocs.io CC’ing gershom, hope he is the right contact for this task. Cheers, Joachim Am Freitag, den 10.05.2019, 13:33 -0700 schrieb Iavor Diatchki: > Having a read-only rendered version of all accepted proposals should > probably be pretty simple---we can even host it in the same repo using > "Github Pages".I don't know that we need anything more complex > than that. > > On Thu, May 9, 2019 at 5:41 AM Joachim Breitner > wrote: > > Hi, > > > > I looked into getting doi’s for our accepted proposals, but it looked > > harder than it should be. > > > > Building a nice web page from our repository and publishing it on > > GitHub pages, which can serve a custom domain like > > ghc-proposals.haskell.org would not be hard. Matthew even started a > > Makefile at some point that produces a reasonably nice output using > > sphinx. > > > > Maybe only reason why I am hesitant to do so is that there is a feature > > creep risk: > > We start with a webpage that shows accepted proposals, > > soon we’ll add functionality to list pending proposals and their status > > (why not? They are just a GitHub API call away), > > then we start using this page to actually drive the proposals (surely > > we can use this to tally the votes), > > and then we end up with a system that no longer has the “you just need > > to know GitHub to use it” property that made us build a Github-centric > > process in the first place. > > > > But maybe I am paranoid, and I should just set up the CI infrastructure > > for Matthew’s sphinx build. > > > > BTW, in hindsight, I regret that we renumber proposals after > > acceptance. It would be easier if they just retained the number of the > > PR (other proposal processes out there do that). But that ship has > > sailed. > > > > Cheers, > > Joachim > > > > Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > > > I want to cite a GHC proposal but linking to github for it doesn't > > > seem very official or permanent. > > > > > > Last year you also cited a proposal for your Haskell symposium paper > > > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > > > request which also doesn't seem ideal to me. > > > > > > Matt > > > > > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > > > wrote: > > > > Interesting. How would it differ from what we have (i.e. github's RST > > > > viewer)? > > > > > > > > > -Original Message- > > > > > From: ghc-devs On Behalf Of Matthew > > > > > Pickering > > > > > Sent: 09 May 2019 09:40 > > > > > To: GHC developers > > > > > Subject: Website for viewing proposals > > > > > > > > > > Hi, > > > > > > > > > > It would be useful if there was a canonical way to link and view GHC > > > > > proposals rather than relying on github's RST viewer. > > > > > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is > > > > > deployed to > > > > > automatically when a new accepted proposal is merged? > > > > > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > > > deployment would be easy using our CI infrastructure but I don't > > > > > know how > > > > > to set up something similar on github. > > > > > > > > > > Cheers, > > > > > > > > > > Matt > > > > > ___ > > > > > ghc-devs mailing list > > > > > ghc-devs@haskell.org > > > > > > > > > > https://nam06.safelinks.protection.outlook.com/?
Re: Website for viewing proposals
Hi, I looked into getting doi’s for our accepted proposals, but it looked harder than it should be. Building a nice web page from our repository and publishing it on GitHub pages, which can serve a custom domain like ghc-proposals.haskell.org would not be hard. Matthew even started a Makefile at some point that produces a reasonably nice output using sphinx. Maybe only reason why I am hesitant to do so is that there is a feature creep risk: We start with a webpage that shows accepted proposals, soon we’ll add functionality to list pending proposals and their status (why not? They are just a GitHub API call away), then we start using this page to actually drive the proposals (surely we can use this to tally the votes), and then we end up with a system that no longer has the “you just need to know GitHub to use it” property that made us build a Github-centric process in the first place. But maybe I am paranoid, and I should just set up the CI infrastructure for Matthew’s sphinx build. BTW, in hindsight, I regret that we renumber proposals after acceptance. It would be easier if they just retained the number of the PR (other proposal processes out there do that). But that ship has sailed. Cheers, Joachim Am Donnerstag, den 09.05.2019, 10:45 +0100 schrieb Matthew Pickering: > I want to cite a GHC proposal but linking to github for it doesn't > seem very official or permanent. > > Last year you also cited a proposal for your Haskell symposium paper > (https://arxiv.org/abs/1806.03476) but instead linked to the pull > request which also doesn't seem ideal to me. > > Matt > > On Thu, May 9, 2019 at 10:11 AM Simon Peyton Jones > wrote: > > Interesting. How would it differ from what we have (i.e. github's RST > > viewer)? > > > > > -Original Message- > > > From: ghc-devs On Behalf Of Matthew > > > Pickering > > > Sent: 09 May 2019 09:40 > > > To: GHC developers > > > Subject: Website for viewing proposals > > > > > > Hi, > > > > > > It would be useful if there was a canonical way to link and view GHC > > > proposals rather than relying on github's RST viewer. > > > > > > Can we set up a website, `ghc.haskell.org/proposals`, which is deployed > > > to > > > automatically when a new accepted proposal is merged? > > > > > > FWIW, if the proposals process was also on gitlab then doing this > > > deployment would be easy using our CI infrastructure but I don't know how > > > to set up something similar on github. > > > > > > Cheers, > > > > > > Matt > > > ___ > > > ghc-devs mailing list > > > ghc-devs@haskell.org > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > > > ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > > > > > devs&data=01%7C01%7Csimonpj%40microsoft.com%7C33b5834164a1436bd09308d6 > > > > > > d459edc0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vWx4R2xtV2%2BX7l > > > RpM0weHo87NIc7pl0MoIiW76R%2BDdM%3D&reserved=0 > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC HEAD documentation once again available
Hi, great work! (Not only this, of course. I just felt it was time to express praise.) Cheers, Joachim Am Samstag, den 30.03.2019, 20:56 -0400 schrieb Ben Gamari: > TL;DR. A snapshot of GHC's documentation from the master branch can >always be found at [2]. > > > Hi everyone, > > Quite a while ago I made it a habit of periodically pushing > documentation snapshots from GHC's master branch to > downloads.haskell.org [1]. Unfortunately, despite some attempts at > automating this process, this frequently grew out-of-date. > > I am happy to report that documentation snapshots are now generated > as a product of GHC's CI process and made available here [2]. The old > downloads.haskell.org URL redirects to [2] and consequently should now > always be up-to-date. > > Let me know if you notice anything amiss. > > Cheers, > > - Ben > > > [1] https://downloads.haskell.org/ghc/master/ > [2] https://ghc.gitlab.haskell.org/ghc/doc/ > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: CI request: a DEBUG compiler
Hi, Am Sonntag, den 27.01.2019, 09:56 -0500 schrieb Richard Eisenberg: > Clearly, having a CI trace of this would simplify things -- not to > mention catch bugs earlier. absolutely agree, and I can’t help but notice that our first CI setup on travis that I created four years ago had a DEBUG build right from the start. (And back then I also noticed that not many developers seem to be using a DEBUG build…) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GitLab migration status
Hi, Am Montag, den 17.12.2018, 00:29 -0500 schrieb Ben Gamari: > 2. We begin officially accepting merge requests on this fresh GitLab > instance on Tuesday. At this point gitlab.haskell.org:ghc/ghc will > become GHC's official upstream repository. I guess this works only because GitLab has a different name (number) space for merge requests and issues, so creating MRs does not create collisions with the issues merged later … so yay :-) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Fwd: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70)
guide/ghci.rst > +++ b/docs/users_guide/ghci.rst > @@ -37,7 +37,7 @@ command ``ghci``: > .. code-block:: none > $ ghci > - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help > + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help > Prelude> > There may be a short pause while GHCi loads the prelude and standard > @@ -2052,7 +2052,7 @@ by using the :ghc-flag:`-package ⟨pkg⟩` flag: > .. code-block:: none > $ ghci -package readline > - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help > + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Loading package readline-1.0 ... linking ... done. > Prelude> > diff --git a/ghc/GHCi/UI.hs b/ghc/GHCi/UI.hs > index ae8ba02..13275f8 100644 > --- a/ghc/GHCi/UI.hs > +++ b/ghc/GHCi/UI.hs > @@ -162,7 +162,7 @@ defaultGhciSettings = > ghciWelcomeMsg :: String > ghciWelcomeMsg = "GHCi, version " ++ cProjectVersion ++ > - ": http://www.haskell.org/ghc/ :? for help" > + ": https://www.haskell.org/ghc/ :? for help" > ghciCommands :: [Command] > ghciCommands = map mkCmd [ > diff --git a/rts/RtsMessages.c b/rts/RtsMessages.c > index 053805e..a90962e 100644 > --- a/rts/RtsMessages.c > +++ b/rts/RtsMessages.c > @@ -172,7 +172,7 @@ rtsFatalInternalErrorFn(const char *s, va_list ap) > #endif > fprintf(stderr, "\n"); > fprintf(stderr, " (GHC version %s for %s)\n", ProjectVersion, > xstr(HostPlatform_TYPE)); > - fprintf(stderr, " Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug\n";); > + fprintf(stderr, " Please report this as a GHC bug: > https://www.haskell.org/ghc/reportabug\n";); > fflush(stderr); > } > #if defined(mingw32_HOST_OS) > > ___ > ghc-commits mailing list > ghc-comm...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: nofib output difference
Hi, now it fail building nofib with a different error: ==nofib== compress: time to compile Uncompress follows... /home/nomeata/logs/ghc-tmp-REV/inplace/bin/ghc-stage2 -O2 -Wno-tabs -Rghc-timing -H32m -hisuf hi -rtsopts -c Uncompress.hs -o Uncompress.o Decode.hs:25:1: error: Main.hs:16:1: error: Encode.hs:9:1: error:Uncompress.hs:15:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 25 | import Defaults | ^^^ Decode.hs:26:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 16 | import Defaults | ^^^ Main.hs:17:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 9 | import Defaults | ^^^ Encode.hs:10:1: error: Could not find module ‘Defaults’ Perhaps you meant TcDefaults (needs flag -package-key ghc-8.7) Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 15 | import Defaults | ^^^ Uncompress.hs:16:1: error: Could not find module ‘BinConv’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 26 | import BinConv | ^^ Could not find module ‘BinConv’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 17 | import BinConv-- binary conversion routines | ^^ Main.hs:18:1: error: Could not find module ‘PTTrees’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 10 | import PTTrees | ^^ Could not find module ‘BinConv’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 16 | import BinConv-- binary conversion routines | ^^ Uncompress.hs:17:1: error: Could not find module ‘Encode’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 18 | import Encode -- coding routine | ^ Could not find module ‘Decode’ Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 17 | import Decode -- decoding routines | ^ -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: nofib output difference
Hi, Am Donnerstag, den 29.11.2018, 10:13 -0500 schrieb Ben Gamari: > Yikes, this is indeed somewhat worrying. I see the same result as you > for result1 and result2 but a slightly different number for result3. > > Looking at this particular test it appears to be quite numerically > unstable. I count over ten distinct sets of .stdout files in > spectral/fft2, some of which match what the results I observe quite > closely. > > Overall we should indeed make sure these get tested in CI. > > Do you know how long ago this change occurred? Not easily, there were other breakages on perf.haskell.org that probably shadowed this. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
nofib output difference
Hi, currently, perf.haskell.org has stopped because recent commits fail to build with: expected stdout not matched by reality --- fft2.stdout72018-11-28 12:00:24.126015465 -0500 +++ /tmp/runtest6392.1 2018-11-28 12:59:59.329423367 -0500 @@ -1,3 +1,3 @@ -result1 = 2.59635799135966e-12 -result2 = 2.59635799135966e-12 -result3 = 4.8279900966008427e-8 +result1 = 2.649891777856828e-12 +result2 = 2.649891777856828e-12 +result3 = 4.830900479646516e-8 make[2]: *** [../../mk/target.mk:102: runtests] Error 1 do others observe this as well? This is worrying, because there has been no change to nofib since it last worked. Can we add a check of the functional correctness of the nofib programs to the CI somehow? Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: nofib oldest GHC to support?
Hi, there is no policy that I am aware of, but being able to run nofib on old (or even ancient) versions of GHC is likely to make someone happy in the future, so I’d say that the (valid!) desire to cleanup is not a good reason to drop support – only if it would require unreasonable efforts should we drop old versions there. Cheers, Joachim Am Sonntag, den 30.09.2018, 14:18 +0300 schrieb Ömer Sinan Ağacan: > Do we have a policy on the oldest GHC to support in nofib? I'm currently doing > some hacking on nofib to parse some new info printed by a modified GHC, and I > think we can do a lot of cleaning (at the very least remove some regexes and > parsers) if we decide on which GHCs to support. > > I checked the README and RunningNoFib wiki page but couldn't see anything > relevant. > > Thanks > > Ömer > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Any ways to test a GHC build against large set of packages (including test suites)?
Hi, Am Freitag, den 10.08.2018, 20:06 -0400 schrieb Ben Gamari: > Head.hackage doesn't have an out of the box package set but it is > quite straightforward to construct such a set. While I now tend to > use nix, in the past I generally just constructed a dummy cabal > package listing the packages of interest as dependencies. > > There are two approaches to choosing a set of packages: extract the > packages from Stackage's build-constraints.yaml or just additively > build up a set from the top of your head. I find the latter is often > more realistic; stackage is now large enough that even getting a > fraction of it to build with a prerelease compiler can be a > significant undertaking. here is another package set worth considering, if you want a representative collection of packages with (somewhat) significance: The packages distributed by Debian: https://salsa.debian.org/haskell-team/package-plan/raw/master/packages.txt Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Request for Nominations to the GHC Steering Committee
Dear Haskell community, the GHC Steering committee is seeking nominations for a new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at m...@joachim-breitner.de until July 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How to use ghc-heap-view of ghc-8.6
Hi, Am Samstag, den 07.07.2018, 04:05 + schrieb Patrick Dougherty: > P.S. Sorry about using [1] so many times. Both libraries are called > heap-view which makes it a little difficult to distinguish. it seems that my hack on hackage is called ghc-heap-view, and the thing landed in GHC just ghc-heap :-) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Diagonally in Data.Bimap
Hi Am Donnerstag, den 05.07.2018, 15:36 +0200 schrieb Gabor Greif: > Hi! > > Just searched for a `bimap` variant that simultaneously transforms > both components with the same morphism: > > ``` haskell > diag :: Bifunctor p => (a -> b) -> p a a -> p b b > diag f = bimap f f > ``` > > I did not find any. Would it make sense to add it? possibly, I have wanted it too before. Bikeshedding: I’d have expected the name “both”. It also has precedence here: http://hackage.haskell.org/package/extra/docs/Data-Tuple-Extra.html#v:both http://hackage.haskell.org/package/concatenative/docs/Control-Concatenative.html#v:both http://hackage.haskell.org/package/MissingK/docs/Control-Arrow-Extra.html#v:both http://hackage.haskell.org/package/lens-family/docs/Lens-Family2-Stock.html#v:both http://hackage.haskell.org/package/lens/docs/Control-Lens-Traversal.html#v:both Diagonally sounds more like something of type `a -> (a,a)` or similar. > PPS: I would have sent this to librar...@haskell.org but it seem to be > closed group. It should not. Maybe only open to subscribers? (A common crude anti- spam measurement.) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Should we have primitive fill-once variables?
Hi, Am Freitag, den 29.06.2018, 12:54 -0400 schrieb David Feuer: > On Friday, June 29, 2018 11:51:07 AM EDT Joachim Breitner wrote: > > when reading the subject I was expecting something like this: > > > >-- | pure! but blocks until the IVar is written > >readIVar :: IVar a -> a > > > >-- | tries to write to an IVar. > >-- Succeeds if it is empty (returning True) > >-- Does nothing if it has been written to (returning False) > >writeIVar :: IVar a -> a -> IO Bool > > It really depends. Are there useful (compile-time or run-time) > optimization for IVars (write-once) that don't apply to QVars (fill- > once)? If so, we might indeed want to offer writeIVar as you suggest, > and I don’t know! Maybe the GC can treat a filled IVar differently (because it is no longer mutable?) But really, I don't know :-) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Should we have primitive fill-once variables?
Hi, when reading the subject I was expecting something like this: -- | Creates an empty IVar newIVar :: IO (IVar a) -- | pure! but blocks until the IVar is written readIVar :: IVar a -> a -- | tries to write to an IVar. -- Succeeds if it is empty (returning True) -- Does nothing if it has been written to (returning False) writeIVar :: IVar a -> a -> IO Bool Alternatively: -- | all in one newIVar :: IO (a, a -> IO Bool) Essentially a thunk, but with explicit control over filling it. In fact, people have implemented something like this using C-- hacks before: https://github.com/twanvl/unsafe-sequence > This would make MonadFix's implementation much nicer, I think :) This would suffice for MonadFix, right? Sorry for derailing the thread :-) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How do you build base with your own compiler?
Hi, Am Donnerstag, den 28.06.2018, 18:08 +0100 schrieb Christopher Done: > I've built the GHC compiler along with libraries/base in the canonical way. > > Now, I want to compile base with my own compiler frontend which will > do some analysis. maybe https://github.com/nomeata/veggies/blob/master/boot.sh can be some inspiration? There I build boot using a GHC with a very different code generator. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Loading GHC into GHCi (and ghcid)
Hi, Am Donnerstag, den 07.06.2018, 17:05 -0400 schrieb Ben Gamari: > How about on a new page (e.g. Building/InGhci) linked to from, > > * https://ghc.haskell.org/trac/ghc/wiki/Building > * https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions (in the Tips >& Tricks section) > > It might also be a good idea to add a script to the tree capturing this > pattern. yes pretty please! Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: Remove ad-hoc special case in occAnal (c16382d)
Dear Simon (and everyone else), Am Donnerstag, den 07.06.2018, 10:06 + schrieb g...@git.haskell.org: > I did look at the > tiny increase in allocation for cacheprof and concluded that it was > unimportant (I forget the details). don’t bother with cacheprof, it's allocation number is non- deterministic: https://ghc.haskell.org/trac/ghc/ticket/8611 I wonder how many hours were wasted by people trying find some causal connection between their change and cacheprof… Maybe we should just remove cacheprof? Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Combining Bag/OrdList?
Hi, Am Samstag, den 02.06.2018, 10:55 -0700 schrieb Jared Weakly: > > It looks to me like many of the applications of snocBag should really be > > using OrdList. > > Do you think there's benefit in refactoring to use ordList and then > removing snoc/cons from the bag API (instead providing only > operations that make no assumptions about ordering)? would you remove `toList` (which has to fix an ordering)? Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Inconsistency in CoreSubst invariant
Hi, Am Freitag, den 25.05.2018, 11:33 + schrieb Simon Peyton Jones: > Ha! That comment is out of date. More up to date is Note [The substitution > invariant] in TyCoRep. I've updated it (and will commit in a moment) to say > the stuff below. > > Does that answer the question? indeed it does! Thanks, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Inconsistency in CoreSubst invariant
Hi, Stephanie stumbled on this apparent inconsistency in CoreSubst, about what ought to be in the in_scope_set of a Subst. On the one hand, the file specifies #in_scope_invariant# The in-scope set contains at least those 'Id's and 'TyVar's that will be in scope /after/ applying the substitution to a term. Precisely, the in-scope set must be a superset of the free vars of the substitution range that might possibly clash with locally-bound variables in the thing being substituted in. Note that the first sentence does not actually imply the second (unless you replace “Precisely” with “In particular”). But the comment even explicitly states: Make it empty, if you know that all the free vars of the substitution are fresh, and hence can't possibly clash Looking at the code I see that lookupIdSubst indeed expects all variables in either the actual substitution or in the in_scope_set: lookupIdSubst :: SDoc -> Subst -> Id -> CoreExpr lookupIdSubst doc (Subst in_scope ids _ _) v | not (isLocalId v) = Var v | Just e <- lookupVarEnv ids v = e | Just v' <- lookupInScope in_scope v = Var v' -- Vital! See Note [Extending the Subst] | otherwise = WARN( True, text "CoreSubst.lookupIdSubst" <+> doc <+> ppr v $$ ppr in_scope) Var v Note the warning! It seems that one of these three are true: A The invariant should be the first sentence; in particular; the in_scope_set contains all the free variables that are not substituted. The rest of that comment needs to be updated to reflect that. B The invariant should be the second sentence, and the WARN is bogus, i.e. WARNs about situations that are actually ok. The rest of that comment needs to be updated, and the WARN removed. C The invariant should be the second sentence, and the WARN is still ok there because, well, it is only a warning and only appears in DEBUG builds. The rest of that comment needs to be updated, the WARN remains. Which one is it? Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
505 Error on https://www.haskell.org/ghc/license.html
Hi, on https://www.haskell.org/ghc/license.html I see 500 Internal Server Error nginx before and after the text. I don’t expect many people to look there, but still ugly. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Add HeapView functionality (ec22f7d)
Hi, Am Sonntag, den 20.05.2018, 15:43 + schrieb g...@git.haskell.org: > commit ec22f7ddc81b40a9dbcf140e5cf44730cb776d00 > Author: Patrick Dougherty > Date: Wed May 16 16:50:13 2018 -0400 > > Add HeapView functionality > > This pulls parts of Joachim Breitner's ghc-heap-view library inside GHC. > The bits added are the C hooks into the RTS and a basic Haskell wrapper > to these C hooks. The main reason for these to be added to GHC proper > is that the code needs to be kept in sync with the closure types > defined by the RTS. It is expected that the version of HeapView shipped > with GHC will always work with that version of GHC and that extra > functionality can be layered on top with a library like ghc-heap-view > distributed via Hackage. whoohoo, this is great! I did not not expect that the horrifying (but maybe not horrible) hack that I wrote so many years ago becomes an official feature :-) I’ll be curious in what ways our community will use (or abuse) this feature… Patrick, you mention that a library like ghc-heap-view will still be required. Are you interested in updating it to use the new interfaces, or even take it over completely? Compatibility with ghc-vis (http://felsin9.de/nnis/ghc-vis/) is probably the most important goal here. I’m CC’ing the author of ghc- vis, Dennis. Or maybe ghc-vis should use the GHC-provided wrappers directly? Dennis, are you still invested in maintaining ghc-vis? Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Re: potential for GHC benchmarks w.r.t. optimisations being incorrect
Hi, Am Sonntag, den 06.05.2018, 16:41 +0200 schrieb Andreas Klebinger: > With a high number of NoFibRuns (30+) , disabling frequency scaling, > stopping background tasks and walking away from the computer > till it was done I got noise down to differences of about +/-0.2% for > subsequent runs. > > This doesn't eliminate alignment bias and the like but at least it > gives fairly reproducible results. That’s true, but it leaves alignment bias. This bit my in my work on Call Arity, as I write in my thesis: Initially, I attempted to use the actual run time measurements, but it turned out to be a mostly pointless endeavour. For example the knights benchmark would become 9% slower when enabling Call Arity (i.e. when comparing (A) to (B)), a completely unexpected result, given that the changes to the GHC Core code were reasonable. Further investigation using performance data obtained from the CPU indicated that with the changed code, the CPU’s instruction decoder was idling for more cycles, hinting at cache effects and/or bad program layout. Indeed: When I compiled the code with the compiler flag -g, which includes debugging information in the resulting binary, but should otherwise not affect the relative performance characteristics much, the unexpected difference vanished. I conclude that non-local changes to the Haskell or Core code will change the layout of the generated program code in unpredictable ways and render such run time measurements mostly meaningless. This conclusion has been drawn before [MDHS09], and recently, tools to mitigate this effect, e.g. by randomising the code layout [CB13], were created. Unfortunately, these currently target specific C compilers, so I could not use them here. In the following measurements, I avoid this problem by not measuring program execution time, but simply by counting the number of instructions performed. This way, the variability in execution time due to code layout does not affect the results. To obtain the instruction counts I employ valgrind [NS07], which runs the benchmarks on a virtual CPU and thus produces more reliable and reproducible measurements. Unpleasant experience. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: potential for GHC benchmarks w.r.t. optimisations being incorrect
Hi, Am Samstag, den 05.05.2018, 12:33 -0400 schrieb Daniel Cartwright: > I write this out of curiosity, as well as concern, over how this may affect > GHC. our performance measurements are pretty non-scientific. For many decades, developers just ran our benchmark suite (nofib) before and after their change, hopefully on a cleanly built working copy, and pasted the most interesting numbers in the commit logs. Maybe some went for coffee to have an otherwise relatively quiet machine (or have some remote setup), maybe not. In the end, the run-time performance numbers are often ignored and we we focus on comparing the effects of *dynamic heap allocations*, which are much more stable across different environments, and which we believe are a good proxy for actual performance, at least for the kind of high-level optimizations that we work on in the core-to-core pipeline. But this assumption is folklore, and not scientifically investigated. Since two years or so we started collecting performance numbers for every commit to the GHC repository, and I wrote a tool to print comparisons: https://perf.haskell.org/ghc/ This runs on a dedicated physical machine, and still the run-time numbers were varying too widely and gave us many false warnings (and probably reported many false improvements which we of course were happy to believe). I have since switched to measuring only dynamic instruction counts with valgrind. This means that we cannot detect improvement or regressions due to certain low-level stuff, but we gain the ability to reliably measure *something* that we expect to change when we improve (or accidentally worsen) the high-level transformations. I wish there were a better way of getting a reliable, stable number that reflects the actual performance. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Open up the issues tracker on ghc-proposals
Fixed! Am Dienstag, den 01.05.2018, 15:48 -0400 schrieb David Feuer: > The ghc-proposals repository does not have the issue tracker enabled, so it's > currently impossible to open an issue. > > On Tuesday, May 1, 2018 3:31:24 PM EDT Joachim Breitner wrote: > > Hi, > > > > the distiction between an issue and a pull request is a rather thin > > one, and the Github API actually allows you to upgrade an issue to a > > pull request… > > > > So no need to be picky about the precise form: If someone has something > > interesting to say in an issue without yet having some text to attach > > to it, by all means go for it! > > > > Cheers, > > Joachim > > > > Am Dienstag, den 01.05.2018, 15:23 -0400 schrieb Richard Eisenberg: > > > I like this idea, but I think this can be done as a PR, which seems a > > > better fit for collaborative building. The author can specify that a > > > proposal is a "pre-proposal", with the goal of fleshing it out before > > > committee submission. If it becomes necessary, we can furnish a tag to > > > label these, but I'm honestly not sure we'll need to. > > > > > > Richard > > > > > > > On May 1, 2018, at 2:24 PM, David Feuer wrote: > > > > > > > > Sometimes, a language extension idea could benefit from some community > > > > discussion before it's ready for a formal proposal. I'd like to propose > > > > that we open up the GitHub issues tracker for ghc-proposals to serve as > > > > a place to discuss pre-proposal ideas. Once those discussions converge > > > > on one or a few specific plans, someone can write a proper proposal. > > > > ___ > > > > ghc-devs mailing list > > > > ghc-devs@haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > ___ > > > ghc-devs mailing list > > > ghc-devs@haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Open up the issues tracker on ghc-proposals
Hi, the distiction between an issue and a pull request is a rather thin one, and the Github API actually allows you to upgrade an issue to a pull request… So no need to be picky about the precise form: If someone has something interesting to say in an issue without yet having some text to attach to it, by all means go for it! Cheers, Joachim Am Dienstag, den 01.05.2018, 15:23 -0400 schrieb Richard Eisenberg: > I like this idea, but I think this can be done as a PR, which seems a better > fit for collaborative building. The author can specify that a proposal is a > "pre-proposal", with the goal of fleshing it out before committee submission. > If it becomes necessary, we can furnish a tag to label these, but I'm > honestly not sure we'll need to. > > Richard > > > On May 1, 2018, at 2:24 PM, David Feuer wrote: > > > > Sometimes, a language extension idea could benefit from some community > > discussion before it's ready for a formal proposal. I'd like to propose > > that we open up the GitHub issues tracker for ghc-proposals to serve as a > > place to discuss pre-proposal ideas. Once those discussions converge on one > > or a few specific plans, someone can write a proper proposal. > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
ghc-8.4.1-release tag
Hi, I noticed that the tag ghc-8.4.1-release points to f31c40efdc918bc9da8a325327ba5a472bd6ea9e but the tarball has different content: $ cat /tmp/ghc-8.4.1/GIT_COMMIT_ID 0a3e2f324dbd525d626ebd3d97e8ffa1cf2f0ffb Ben, would you mind updating the git tag to reflect reality, to avoid confusion (it’s be a forced tag update, but still better than inconsistent information). Cheers, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Building GHC using cabal repl
Hi, when hacking on most Haskell projects these days, I enjoy having a shell with ghcid -c 'cabal new-repl -w ghc-8.2' open. I wondered if I can achieve the same when hacking on GHC. The compiler/ directory has a Cabal file. It does not work out-of-the box (in a fully built tree): $ cabal new-repl -w ../inplace/bin/ghc-stage2 -fstage2 Build profile: -w ghc-8.5.20180320 -O1 In order, the following will be built (use -v for more details): - ghc-8.5 (lib) (first run) Preprocessing library for ghc-8.5.. cabal: can't find source for Config in backpack, basicTypes, cmm, codeGen, coreSyn, deSugar, ghci, hsSyn, iface, llvmGen, main, nativeGen, parser, prelude, profiling, rename, simplCore, simplStg, specialise, stgSyn, stranal, typecheck, types, utils, vectorise, /home/jojo/build/haskell/ghc/compiler/dist-newstyle/build/x86_64-linux/ghc-8.5.20180320/ghc-8.5/build/autogen, /home/jojo/build/haskell/ghc/compiler/dist-newstyle/build/x86_64-linux/ghc-8.5.20180320/ghc-8.5/build/global-autogen cabal: repl failed for ghc-8.5. It seems that the stage2/build directory is not registered as a source directory: $ find -name Config.hs ./stage2/build/Config.hs ./stage1/build/Config.hs But if I extend the section if flag(stage2) Include-Dirs: stage2 with these lines Include-Dirs: stage2/build hs-source-dirs: stage2/build ghc-options: -DSTAGE=2 ghc-options: -fobject-code and call cabal like so, it actually works: cabal new-repl -w ../inplace/bin/ghc-stage2 -fstage2 If I now make hdevtools use this line, then hacking on GHC will have a bit less friction… (BTW, does Hadrian have a “load all of GHC in GHCi” mode?) Cheers, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why does SpecConstr run far later than specialisation
Hi, Am Dienstag, den 20.03.2018, 13:23 + schrieb Matthew Pickering: > As far as I understand it, the goals of SpecConstr and specialisation > are the same. One works for > normal value arguments and one works for special type class dictionary > arguments. > > However, looking at the pass order in `SimplCore`, specialisation runs > very early before any major simplification but SpecConstr runs very > late right at the end of the pipeline. > > Does anyone know the justification for this? It seems intuitively that > they should work in the same way. Just a guess: We want the demand analyzer to run before SpecConstr, because I expect that there are many functions where both the demand analyzer are happy to do something, and SpecConstr is happy to do something, but the worker-wrapper done by DmdAnal is strictly preferable (no code duplication, for example.) But the Specializer and the demand analyzer have no overlap, and we we do want to strictness-analyzer the type-class-specialized code. But as I said, it’s just a guess. Cheers, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: An idea for a different style of metaprogramming evaluation using the optimiser
> In my hacked together implementation of this, constant folding happens
too late so only the algebraic version teminated.
ah, very good point!
Joachim
Am 28. Februar 2018 06:26:35 EST schrieb Matthew Pickering
:
>You have identified a small inaccuracy in my original email.
>
>It is true that ultimately 3 == 0 will be evaluated but these constant
>folding opportunities are only applied later after other inlining
>takes place.
>
>It becomes quite crucial under this scheme when different
>optimisations happen because when we inline a recursive function, we
>have to make sure to apply the right evaluation steps before trying to
>simplify the function body.
>In my hacked together implementation of this, constant folding happens
>too late so only the algebraic version teminated.
>
>Cheers,
>
>Matt
>
>On Tue, Feb 27, 2018 at 5:01 PM, Joachim Breitner
> wrote:
>> Hi,
>>
>> something like this would be great. I don’t have a sense yet of what
>> “something” should be like.
>>
>>
>> Am Dienstag, den 27.02.2018, 09:59 + schrieb Matthew Pickering:
>>> To go back to the power example, the recursive
>>> condition would have to be an inductively defined natural (data N =
>Z
>>> | S N) rather than an Int as the comparison operator for integers
>>> can't be evaluated by the optimiser.
>>
>> Sure they can:
>>
>> $ cat ConstantFolding.hs
>> {-# LANGUAGE TemplateHaskell #-}
>> {-# OPTIONS_GHC -fplugin=Test.Inspection.Plugin #-}
>> module ConstantFolding where
>>
>> import Test.Inspection
>>
>> ltInt :: Bool
>> ltInt = (3::Int) > 2
>>
>> ltInteger :: Bool
>> ltInteger = (3::Integer) > 2
>>
>> true :: Bool
>> true = True
>>
>>
>> inspect $ 'ltInt === 'true
>> inspect $ 'ltInteger === 'true
>>
>> $ ghc -O ConstantFolding.hs
>> [1 of 1] Compiling ConstantFolding ( ConstantFolding.hs,
>> ConstantFolding.o )
>> ConstantFolding.hs:17:1: ltInt === true passed.
>> ConstantFolding.hs:18:1: ltInteger === true passed.
>> inspection testing successful
>> expected successes: 2
>>
>>
>>
>> As an alternative with a maybe simpler user interface (and probably
>> less power), I wonder if we can create a magic function
>>> compileTimeWHNF :: a -> a
>> or
>>> compileTimeNF :: a -> a
>> and a GHC core plugin (or eventually built-in thing) that finds these
>> magic functions and evaluates their arguments, using the simplifier.
>>
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>> m...@joachim-breitner.de
>> http://www.joachim-breitner.de/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: An idea for a different style of metaprogramming evaluation using the optimiser
Hi,
something like this would be great. I don’t have a sense yet of what
“something” should be like.
Am Dienstag, den 27.02.2018, 09:59 + schrieb Matthew Pickering:
> To go back to the power example, the recursive
> condition would have to be an inductively defined natural (data N = Z
> | S N) rather than an Int as the comparison operator for integers
> can't be evaluated by the optimiser.
Sure they can:
$ cat ConstantFolding.hs
{-# LANGUAGE TemplateHaskell #-}
{-# OPTIONS_GHC -fplugin=Test.Inspection.Plugin #-}
module ConstantFolding where
import Test.Inspection
ltInt :: Bool
ltInt = (3::Int) > 2
ltInteger :: Bool
ltInteger = (3::Integer) > 2
true :: Bool
true = True
inspect $ 'ltInt === 'true
inspect $ 'ltInteger === 'true
$ ghc -O ConstantFolding.hs
[1 of 1] Compiling ConstantFolding ( ConstantFolding.hs,
ConstantFolding.o )
ConstantFolding.hs:17:1: ltInt === true passed.
ConstantFolding.hs:18:1: ltInteger === true passed.
inspection testing successful
expected successes: 2
As an alternative with a maybe simpler user interface (and probably
less power), I wonder if we can create a magic function
> compileTimeWHNF :: a -> a
or
> compileTimeNF :: a -> a
and a GHC core plugin (or eventually built-in thing) that finds these
magic functions and evaluates their arguments, using the simplifier.
Cheers,
Joachim
--
Joachim Breitner
m...@joachim-breitner.de
http://www.joachim-breitner.de/
signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: testsuite failures in DEBUG
Hi, Am Freitag, den 26.01.2018, 23:23 -0500 schrieb Joachim Breitner: > Am Freitag, den 26.01.2018, 22:53 -0500 schrieb Richard Eisenberg: > > So: would it be possible to have our CI infrastructure validate DEBUG mode > > as well? Then it would be easy to spot where these failures are from. > > unhelpful comment: Travis used to validate with DEBUG, but it no longer > runs the test suite for build time reason. So plausibly we could add a > -DEBUG variant to CircleCI? I now also stumble about the inability to properly test a build built with -DDEBUG. So let me rephrase: Could we please add a -DDEBUG variant to CircleCI? (And then fix the failing tests, or at least mark them as known-to-be- failing on a debugged GHC) Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
https://downloads.haskell.org/~ghc/master/
Hi, just curious: What is the status of https://downloads.haskell.org/~ghc/master/ where I would expect the documentation of GHC HEAD? It seems to be last updated in October, and also be missing the GHC API docs. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: testsuite failures in DEBUG
Hi, Am Freitag, den 26.01.2018, 22:53 -0500 schrieb Richard Eisenberg: > So: would it be possible to have our CI infrastructure validate DEBUG mode as > well? Then it would be easy to spot where these failures are from. unhelpful comment: Travis used to validate with DEBUG, but it no longer runs the test suite for build time reason. So plausibly we could add a -DEBUG variant to CircleCI? Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC builds are broken
Hi, Am Freitag, den 26.01.2018, 22:34 -0500 schrieb Joachim Breitner: > Did anyone observe the segfaults locally? JFTR, neither of perf.haskell.org, Travis CI and CircleCI observe the segfaults. Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC builds are broken
Hi, Am Freitag, den 26.01.2018, 21:49 -0500 schrieb David Feuer: > The Linux build has been failing with a segfault. It looks to me as > though this started with 0e022e56b130ab9d277965b794e70d8d3fb29533: > Turn EvTerm (almost) into CoreExpr. I have seen that, but it seemed to be intermittent. I saw a segfault in the differential revision for that patch, but restarting the build made it go away. Given that this patch is purely a refactoring in the type checker, I believe the problem is somewhere else. Did anyone observe the segfaults locally? Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: pattern signatures
Hi, Am Freitag, den 05.01.2018, 13:42 -0500 schrieb Brandon Allbery: > Further complicated by the fact that that form used to be called a > "pattern signature" with accompanying extension, until that was > folded into ScopedTypeVariables extension. which I find super confusing, because sometimes I want a signature on a pattern and it is counter-intuitive to me why I should not longer use the obviously named PatternSignatures extension but rather the at first glance unrelated ScopedTypeVariable extension. But I am derailing the discussion a bit. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: True multi stage Haskell
Hi Tim, Am Freitag, den 17.11.2017, 13:05 -0500 schrieb Tim Sheard: > After many years of hoping someone else would do this, I would like to > make GHC into a true multi-stage programming language. Here is how I > thought I might approach this. > > 1) Use the GHC as a library module. > 2) Use the LLVM backend. > > I have no experience with either of these tools. > > Lets start simple, How would I write functions like > > compile :: String -> IO PtrToLLVMCode -- where the string is a small > Haskell program. > llvmCompile :: PtrToLLVMCode -> IO PtrToMachineCode > jumpTo:: PtrToMachineCode -> IO ans -- where ans is the "type" of the > string. maybe not quite what you are looking for, but veggies, at https://github.com/nomeata/veggies uses the GHC API build a “new” Haskell compiler with its own Core→LLVM pass. Cheers, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: WIP on combined Step 1 and 3 for Trees That Grow, HsExpr (e3ec2e7)
Hi, > A 15% regression in the compilation time of GHC is indeed hard to stomach but > Alan had said that much of this will likely disappear in the future. great, that’s all I wanted to hear :-) Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [commit: ghc] master: WIP on combined Step 1 and 3 for Trees That Grow, HsExpr (e3ec2e7)
Hi Alan, the combined effect of commit e3ec2e7ae94524ebd111963faf34b84d942265b4 WIP on combined Step 1 and 3 for Trees That Grow, HsExpr and commit 438dd1cbba13d35f3452b4dcef3f94ce9a216905 WIP on Doing a combined Step 1 and 3 for Trees That Grow causes a 15% regression in the time it takes to build GHC, according to https://perf.haskell.org/ghc/#compare/fe6848f544c2a14086bcef388c46f4070c22d287/e3ec2e7ae94524ebd111963faf34b84d942265b4 Is that a known, expected and accepted regression? Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: perf.haskell.org functional again
Hi, Am Sonntag, den 29.10.2017, 23:58 +0100 schrieb Sebastian Graf: > Hi, > > just wanted to throw in the idea of parallelising the benchmark suite > (hurts to even write that, but cachegrind) to speed up the build, if > ever need be. https://github.com/nomeata/gipeda/blob/master/ghc/run-speed.sh#L143 good idea indeed – I’ve been doing that since I started running cachegrind ;-) Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Bringing some observable sharing to GHCi
Hi, Am Sonntag, den 29.10.2017, 16:40 -0400 schrieb David Feuer: > 1. To be able to display cyclical data in some sensible way. > > > x = "hi" : x > > x `seq` () > > :print x > > should print some useful representation of x. the best that I know for this is the hack that calls itself ghc-heap- view: ~ $ cabal install ghc-heap-view ~ $ ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :script .cabal/share/x86_64-linux-ghc-8.0.2/ghc-heap-view-0.5.10/ghci Prelude> x = "hi" : x Prelude> take 2 x ["hi","hi"] Prelude> :printHeap x let x1 = _bh (C# 'h' : _bh (C# 'i' : _bh [])) : _bh x1 in x1 Prelude> System.Mem.performGC Prelude> :printHeap x let x1 = "hi" : x1 in x1 A graphical front-end is ghc-vis: http://felsin9.de/nnis/ghc-vis/ But it is mostly a hack and you should not expect a lot of reliability of it. I’d love to see it supported by GHC proper. Erik de Castro Lopo tried to merge it into GHC, but it seems to be very hard. > 2. To be able to force cyclical data without looping. > > > x = "hi" : x > > :force x > That could be implemented on top of ghc-heap-view. Greetings, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [commit: ghc] wip/float-join-points: Wip on floating join points (128e4c1)
Hi Simon, Am Freitag, den 27.10.2017, 15:24 + schrieb g...@git.haskell.org: > commit 128e4c1ffa29f3dfade7128152c143cd601aaa3a > Author: Simon Peyton Jones > Date: Fri Oct 27 16:20:24 2017 +0100 > > Wip on floating join points do you expect to merge that soon, or can I land Exitification before that? (I’m worried that I have to re-do a lot of performance analysis if the Simplifier suddenly does new things to join points). Blocking for Exitification is: * https://phabricator.haskell.org/D4130 needs to land Or rather, I’d prefer if someone who understands the Simplifier better than I fixes it properly. See https://phabricator.haskell.org/D4130#inline-32243 for bits that I am puzzled about. * I need to understand better why inlining join points in the final simplifier run regresses things. Unless you permit merging Exitification without final inlining even before we completely solve this mystery, on the grounds that - the nofib results say it’s the right thing to do and - there is a plausible theory (exit join points in unfolding enable optimizations in later modules in earlier phases). Greetings, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: wip/nfsl-locking
Hi, Am Freitag, den 27.10.2017, 15:36 + schrieb Simon Peyton Jones via ghc-devs: > Can anyone switch off this torrent of commit messages for wip/nfs-locking? > I’m submerged in junk. > I’m about to write a junk-mail rule I assume that some mailserver has all those mails and is now unerringly working it off, so I am not sure anybody can stop it at this time. Anyways, I have already added a rule to drop these mails… Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Relocatable dist
Hi, right now I’d like to compare the compiler at my feature branch with and without the last commit on that branch. I have a working copy at the end of my feature branch. If the worktree was relocatable, I could now simply `cp -r` the whole worktree, pop the top commit, run `make -C ghc 2` and would be good to go. This would be much more pleasant that the current thing where I have to create a new work tree and rebuild everything from scratch… (Again, nothing constructive in this mail, it's just motivational. Or maybe someone can enlighten me with a better workflow.) Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Simplify.hs depends on typechecker
Hi,
while rebuilding Simplify.o only I noticed that all of the type
checker, and HsSyn stuff, and renamer stuff, and so needed to be
rebuilt, which I found strange.
After a little investigation, it seems that the simplifier depends on
CoreMonad, and that pulls some very few type-checker related things:
1.
import TcRnMonad( initTcForLookup )
import {-# SOURCE #-} TcSplice ( lookupThName_maybe )
for
thNameToGhcName :: TH.Name -> CoreM (Maybe Name)
thNameToGhcName th_name = do
hsc_env <- getHscEnv
liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name)
which is not even used in GHC, but only in GHC Plugins, so this could
probably be moved to a separate module pulled in by GhcPlugins.hs
2.
import TcEnv( lookupGlobal )
for
instance MonadThings CoreM where
lookupThing name = do { hsc_env <- getHscEnv
; liftIO $ lookupGlobal hsc_env name }
This might be a bit harder to disentangle. But if successful, it would
probably make building GHC in parallel quite a bit faster. And it just
seems strange to me that the Core-to-Core code should depend on the
type checker…
I’m sending this out there in case someone has dug in that direction
before and has insights to share.
Greetings,
Joachim
(Attached is a transitively reduced dependency graph of Simplify.hs,
created using Iavor’s https://github.com/yav/graphmod/wiki).
--
Joachim “nomeata” Breitner
m...@joachim-breitner.de
https://www.joachim-breitner.de/
foo.pdf
Description: Adobe PDF document
signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: perf.haskell.org functional again
Hi, Am Dienstag, den 24.10.2017, 16:59 +0200 schrieb Boespflug, Mathieu: > Hi Joachim, > > > But that’s what I am saying: By measuring dynamic instructions (using > > cachegrind), the execution time is no longer relevant. > > I'm skeptical that this metric is a reliable enough proxy for actual > runtime of user programs to make tracking it and only it sufficient. > For the reasons Sven Panne gave in a previous email. But I'll be very > interested to hear your experience report over time. Sure, it’s a crutch. But we have been working for decades with “allocations go down, so this must be a win”, which is even more distant from runtime. If someone builds me a system where the runtime measurements are actually reliable (and not drowned in the noise of modern CPU architectures with sensitivity to layout and alignment), maybe using a tool like this http://plasma.cs.umass.edu/emery/stabilizer.html then I’ll happily ditch instruction counts and use that! But at the current state, working with nofib results is just too frustrating: You see a change, but you don't know, is it a measurement error? Did you push something over a performance cliff? Is it really related to your change to Core? I find it just not viable. Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: perf.haskell.org functional again
Hi, Am Dienstag, den 24.10.2017, 09:57 +0200 schrieb Boespflug, Mathieu: > what kind of machine is this running on at the moment? A dedicated > instance or some colocated VM in the cloud? A physical box sponsored by Bryn Mawr. 8GB RAM, 8 Core Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz > I ask because for perf > results something CircleCI might *not* be suitable here because > execution time on CircleCI varies quite substantially depending on > load from other users of the same physical machine. This is not a > problem for most types of jobs, but perf measurement is one of the few > for which it is, depending on which metrics are tracked. But that’s what I am saying: By measuring dynamic instructions (using cachegrind), the execution time is no longer relevant. Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: perf.haskell.org functional again
Hi, Is CircleCI the future now? In general, yes. But it’s running fine for now, so I would not prematurely throw it over. My requirements are: * needs to run on every commit (not just every push), including branches. * needs to be able to push to a repository¹, so it needs access to some secret token for depolyment. Alternatively, the CI could simply keep track of the build log and the perf.haskell.org dashboard scrapes it from there. * Occasionally, I find that I want to rebuild a fair number of commits that are already in the repository. So a good way to trigger rebuilds would be nice. Greetings, Joachim ¹ https://github.com/nomeata/ghc-speed-logs/commits/master Am Dienstag, den 24.10.2017, 12:18 +1100 schrieb Manuel M T Chakravarty: > Hi Joachim, > > Great! Just because you mention CI infrastructure and our effort around GHC > CI at the moment, do you think, it would make sense to move this to CircleCI > eventually? > > Cheers, > Manuel > > > Am 24.10.2017 um 11:02 schrieb Joachim Breitner : > > > > Hi, > > > > after a system upgrade to avoid weird linker errors, and after some fixes > > in the nofib submodule, http://perf.haskell.org/ghc is running again. > > > > I am collecting instruction counts instead of runtime, because the latter > > was just too often varying too wildly. I hope this will yield less false > > alarms. > > > > I am also running nofib with mode=fast. This way, building GHC, running the > > testsuite and nofib takes a bit over one hour. I hope this can keep up with > > y'all's commits (when it took 2h it couldn't). > > > > Now nothing of the setup requires a quiet dedicated machine, so if there is > > a need, we could move these builds into the cloud or into some CI > > infrastructure - but no changes are immediately planned. > > > > Enjoy, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
perf.haskell.org functional again
Hi, after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again. I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms. I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't). Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned. Enjoy, Joachim ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC HEAD now needs extra tools to build libffi?
Hi, Am Montag, den 23.10.2017, 20:49 +0800 schrieb Moritz Angermann: > I still can’t make sense of this. Is your gold a different version now as > well? It is “GNU gold (GNU Binutils 2.29.1) 1.14” now, and it seems it was upgraded: [2017-10-22 16:58] [ALPM] upgraded binutils (2.27-1 -> 2.29.1-1) Here is the full build log: https://raw.githubusercontent.com/nomeata/ghc-speed-logs/master/052ec24412e285aa34911d6187cc2227fc7d86d9.log Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC HEAD now needs extra tools to build libffi?
Hi, JFTR, upgrading the Arch installation, including ghc to 8.2.1, fixes the issue for perf.haskell.org. Greetings, Joachim Am Donnerstag, den 19.10.2017, 16:28 +0800 schrieb Moritz Angermann: > Hi, > > As it turns out this might be linker madness. I do not yet understand why > this did work with > the "old" libffi though. > > The command that fails is a rather long gcc invocation asking it to link a > bunch of libraries together. > > $ gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-fuse-ld=gold' [...] > -lHSghci-8.3-ghc8.3.20171018 [...] -lffi [...] > > From the error message, we know taht ghci depends on libffi. E.g. > > > libHSghci-8.3-ghc8.3.20171018.so: error: undefined reference to > > 'ffi_prep_cif' > > Now there are two possible configurations that do (successfully) link on my > test machine: > > 1.) Droppping `-fuse-ld=gold`. > 2.) Moving `-lffi` prior to `-lHSghci-8.3-ghc8.3.20171018`. > > I guess we could also add the libffi symbols the the other -Wl,-u,... symbols. > > Obviously I would not see this on macOS, as there is no go.ld on macOS. On my > ubuntu system, gold is > > GNU gold (GNU Binutils for Ubuntu 2.27) 1.12 > > Again, as I stated in the beginning, I fail to understand why this should > related to the new libffi version. > > As such running `LD=ld ./configure && make -j` does indeed complete > successfully on my machine. > > If someone has any idea what the core issue between the libffi update and > these build failures is, I'd be happy > to know! > > Cheers, > Moritz > > > On Oct 18, 2017, at 11:38 PM, Joachim Breitner > > wrote: > > > > Hi, > > > > it’s an Arch linux (generously sponsored by Richard’s university). I > > have not idea how to give more precise information about the distro > > release version or such :-) > > > > Greetings, > > Joachim > > > > Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann: > > > Hi, > > > > > > so this somehow looks like for a not yet absolutely clear reason to me, > > > when building ghci, we fail to link in libffi, for some configurations. > > > > > > Joachim, as far as I could see, you are using ghc 8.0.1 to boostrap the > > > compiler. Thomas are you by any chance bootstrapping with 8.0.1 as well? > > > I assume Ben bootstraps wit 8.2.1. > > > > > > I'll set up a Ubuntu 16.10 machine tomorrow and try to reproduce this. > > > > > > Joachim, is perf.haskell.org running Ubuntu as well? > > > > > > Cheers, > > > Moritz > > > > > > > On Oct 11, 2017, at 1:43 AM, Thomas Jakway wrote: > > > > > > > > Thanks for getting back to me. > > > > > > > > (I think you mean `git clean -x -f -d`): I usually omit -x but I'll > > > > give it a go and report back. > > > > > > > > Before I got the issue on a clean checkout I thought it was something I > > > > did to the build files. > > > > > > > > I also tried building the latest release of libffi (v3.2.1) and using > > > > it in configure with --with-ffi-includes and --with-ffi-libraries but > > > > got the same error. > > > > > > > > > > > > On 10/09/2017 02:40 AM, Moritz Angermann wrote: > > > > > Yes, this commit indeed introduced the need for makeinfo, however > > > > > after some debugging and improved packaging of the external libffi > > > > > library, this dependency was removed again, and should not be > > > > > required with the latest head anymore. > > > > > > > > > > Then again this should not result in link issues but rather in build > > > > > time issues. > > > > > > > > > > The key to libffi is the libffi-tarballs git submodule, which > > > > > contains the packaged libffi-tarballs. Make sure all your submodules > > > > > are also updated. > > > > > > > > > > I usually use `git -x -f -d` (read the documentation first) to ensure > > > > > a clean working tree. Especially as you say you can’t reproduce it on > > > > > other machines, maybe there is a file in your tree that the cleaning > > > > > did not catch? > > > > > > > > > > Sent from my iPhone > > > > > > > > > > > On 9 Oct 2017, at 4:31 AM, Thomas Jakway wrote: > > &
Re: Is stage-1 sufficient to run nofib
Hi, Am Sonntag, den 22.10.2017, 23:14 -0400 schrieb Joachim Breitner: > Am Sonntag, den 22.10.2017, 22:23 -0400 schrieb Edward Z. Yang: > > Yes, but you still need to build the libraries, so the speed up > > will not be as much as you might hope. > > sure, but when you build every GHC commit, then even a small > improvement is nice. > > Do you know the proper way of building only libraries + ghc-stage1? nevermind, perf.haskell.org also measures compiler performances (in the test suite), so I need stage2. Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Relocatable dist
Hi, Am Montag, den 23.10.2017, 14:04 +0800 schrieb Moritz Angermann: > I've come wonder, how hard it could be to > make GHC relocatable. (e.g. just unpack the distribution, > and use the compiler from the `bin` folder within). Yes yes yes please! (Sorry for not contributing anything but motivation.) Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Is stage-1 sufficient to run nofib
Hi Edward, Am Sonntag, den 22.10.2017, 22:23 -0400 schrieb Edward Z. Yang: > Yes, but you still need to build the libraries, so the speed up > will not be as much as you might hope. sure, but when you build every GHC commit, then even a small improvement is nice. Do you know the proper way of building only libraries + ghc-stage1? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Is stage-1 sufficient to run nofib
Hi, I guess I could just try it, but maybe someone knows it, or knows what would go wrong… If I run nofib with ghc-stage1 instead of ghc-stage2, I should get the same results, right? (ignoring compilation times here) My hope is that it can speed up perf.haskell.org some more. Greetings, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC HEAD now needs extra tools to build libffi?
Hi, it’s an Arch linux (generously sponsored by Richard’s university). I have not idea how to give more precise information about the distro release version or such :-) Greetings, Joachim Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann: > Hi, > > so this somehow looks like for a not yet absolutely clear reason to me, > when building ghci, we fail to link in libffi, for some configurations. > > Joachim, as far as I could see, you are using ghc 8.0.1 to boostrap the > compiler. Thomas are you by any chance bootstrapping with 8.0.1 as well? > I assume Ben bootstraps wit 8.2.1. > > I'll set up a Ubuntu 16.10 machine tomorrow and try to reproduce this. > > Joachim, is perf.haskell.org running Ubuntu as well? > > Cheers, > Moritz > > > On Oct 11, 2017, at 1:43 AM, Thomas Jakway wrote: > > > > Thanks for getting back to me. > > > > (I think you mean `git clean -x -f -d`): I usually omit -x but I'll give it > > a go and report back. > > > > Before I got the issue on a clean checkout I thought it was something I did > > to the build files. > > > > I also tried building the latest release of libffi (v3.2.1) and using it in > > configure with --with-ffi-includes and --with-ffi-libraries but got the > > same error. > > > > > > On 10/09/2017 02:40 AM, Moritz Angermann wrote: > > > Yes, this commit indeed introduced the need for makeinfo, however after > > > some debugging and improved packaging of the external libffi library, > > > this dependency was removed again, and should not be required with the > > > latest head anymore. > > > > > > Then again this should not result in link issues but rather in build time > > > issues. > > > > > > The key to libffi is the libffi-tarballs git submodule, which contains > > > the packaged libffi-tarballs. Make sure all your submodules are also > > > updated. > > > > > > I usually use `git -x -f -d` (read the documentation first) to ensure a > > > clean working tree. Especially as you say you can’t reproduce it on other > > > machines, maybe there is a file in your tree that the cleaning did not > > > catch? > > > > > > Sent from my iPhone > > > > > > > On 9 Oct 2017, at 4:31 AM, Thomas Jakway wrote: > > > > > > > > I'm on Ubuntu 16.10. > > > > > > > > I ran git bisect: > > > > > > > > -- > > > > > > > > e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit > > > > commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 > > > > Author: Moritz Angermann > > > > Date: Sat Sep 30 09:31:12 2017 -0400 > > > > > > > > Allow libffi snapshots > > > > > > > > This is rather annoying. I'd prefer to have a stable release to > > > > use. However libffi-3.2.1 has been released November 12, 2014, and > > > > libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296 > > > > > > > > The core reason for this change is that llvm changed the supported > > > > assembly to unified syntax, which libffi-3.2.1 does not use, and hence > > > > fails to compile for arm with llvm. For refence, see the following > > > > issue: https://github.com/libffi/libffi/issues/191. > > > > > > > > This diff contains a script to generate a tarball for the > > > > `libffi-tarballs` repository from the libffi GitHub repository; as well > > > > as the necessary changes to the build system. > > > > > > > > Updates libffi-tarballs submodule. > > > > > > > > Reviewers: austin, bgamari, hvr > > > > > > > > Subscribers: hvr, erikd, rwbarton, thomie > > > > > > > > Differential Revision: https://phabricator.haskell.org/D3574 > > > > > > > > -- > > > > > > > > I can't reproduce it on my other linux computers though. > > > > > > > > > > > > > On 10/04/2017 02:17 PM, Ben Gamari wrote: > > > > > Thomas Jakway writes: > > > > > > > > > > > Anyone else getting linker errors? > > > > > > > > > > > > This is after running > > > > > > > > > > > > make clean && make distclean && find . -name "*.o" -type f -delete > > > > >
Re: GHC HEAD now needs extra tools to build libffi?
Hi, Am Dienstag, den 03.10.2017, 13:55 -0400 schrieb Thomas Jakway: > Anyone else getting linker errors? > > /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3. > 20171003.so: error: undefined reference to 'ffi_type_uint64' > chmod +x > inplace/bin/runghc > /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3. > 20171003.so: error: undefined reference to 'ffi_type_uint32' … I can confirm these. Looks like perf.haskell.org is stuck on that problem. Thomas, did you resolve that issue? Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: CircleCI (Was: Disable Travis?)
Hi, Am Donnerstag, den 28.09.2017, 17:46 -0400 schrieb Richard Eisenberg: > I just tried to get on board this new train. But I can't seem to > figure out how to "follow" ghc. I signed up through my GitHub > account, but CircleCI doesn't seem to want me to follow an open- > source project with which I have no formal association in GitHub. > Joachim, it seemed you unlocked this capability. How? It'd be lovely > to get notifications of builds on ghc's wip/rae branch, in > particular. it seems that one cannot simply make CircleCI notify the committer that broke something: https://discuss.circleci.com/t/automatic-email-notifications-to-the-author-of-a-broken-commit/519/12 The summary seems to be: * only CircleCI users can sign up for notifications, and they have to so actively (and it’s non trivial, judging from Richard’s struggle) * Even then, the only options are: “Send me a personalized email for every build in my projects.” which certainly too much spam and “Send me a personalized email every time a build on a branch I've pushed to fails; also once they're fixed.” which might be what most people want. It is not clear how I can get a mail when someone else broke master… Well, eventually we will have Jenkins and All Is Well™. Greetings, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: perf.haskell.org update: Now using cachegrind
Hi, update ton this: Am Freitag, den 22.09.2017, 09:06 -0400 schrieb Joachim Breitner: > I have switched perf.haskell.org to run nofib with > $ make -C nofib EXTRA_RUNTEST_OPTS=-cachegrind NoFibRuns=1 mode=slow -j8 it looks like this will not work out, with the current setup; perf.haskell.org has failed to catch up with the number of commits coming in. I’ll see if there are some low-hanging fruits to speed this up, such as not building haddocks. I also wonder whether, when using cachegrind, the results from different machines are actually comparable. Maybe I’ll try that some day. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: CircleCI (Was: Disable Travis?)
Hi, Am Montag, den 25.09.2017, 13:36 +0200 schrieb Boespflug, Mathieu: > Can you configure circleci to mail both the committeer and a specific > person (e.g. you, or me) on every failed committ? > > That's a good question. The way things work in CircleCI is that this > is a user setting. You can go to > > https://circleci.com/account/notifications > > and "subscribe" to notifications on a per-organization or per-project basis. ok, so it seems that I can ensure I get mail. Do you know if there is a way to notify the committer, even if the committer is not a CircleCI user? > Regarding the resource_class setting, that's a feature CircleCI > graciously enabled for tweag/ghc. I could do the same request for the > ghc/ Github org. But better if it's an admin of the org. Even without this, it often runs in 40mins, and sometimes takes an hour. So for now, I’ll just let it run like this. Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RTS changes affect runtime when they shouldn’t
Hi, Am Samstag, den 23.09.2017, 20:45 +0200 schrieb Sven Panne: > 2017-09-21 0:34 GMT+02:00 Sebastian Graf : > > [...] The only real drawback I see is that instruction count might > > skew results, because AFAIK it doesn't properly take the > > architecture (pipeline, latencies, etc.) into account. It might be > > just OK for the average program, though. > > > > It really depends on what you're trying to measure: The raw > instruction count is basically useless if you want to have a number > which has any connection to the real time taken by the program. The > average number of cycles per CPU instruction varies by 2 orders of > magnitude on modern architectures, see e.g. the Skylake section in ht > tp://www.agner.org/optimize/instruction_tables.pdf (IMHO a must-read > for anyone doing serious optimizations/measurements on the assembly > level). And these numbers don't even include the effects of the > caches, pipeline stalls, branch prediction, execution units/ports, > etc. etc. which can easily add another 1 or 2 orders of magnitude. > > So what can one do? It basically boils down to a choice: > >* Use a stable number like the instruction count (the > "Instructions Read" (Ir) events), which has no real connection to the > speed of a program. > >* Use a relatively volatile number like real time and/or cycles > used, which is what your users will care about. If you put a non- > trivial amount of work into your compiler, you can make these numbers > a bit more stable (e.g. by making the code layout/alignment more > stable), but you will still get quite different numbers if you switch > to another CPU generation/manufacturer. > > A bit tragic, but that's life in 2017... :-} what I want to do is to reliably catch regressions. What are the odds that a change to the Haskell compiler (in particular to Core2Core transformations) will cause a significant increase in runtime without a significant increase in instruction count? (Honest question, not rhetoric). Greetings, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
perf.haskell.org update: Now using cachegrind
Hi, I have switched perf.haskell.org to run nofib with $ make -C nofib EXTRA_RUNTEST_OPTS=-cachegrind NoFibRuns=1 mode=slow -j8 Right now, a complete build with testsuite and nofib takes ~2½h, but that was before I added the "-j8" to the line above, so let’s see if that helps. Even with cachegrind, most nofib tests finish in under one minute, 7 take between one and 10 minutes, k-nucleotide needs 20 minutes and fannkuch-redux needs 27 minutes. All in all not too bad. I reset the perf.haskell.org database and started re-measuring commits from 055d73c6576bed2affaf96ef6a6b89aeb2cd2e9f on. It will take a while (a week maybe?) for it to catch up with master. I hope that this allows us to spot performance regressions with greater precision. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
CircleCI (Was: Disable Travis?)
Hi, Am Donnerstag, den 21.09.2017, 14:25 +0200 schrieb Boespflug, Mathieu: > It took me no more than a couple hours to get this working, but using > CircleCI, for our fork of GHC. I started from Joachim's TravisCI > script. > > https://circleci.com/gh/tweag/ghc/tree/circleci > > It would be trivial to activate this for github.com/ghc/ghc as well. > > A few notes: > - It runs ./validate --fast in 40 minutes. > - CircleCI has OS X support as well. I think we should just migrate > to > using CircleCI for OS X testing instead of the custom drones, one or > all of which are currently down. > - CircleCI graciously agreed to running on one of the beefy AWS node > types, called c4.xlarge (8 cores). On the standard node type (2 > cores), validate takes just over an hour to run. It would be great if > ./validate could scale better to more cores. nice! Yes, let’s do this. More CI never hurts (if someone keeps an eye on it and fixes breakage that is not due to the code). Can you configure circleci to mail both the committeer and a specific person (e.g. you, or me) on every failed committ? I enabled it now for ghc/ghc, but it says > Configurable resource class is not enabled in your project. Please > contact your CSM person or our support team to whitelist your > project. Can you do that? Greetings, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RTS changes affect runtime when they shouldn’t
Hi, Am Donnerstag, den 21.09.2017, 00:34 +0200 schrieb Sebastian Graf: > Hi, > > > I did it for my thesis and I found it ok. I mean I always sent it off > > to some machine and looked at the results later, so I did not really > > care whether it took 30mins or 2h. > > I did the same for my thesis (the setup of which basically was a rip- > off of Joachim's) and it was really quite bearable. I think it was > even faster than doing NoFibRuns=30 without counting instructions. > > The only real drawback I see is that instruction count might skew > results, because AFAIK it doesn't properly take the architecture > (pipeline, latencies, etc.) into account. It might be just OK for the > average program, though. I’ll try that now, and see if I like the results better. It might take a few iterations to find the right settings, so perf.haskell.org might not update quickly for now. Greetings, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: RTS changes affect runtime when they shouldn’t
Hi Am Mittwoch, den 20.09.2017, 14:33 -0400 schrieb Ben Gamari: > Note that valgrind can also do cache modelling so I suspect it can give > you a reasonably good picture of execution; certainly better than > runtime. However, the trade-off is that (last I checked) it's incredibly > slow. Don't you think I mean just a bit less peppy than usual. I mean > soul-crushingly, mollasses-on-a-cold-December-morning slow. > > If we think that we can bear the cost of running valigrind then I think > it would be a great improvement. As you point out, the current run times > are essentially useless. I did it for my thesis and I found it ok. I mean I always sent it off to some machine and looked at the results later, so I did not really care whether it took 30mins or 2h. I think I’ll try it in perf.haskell.org and see what happens. Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RTS changes affect runtime when they shouldn’t
Hi, while keeping an eye on the performance numbers, I notice a pattern where basically any change to the rts makes some benchmarks go up or down by a significant percentage. Recent example: https://git.haskell.org/ghc.git/commitdiff/0aba999f60babe6878a1fd2cc8410139358cad16 which exposed an additional secure modular power function in integer (and should really not affect any of our test cases) causes these changes: Benchmark name prevchange now nofib/time/FS 0.434 - 4.61%0.414 seco nds nofib/time/VS 0.369 + 15.45%0.426 seco nds nofib/time/scs 0.411 - 4.62%0.392 sec onds https://perf.haskell.org/ghc/#revision/0aba999f60babe6878a1fd2cc8410139 358cad16 The new effBench benchmarks (FS, VS) are particularly often affected, but also old friends like scs, lambda, integer… In a case like this I can see that the effect is spurious, but it really limits our ability to properly evaluate changes to the compiler – in some cases it makes us cheer about improvements that are not really there, in other cases it makes us hunt for ghosts. Does anyone have a solid idea what is causing these differences? Are they specific to the builder for perf.haskell.org, or do you observe them as well? And what can we do here? For the measurements in my thesis I switched to measuring instruction counts (using valgrind) instead. These are much more stable, requires only a single NoFibRun, and the machine does not have to be otherwise quiet. Should I start using these on perf.haskell.org? Or would we lose too much by not tracking actual running times any more? Greetings, Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
nofib behind master?
Hi, nofib currently does not build (and hence perf.haskell.org is broken), du to the Monoid-Semigroup-Change. I looked into it and found that nofib, as refernced by ghc HEAD, is 26 commits behind nofib master. Ben, you did some of those commits. Any good reason not to update the submodule in ghc? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Disabling Travis?
Hi Richard, I saw you tried to get Travis working again. I also gave it a quick shot (in wip/travis2), but hit time limits again. Did you have more luck? Greetings, Joachim Am Montag, den 21.08.2017, 23:17 -0400 schrieb Richard Eisenberg: > I have not been getting emails from Travis, despite using it for > other projects (and thus being registered). So perhaps something is > going wrong there. Regardless, it's useful for me, even without the > emails. > > Another nice thing about Travis: I can get a quick check of the > history of failures, even in DEBUG mode. > > Richard > > > On Aug 21, 2017, at 3:54 AM, Joachim Breitner > r.de> wrote: > > > > Hi, > > > > Am Sonntag, den 20.08.2017, 23:55 -0400 schrieb Richard Eisenberg: > > > The big minus to Travis, as I see it, are that only committers > > > can > > > use it. (A forked repo just doesn't work because of the way that > > > submodules are checked out, IIRC.) This minus doesn't affect me, > > > however. > > > > I think the biggest minus is that Travis can either be configured > > to > > send mails to one specific address (as it was initially, when I > > received all the mail and could check whether I want to notify the > > author), or to the author of the patch, but not both. Currently it > > is > > sent to notify the author, but people seem to simply ignore the > > mails. > > > > (Or maybe even only authors who also registered on travis get > > them?) > > > > So if there is demand to keep using Travis, maybe we have to go > > back to > > sending notification mails to one person who oversees this service? > > > > Joachim > > > > > > > > -- > > Joachim Breitner > > m...@joachim-breitner.de > > http://www.joachim-breitner.de/ > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Disabling Travis?
Hi, Am Sonntag, den 20.08.2017, 23:55 -0400 schrieb Richard Eisenberg: > The big minus to Travis, as I see it, are that only committers can > use it. (A forked repo just doesn't work because of the way that > submodules are checked out, IIRC.) This minus doesn't affect me, > however. I think the biggest minus is that Travis can either be configured to send mails to one specific address (as it was initially, when I received all the mail and could check whether I want to notify the author), or to the author of the patch, but not both. Currently it is sent to notify the author, but people seem to simply ignore the mails. (Or maybe even only authors who also registered on travis get them?) So if there is demand to keep using Travis, maybe we have to go back to sending notification mails to one person who oversees this service? Joachim -- Joachim Breitner m...@joachim-breitner.de http://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Disabling Travis?
Hi, I wasn’t looking for a while I notice that the travis CI build of GHC has not been succeeding for two months, partly because build time exceeded the already much extended limits we have, partly because support for booting with 7.10 was dropped, but the .travis file was not used. A CI system that is not normally succeeding is pretty pointless, and will only confuse people who submit pull requests over GitHub who see failures. So if noone complains now I will soon disable building on Travis. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
