mainland at apeiron.net
Fri Jan 22 16:23:18 UTC 2016
I didn't mean to suggest that DPH should be part of every build, just
that it should be part of *some* regular build.
If we're willing to do that, then I'm certainly willing to get DPH back
up and running.
On 01/22/2016 11:13 AM, Simon Peyton Jones wrote:
> Making it part of *every* validate is a big ask because it takes so long to build.
> But we already have "sh validate --slow", which runs a lot more tests than --fast. So maybe it could be part of --slow?
> And I do think that we should have a nightly build (although perhaps not the continuous-integration build-every-commit stuff) that runs the full testsuite. I don't think that happens right now. But it should.
> That might resolve the "painful to add DPH to validate" problem.
> | -----Original Message-----
> | From: Geoffrey Mainland [mailto:mainland at apeiron.net]
> | Sent: 22 January 2016 14:58
> | To: Thomas Miedema <thomasmiedema at gmail.com>
> | Cc: Ben Gamari <ben at well-typed.com>; Manuel M T Chakravarty
> | <chak at cse.unsw.edu.au>; Simon Peyton Jones <simonpj at microsoft.com>;
> | ghc-devs at haskell.org
> | Subject: Re: vectorisation code?
> | On Fri, Jan 22, 2016 at 03:23:56PM +0100, Thomas Miedema wrote:
> | > On Fri, Jan 22, 2016 at 3:17 PM, Geoffrey Mainland
> | <mainland at apeiron.net> wrote:
> | >> On 1/22/16 8:05 AM, Ben Gamari wrote:
> | >>> Manuel M T Chakravarty <chak at cse.unsw.edu.au> writes:
> | >>>> The way I see it, the main cost of keeping DPH around is to
> | handle
> | >>>> breakages such as that with vector. I can't promise to address
> | >>>> those in a timely manner, which is why I agreed to disable/remove
> | DPH.
> | >>>> However, as Geoff stepped forward, this issue is solved. As for
> | the
> | >>>> overhead in compile time etc, I don't think, it is that much of a
> | >>>> deal. During development, most compiles runs are incremental
> | anyway.
> | >>>
> | >>> Judging by the VCS history it seems that nothing happened in
> | >>> response to this thread. Geoff, do you see yourself having time to
> | >>> pick this up in the near future? If not, perhaps we should pick up
> | >>> this matter again and seriously consider parking this code in a
> | >>> branch until someone is able to pick it up again.
> | >>> Cheers,
> | >>> - Ben
> | >>
> | >> Yes, I am willing to do the work to get DPH back into the build in
> | >> the near future. However, that only makes sense if we are willing
> | to
> | >> build DPH regularly. Also, I can't be solely responsible for all
> | >> breakage resulting from DPH; DPH has regularly exposed bugs in the
> | >> past, which is one reason to get it back into the regular build,
> | but
> | >> I can't promise to fix all problems that might be exposed by DPH in
> | >> the future :)
> | >>
> | >> If I put a patch on Phab that updates DPH, are we willing to make
> | DPH
> | >> part of the regular validation script again?
> | >>
> | >> Cheers,
> | >> Geoff
> | >
> | > We could make all of hackage be part of the ghc build, and it would
> | > turn up bugs. But we don't do that either. Why is dph special?
> | Manuel and Simon can say more, but DPH has in the past been very good
> | at exposing, for example, regressions in the inliner. It exercises GHC
> | in a way that few other packages do.
> | DPH is intimately tied to GHC, so it's not something that can be
> | maintained separately as a package. If we aren't willing to make DPH
> | part of the regular build, then it will just bitrot again quickly, and
> | there's little point in doing the work to get it running again.
> | I'm of the opinion that DPH still has value and that it would be a
> | shame to lose it forever, which is effectively what will happen if we
> | relegate the vectorizer to a branch. I am willing to get DPH working
> | again, but only if there is general agreement that DPH is worth
> | having---and that we are willing to once again make it part of the
> | regular build.
> | Geoff
> ghc-devs mailing list
> ghc-devs at haskell.org
More information about the ghc-devs