Hi Austin, I haven't heard back from you about this, and D302 has been waiting for review in phab for two weeks. This seems to be a minor change, so if I don't hear otherwise by the end of the week, I'm going to go ahead and merge.
Thanks, Geoff On 08/29/2014 01:29 PM, Geoffrey Mainland wrote: > Hi Austin, > > I've pushed wip/dph-fix branches to the dph and ghc repos. dph is not in > Phabricator, so I didn't submit anything for review. I think this is > small enough that we can probably just merge it directly, but it would > be nice to have DPH in Phabricator eventually. > > I only validated on Linux x64. Is there an easy way for me to validate > on other platforms? > > Thanks, > Geoff > > On 08/04/2014 10:07 AM, Austin Seipp wrote: >> On Mon, Aug 4, 2014 at 8:49 AM, Geoffrey Mainland <mainl...@apeiron.net> >> wrote: >>> I have patches for DPH that let it work with vector 0.11 as of a few >>> months ago. I would be happy to submit them via phabricator if that is >>> agreeable (we have to coordinate with the import of vector 0.11 >>> though...I can instead leave them in a wip branch for Austin to merge as >>> he sees fit). I am also willing to commit some time to keep DPH at least >>> working in its current state. >> That would be quite nice if you could submit patches to get it to >> work! Thanks so much. >> >> As we've moved to submodules, having our own forks is becoming less >> palatable; we'd like to start tracking upstream closely, and having >> people submit changes there first and foremost. This creates a bit of >> a lag time between changes, but I think this is acceptable (and most >> of our maintainers are quite responsive to GHC needs!) >> >> It's also great you're willing to help maintain DPH a bit - but based >> on what Ben said, it seems like a significant rewrite will happen >> eventually. >> >> Geoff, here's my proposal: >> >> 1) I'll disable DPH for right now, so it won't pop up during >> ./validate. This will probably happen today. >> 2) We can coordinate the update of vector to 0.11, making it track >> the official master. (Perhaps an email thread or even Skype would >> work) >> 3) We can fix DPH at the same time. >> 4) Afterwords, we can re-enable it for ./validate >> >> If you submit Phabricator patches, that would be fantastic - we can >> add the DPH repository to Phabricator with little issue. >> >> In the long run, I think we should sync up with Ben and perhaps Simon >> & Co to see what will happen long-term for the DPH libraries. >> >>> Geoff >>> >>> On 8/4/14 8:18 AM, Ben Lippmeier wrote: >>>> On 4 Aug 2014, at 21:47 , Austin Seipp <aus...@well-typed.com> wrote: >>>> >>>>> Why? Because I'm afraid I just don't have any more patience for DPH, >>>>> I'm tired of fixing it, and it takes up a lot of extra time to build, >>>>> and time to maintain. >>>> I'm not going to argue against cutting it lose. >>>> >>>> >>>>> So - why are we still building it, exactly? >>>> It can be a good stress test for the simplifier, especially the SpecConstr >>>> transform. The fact that it takes so long to build is part of the reason >>>> it's a good stress test. >>>> >>>> >>>>> [1] And by 'speak up', I mean I'd like to see someone actively step >>>>> forward address my concerns above in a decisive manner. With patches. >>>> I thought that in the original conversation we agreed that if the DPH code >>>> became too much of a burden it was fine to switch it off and let it become >>>> unmaintained. I don't have time to maintain it anymore myself. >>>> >>>> The original DPH project has fractured into a few different research >>>> streams, none of which work directly with the implementation in GHC, or >>>> with the DPH libraries that are bundled with the GHC build. >>>> >>>> The short of it is that the array fusion mechanism implemented in DPH >>>> (based on stream fusion) is inadequate for the task. A few people are >>>> working on replacement fusion systems that aim to solve this problem, but >>>> merging this work back into DPH will entail an almost complete rewrite of >>>> the backend libraries. If it the existing code has become a maintenance >>>> burden then it's fine to switch it off. >>>> >>>> Sorry for the trouble. >>>> Ben. >>>> >> _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
