vectorisation code?

[Simon Peyton Jones]

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