vectorisation code?

[Geoffrey Mainland]

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.

Geoff

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.
>
> Simon
>
> |  -----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
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>