Re: vectorisation code?
Geoffrey Mainland writes: > Hi Ben, > > Progress is stalled on a rewrite of DPH's use of TH since TH is no > longer available in stage1. There is no reason this can't be worked > around, just that it's more work than I initially expected. > > I agree that it would be good to get this taken care of soon, but that > is generically true of almost all things :) I was planning on getting > this done for 8.2. If there is a reason for more urgency, let's discuss. > Hi Geoff, Hsa there been any news here? It would be great if we could have this taken care of by mid-October or so; the time right before a new release is always quite busy so the more things we can handle earlier the better. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
Ben Gamari writes: > Geoffrey Mainland writes: > >> Hi Ben, >> Hi Geoff, >> Progress is stalled on a rewrite of DPH's use of TH since TH is no >> longer available in stage1. There is no reason this can't be worked >> around, just that it's more work than I initially expected. >> > Alright, thanks for the update Geoff! > Any news on this front? 8.2 isn't imminent but it's certainly on the horizon so it would be good to get this taken care of in the next month or so. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
Geoffrey Mainland writes: > On 05/11/2016 11:28 AM, Ben Gamari wrote: >> Geoffrey Mainland writes: >> >>> Yes, I will take this on, but it may take a few months to happen. >>> >> Hi Geoff, >> >> Has there been any motion on this front? >> >> It would be great if we could get this taken care of soon. >> >> Cheers, >> >> - Ben >> > > Hi Ben, > > Progress is stalled on a rewrite of DPH's use of TH since TH is no > longer available in stage1. There is no reason this can't be worked > around, just that it's more work than I initially expected. > Alright, thanks for the update Geoff! > I agree that it would be good to get this taken care of soon, but that > is generically true of almost all things :) I was planning on getting > this done for 8.2. If there is a reason for more urgency, let's discuss. > There's nothing terribly urgent, although it would be nice just to get this sorted out. Out of curiosity is there a branch posted somewhere for those of us who want to play along at home? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
On 05/11/2016 11:28 AM, Ben Gamari wrote: > Geoffrey Mainland writes: > >> On 01/26/2016 12:00 PM, Ben Gamari wrote: >> >>> We discussed this in today's meeting. The consensus seems to be that >>> this is worth doing; let's make it happen. >>> >>> As I mentioned yesterday, I would be happy to provide the infrastructure >>> necessary to produce full testsuite results on a nightly basis. I >>> already do nightly builds and setting up some sort of monitoring is >>> something that I've been meaning to do for some time now. >>> >>> Geoff, could you brush the cob-webs off of the vectoriser and post a >>> patch to Phabricator? >>> >>> Cheers, >>> >>> - Ben >>> >> Yes, I will take this on, but it may take a few months to happen. >> > Hi Geoff, > > Has there been any motion on this front? > > It would be great if we could get this taken care of soon. > > Cheers, > > - Ben > Hi Ben, Progress is stalled on a rewrite of DPH's use of TH since TH is no longer available in stage1. There is no reason this can't be worked around, just that it's more work than I initially expected. I agree that it would be good to get this taken care of soon, but that is generically true of almost all things :) I was planning on getting this done for 8.2. If there is a reason for more urgency, let's discuss. Cheers, Geoff ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
Geoffrey Mainland writes: > On 01/26/2016 12:00 PM, Ben Gamari wrote: > >> We discussed this in today's meeting. The consensus seems to be that >> this is worth doing; let's make it happen. >> >> As I mentioned yesterday, I would be happy to provide the infrastructure >> necessary to produce full testsuite results on a nightly basis. I >> already do nightly builds and setting up some sort of monitoring is >> something that I've been meaning to do for some time now. >> >> Geoff, could you brush the cob-webs off of the vectoriser and post a >> patch to Phabricator? >> >> Cheers, >> >> - Ben >> > > Yes, I will take this on, but it may take a few months to happen. > Hi Geoff, Has there been any motion on this front? It would be great if we could get this taken care of soon. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
On 01/26/2016 12:00 PM, Ben Gamari wrote: Geoffrey Mainland writes: 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. We discussed this in today's meeting. The consensus seems to be that this is worth doing; let's make it happen. As I mentioned yesterday, I would be happy to provide the infrastructure necessary to produce full testsuite results on a nightly basis. I already do nightly builds and setting up some sort of monitoring is something that I've been meaning to do for some time now. Geoff, could you brush the cob-webs off of the vectoriser and post a patch to Phabricator? Cheers, - Ben Yes, I will take this on, but it may take a few months to happen. Cheers, Geoff ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
Geoffrey Mainland writes: > 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. > We discussed this in today's meeting. The consensus seems to be that this is worth doing; let's make it happen. As I mentioned yesterday, I would be happy to provide the infrastructure necessary to produce full testsuite results on a nightly basis. I already do nightly builds and setting up some sort of monitoring is something that I've been meaning to do for some time now. Geoff, could you brush the cob-webs off of the vectoriser and post a patch to Phabricator? Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: vectorisation code?
Simon Peyton Jones writes: > 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. > Indeed that sounds reasonable. I have a cronjob which performs a nightly build and testsuite run anyways. As a start I can make these logs publicly available and ensure that I get notified when the build breaks. In the longer term I hope we can get some integration with Phabricator, although if I'm not mistaken this isn't yet possible. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
On 1/22/16 11:36 AM, Herbert Valerio Riedel wrote: > On 2016-01-22 at 17:23:18 +0100, Geoffrey Mainland wrote: >> 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. > What's the situation with the `vector`/`primitive` packages if DPH is to > be resuscitated? Does the official `vector` package need to be made > DPH-aware? > The vector and primitive packages will not need to be changed in any significant way, and perhaps not at all. It's possible we might need a few patches to vector to, e.g., expose a data constructor somewhere, so I can't promise that we will need zero changes. Geoff ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
On 2016-01-22 at 17:23:18 +0100, Geoffrey Mainland wrote: > 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. What's the situation with the `vector`/`primitive` packages if DPH is to be resuscitated? Does the official `vector` package need to be made DPH-aware? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
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:mainl...@apeiron.net] | Sent: 22 January 2016 14:58 | To: Thomas Miedema | Cc: Ben Gamari ; Manuel M T Chakravarty | ; Simon Peyton Jones ; | ghc-devs@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 | wrote: | >> On 1/22/16 8:05 AM, Ben Gamari wrote: | >>> Manuel M T Chakravarty 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@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
RE: vectorisation code?
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:mainl...@apeiron.net] | Sent: 22 January 2016 14:58 | To: Thomas Miedema | Cc: Ben Gamari ; Manuel M T Chakravarty | ; Simon Peyton Jones ; | ghc-devs@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 | wrote: | >> On 1/22/16 8:05 AM, Ben Gamari wrote: | >>> Manuel M T Chakravarty 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
Geoffrey Mainland writes: > That's part of "minimal maintenance mode." Yes, keeping DPH will impose > some burden. I am not pretending that keeping DPH imposes no cost, but > instead asking what cost we are willing to pay to keep DPH > working---maybe the answer is "none." > I would imagine that cost is greater than "none". Unfortunately, it is is very difficult to judge as it depends upon something none of us can know: what the future holds in store for DPH. Naturally, this is subject to the whims of funding and students' interests, but it would be good to know where the DPH project currently stands and what future plans for it, if any, exist. Is there potential for someone to come along in, say, the next three years, pick up the existing implementation, and begin turning it into something that might become useful to a larger audience? I stress the phrase "existing implementation" since we need to weigh the fact that, as has been mentioned in past discussions [1], the current implementation embodies some design decisions which will likely need to be changed, perhaps requiring a rewrite. If a rewrite is very likely it becomes harder for us to ask developers to invest the effort to keep this code building. I also stress the phrase "begin turning", acknowledging that this is a research project, that students and funding come and go, and the problem that the project attacks is a challenging one. I appreciate the fact that DPH may serve as a good smoke-test for GHC and it would be a shame to see this work rot into oblivion; as a Haskell user I am intrigued by the potential held by DPH. Nevertheless, it would be nice to have an estimate of the probability that the effort we put in maintaining DPH might some day be rewarded. Cheers, - Ben [1] http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/5645/ signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 > wrote: >> On 1/22/16 8:05 AM, Ben Gamari wrote: >>> Manuel M T Chakravarty 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
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? On Fri, Jan 22, 2016 at 3:17 PM, Geoffrey Mainland wrote: > On 1/22/16 8:05 AM, Ben Gamari wrote: > > Manuel M T Chakravarty 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 > > ___ > 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
Re: vectorisation code?
On 1/22/16 8:05 AM, Ben Gamari wrote: > Manuel M T Chakravarty 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
Manuel M T Chakravarty 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 signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: vectorisation code?
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. Concerning handling of the DPH libraries, since Austin was looking at putting some love into the —slow test suite. Maybe we could re-active the DPH tests, and hence, DPH library builds for ”slow” testing. The DPH libraries have shaken out many GHC bugs in the past. Adding them to ”slow” would ensure they don’t bit rot, improve the test suite, but keep it out of the main path for dev builds. Manuel > Geoffrey Mainland : > > On 01/22/2015 10:50 AM, Herbert Valerio Riedel wrote: >> On 2015-01-22 at 14:59:51 +0100, Geoffrey Mainland wrote: >>> The current situation is that DPH is not being built or maintained at >>> all. Given this state of affairs, it is hard to justify keeping it >>> around---DPH is just bitrotting. >>> >>> I am proposing that we reconnect it to the build and keep it building, >>> putting it in minimal maintenance mode. >> Ok, but how do we avoid issues like >> >> http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/5645/ >> >> in the future then? DPH became painful back then, because we didn't know >> what to do with 'vector' (which as a package at the time also suffered >> from neglect of maintainership) >> >> >> Cheers, >> hvr >> > > That's part of "minimal maintenance mode." Yes, keeping DPH will impose > some burden. I am not pretending that keeping DPH imposes no cost, but > instead asking what cost we are willing to pay to keep DPH > working---maybe the answer is "none." > > As for the particular issue you mentioned, I patched DPH to fix > compatibility with the new vector. Those changes have been in the tree > for some time, but DPH was never reconnected to the build, so it has > bitrotted again. > > Note that vector *also* no longer builds with the other libraries in the > tree, so if we excise DPH, we should excise vector. > > I am willing to put some effort into fixing these sorts of problems when > they come up. That may still impose too much burden on the other developers. > > Geoff > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
On 01/22/2015 10:50 AM, Herbert Valerio Riedel wrote: > On 2015-01-22 at 14:59:51 +0100, Geoffrey Mainland wrote: >> The current situation is that DPH is not being built or maintained at >> all. Given this state of affairs, it is hard to justify keeping it >> around---DPH is just bitrotting. >> >> I am proposing that we reconnect it to the build and keep it building, >> putting it in minimal maintenance mode. > Ok, but how do we avoid issues like > > http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/5645/ > > in the future then? DPH became painful back then, because we didn't know > what to do with 'vector' (which as a package at the time also suffered > from neglect of maintainership) > > > Cheers, > hvr > That's part of "minimal maintenance mode." Yes, keeping DPH will impose some burden. I am not pretending that keeping DPH imposes no cost, but instead asking what cost we are willing to pay to keep DPH working---maybe the answer is "none." As for the particular issue you mentioned, I patched DPH to fix compatibility with the new vector. Those changes have been in the tree for some time, but DPH was never reconnected to the build, so it has bitrotted again. Note that vector *also* no longer builds with the other libraries in the tree, so if we excise DPH, we should excise vector. I am willing to put some effort into fixing these sorts of problems when they come up. That may still impose too much burden on the other developers. Geoff ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
On 2015-01-22 at 14:59:51 +0100, Geoffrey Mainland wrote: > The current situation is that DPH is not being built or maintained at > all. Given this state of affairs, it is hard to justify keeping it > around---DPH is just bitrotting. > > I am proposing that we reconnect it to the build and keep it building, > putting it in minimal maintenance mode. Ok, but how do we avoid issues like http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/5645/ in the future then? DPH became painful back then, because we didn't know what to do with 'vector' (which as a package at the time also suffered from neglect of maintainership) Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
The current situation is that DPH is not being built or maintained at all. Given this state of affairs, it is hard to justify keeping it around---DPH is just bitrotting. I am proposing that we reconnect it to the build and keep it building, putting it in minimal maintenance mode. This will at least allow someone to pick it up again in the future without having to first re-integrate it into the then-current GHC. I recognize this imposes a larger ongoing burden than either just leaving it in the tree or purging it completely. Whether or not that burden is justified, I'm not sure. If we purge DPH, I am afraid it is likely we will have lost DPH forever. That would indeed be a loss. Geoff On 1/22/15 6:36 AM, Simon Peyton Jones wrote: > The issue that Richard Eisenberg raised is not > > DPH doesn't compile (which Geoff might fix) > > but rather > > no one is working on DPH, but having it all in the tree > imposes a small cost on a large number of people > (build/validate cycle time, grep hits, etc) > > So re-adding the DPH library would worsen the perceived problem, rather than > make it better. > > | > My fear is that without making it part of the nightly builds, > | > accumulated bitrot will make it extremely difficult to ever > | > re-integrate DPH. I would hate to see that happen. > > This was the reason we originally put the DPH libraries in the build. Before > we did so, changes to GHC often broke DPH, sometimes for superficial reasons, > but sometimes because the DPH libraries really push the envelope of what GHC > can do. > > But when literally no one is working on DPH, it's harder to justify imposing > (small) costs on everyone without giving immediate benefits to anyone. > That's the point that is being made here. I don’t have strong feelings > myself. > > Simon > > > | -Original Message- > | From: Manuel M T Chakravarty [mailto:c...@cse.unsw.edu.au] > | Sent: 22 January 2015 04:08 > | To: Mainland Geoffrey > | Cc: Simon Peyton Jones; ghc-devs@haskell.org > | Subject: Re: vectorisation code? > | > | Thanks for the offer, Geoff. > | > | Under these circumstances, I would also very much prefer for Geoff > | getting the code in order and leaving it in GHC. > | > | Manuel > | > | > Geoffrey Mainland : > | > > | > I'm sorry I'm a bit late to the game here, but there is also the > | > option of reconnecting DPH to the build. > | > > | > When I patched DPH for the new version of the vector library, I did > | > not perform this step---now I'm sorry I didn't. > | > > | > I am willing to get DPH in working order again---I believe the > | > required work will be minimal. However, that only makes sense if we > | 1) > | > re-enable DPH in the nightly builds (and also by default for > | > validate?), and 2) folks will not object too strenuously to having > | DPH stick around. > | > > | > My fear is that without making it part of the nightly builds, > | > accumulated bitrot will make it extremely difficult to ever > | > re-integrate DPH. I would hate to see that happen. > | > > | > Geoff > | > > | > On 01/21/2015 04:11 PM, Simon Peyton Jones wrote: > | >> > | >> I’ve had a chat to Manuel. He is content for us to remove DPH code > | >> altogether (not just CPP/comment it out), provided we are careful > | to > | >> signpost what has gone and how to get it back. > | >> > | >> > | >> > | >> I am no Git expert, so can I leave it to you guys to work out what > | to > | >> do? The specification is: > | >> > | >> ·It should be clear how to revert the change; that is, to > | >> re-introduce the deleted code. I guess that might be “git revert > | >> ” > | >> > | >> ·If someone trips over more DPH code later, and wants to > | >> remove that too, it should be clear how to add it to the list of > | >> things to be revertred. > | >> > | >> ·We should have a Trac ticket “Resume work on DPH and > | >> vectorisation” or something like that, which summarises the > | reversion > | >> process. > | >> > | >> > | >> > | >> Just to be clear, this does not indicate any lack of interest in > | DPH > | >> on my part. (Quite the reverse.) It’s just that while no one is > | >> actually working on it, we should use our source code control > | system > | >> to move it out of the way, as others on this thread have > | persuasively > | >
RE: vectorisation code?
The issue that Richard Eisenberg raised is not DPH doesn't compile (which Geoff might fix) but rather no one is working on DPH, but having it all in the tree imposes a small cost on a large number of people (build/validate cycle time, grep hits, etc) So re-adding the DPH library would worsen the perceived problem, rather than make it better. | > My fear is that without making it part of the nightly builds, | > accumulated bitrot will make it extremely difficult to ever | > re-integrate DPH. I would hate to see that happen. This was the reason we originally put the DPH libraries in the build. Before we did so, changes to GHC often broke DPH, sometimes for superficial reasons, but sometimes because the DPH libraries really push the envelope of what GHC can do. But when literally no one is working on DPH, it's harder to justify imposing (small) costs on everyone without giving immediate benefits to anyone. That's the point that is being made here. I don’t have strong feelings myself. Simon | -Original Message- | From: Manuel M T Chakravarty [mailto:c...@cse.unsw.edu.au] | Sent: 22 January 2015 04:08 | To: Mainland Geoffrey | Cc: Simon Peyton Jones; ghc-devs@haskell.org | Subject: Re: vectorisation code? | | Thanks for the offer, Geoff. | | Under these circumstances, I would also very much prefer for Geoff | getting the code in order and leaving it in GHC. | | Manuel | | > Geoffrey Mainland : | > | > I'm sorry I'm a bit late to the game here, but there is also the | > option of reconnecting DPH to the build. | > | > When I patched DPH for the new version of the vector library, I did | > not perform this step---now I'm sorry I didn't. | > | > I am willing to get DPH in working order again---I believe the | > required work will be minimal. However, that only makes sense if we | 1) | > re-enable DPH in the nightly builds (and also by default for | > validate?), and 2) folks will not object too strenuously to having | DPH stick around. | > | > My fear is that without making it part of the nightly builds, | > accumulated bitrot will make it extremely difficult to ever | > re-integrate DPH. I would hate to see that happen. | > | > Geoff | > | > On 01/21/2015 04:11 PM, Simon Peyton Jones wrote: | >> | >> I’ve had a chat to Manuel. He is content for us to remove DPH code | >> altogether (not just CPP/comment it out), provided we are careful | to | >> signpost what has gone and how to get it back. | >> | >> | >> | >> I am no Git expert, so can I leave it to you guys to work out what | to | >> do? The specification is: | >> | >> ·It should be clear how to revert the change; that is, to | >> re-introduce the deleted code. I guess that might be “git revert | >> ” | >> | >> ·If someone trips over more DPH code later, and wants to | >> remove that too, it should be clear how to add it to the list of | >> things to be revertred. | >> | >> ·We should have a Trac ticket “Resume work on DPH and | >> vectorisation” or something like that, which summarises the | reversion | >> process. | >> | >> | >> | >> Just to be clear, this does not indicate any lack of interest in | DPH | >> on my part. (Quite the reverse.) It’s just that while no one is | >> actually working on it, we should use our source code control | system | >> to move it out of the way, as others on this thread have | persuasively | >> argued. | >> | >> | >> | >> Manuel, yell if I got anything wrong. | >> | >> | >> | >> Thanks! | >> | >> | >> | >> Simon | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> *From:*ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of | >> *Carter Schonwald | >> *Sent:* 21 January 2015 03:32 | >> *To:* RodLogic | >> *Cc:* Manuel M T Chakravarty; ghc-devs@haskell.org | >> *Subject:* Re: vectorisation code? | >> | >> | >> | >> moving it to its own submodule is just a complicated version of | >> cutting a branch that has the code Right before deleting it from | master. | >> | >> afaik, the amount of love needed is roughly "one or more full time | >> grad students really owning it", though i could be wrong. | >> | >> | >> | >> | >> | >> On Tue, Jan 20, 2015 at 5:39 AM, RodLogic > <mailto:d...@rodlogic.net>> wrote: | >> | >>(disclaimer: I know nothing about the vectoriz
Re: vectorisation code?
I think there is significant infrastructure in the parser, not sure how that could be managed via a plugin. Alan On Thu, Jan 22, 2015 at 10:55 AM, Jan Stolarek wrote: > Would it be possible to turn vectorisation into a compiler plugin? This > would kill two birds with > one stone: vectorisation would be removed from GHC sources and at the same > time the code could be > maintained by Geoffrey or anyone else who would want to take it up. I'm > not sure what would > happen with DPH in that scenario. > > Janek > > Dnia czwartek, 22 stycznia 2015, Manuel M T Chakravarty napisał: > > Thanks for the offer, Geoff. > > > > Under these circumstances, I would also very much prefer for Geoff > getting > > the code in order and leaving it in GHC. > > > > Manuel > > > > > Geoffrey Mainland : > > > > > > I'm sorry I'm a bit late to the game here, but there is also the option > > > of reconnecting DPH to the build. > > > > > > When I patched DPH for the new version of the vector library, I did not > > > perform this step---now I'm sorry I didn't. > > > > > > I am willing to get DPH in working order again---I believe the required > > > work will be minimal. However, that only makes sense if we 1) re-enable > > > DPH in the nightly builds (and also by default for validate?), and 2) > > > folks will not object too strenuously to having DPH stick around. > > > > > > My fear is that without making it part of the nightly builds, > > > accumulated bitrot will make it extremely difficult to ever > re-integrate > > > DPH. I would hate to see that happen. > > > > > > Geoff > > > > > > On 01/21/2015 04:11 PM, Simon Peyton Jones wrote: > > >> I’ve had a chat to Manuel. He is content for us to remove DPH code > > >> altogether (not just CPP/comment it out), provided we are careful to > > >> signpost what has gone and how to get it back. > > >> > > >> > > >> > > >> I am no Git expert, so can I leave it to you guys to work out what to > > >> do? The specification is: > > >> > > >> ·It should be clear how to revert the change; that is, to > > >> re-introduce the deleted code. I guess that might be “git revert > > >> ” > > >> > > >> ·If someone trips over more DPH code later, and wants to > > >> remove that too, it should be clear how to add it to the list of > > >> things to be revertred. > > >> > > >> ·We should have a Trac ticket “Resume work on DPH and > > >> vectorisation” or something like that, which summarises the reversion > > >> process. > > >> > > >> > > >> > > >> Just to be clear, this does not indicate any lack of interest in DPH > > >> on my part. (Quite the reverse.) It’s just that while no one is > > >> actually working on it, we should use our source code control system > > >> to move it out of the way, as others on this thread have persuasively > > >> argued. > > >> > > >> > > >> > > >> Manuel, yell if I got anything wrong. > > >> > > >> > > >> > > >> Thanks! > > >> > > >> > > >> > > >> Simon > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> *From:*ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of > > >> *Carter Schonwald > > >> *Sent:* 21 January 2015 03:32 > > >> *To:* RodLogic > > >> *Cc:* Manuel M T Chakravarty; ghc-devs@haskell.org > > >> *Subject:* Re: vectorisation code? > > >> > > >> > > >> > > >> moving it to its own submodule is just a complicated version of > > >> cutting a branch that has the code Right before deleting it from > master. > > >> > > >> afaik, the amount of love needed is roughly "one or more full time > > >> grad students really owning it", though i could be wrong. > > >> > > >> > > >> > > >> > > >> > > >> On Tue, Jan 20, 2015 at 5:39 AM, RodLogic > >> <mailto:d...@rodlogic.net>> wrote: > > >> > > >>(disclaimer: I know nothing a
Re: vectorisation code?
Would it be possible to turn vectorisation into a compiler plugin? This would kill two birds with one stone: vectorisation would be removed from GHC sources and at the same time the code could be maintained by Geoffrey or anyone else who would want to take it up. I'm not sure what would happen with DPH in that scenario. Janek Dnia czwartek, 22 stycznia 2015, Manuel M T Chakravarty napisał: > Thanks for the offer, Geoff. > > Under these circumstances, I would also very much prefer for Geoff getting > the code in order and leaving it in GHC. > > Manuel > > > Geoffrey Mainland : > > > > I'm sorry I'm a bit late to the game here, but there is also the option > > of reconnecting DPH to the build. > > > > When I patched DPH for the new version of the vector library, I did not > > perform this step---now I'm sorry I didn't. > > > > I am willing to get DPH in working order again---I believe the required > > work will be minimal. However, that only makes sense if we 1) re-enable > > DPH in the nightly builds (and also by default for validate?), and 2) > > folks will not object too strenuously to having DPH stick around. > > > > My fear is that without making it part of the nightly builds, > > accumulated bitrot will make it extremely difficult to ever re-integrate > > DPH. I would hate to see that happen. > > > > Geoff > > > > On 01/21/2015 04:11 PM, Simon Peyton Jones wrote: > >> I’ve had a chat to Manuel. He is content for us to remove DPH code > >> altogether (not just CPP/comment it out), provided we are careful to > >> signpost what has gone and how to get it back. > >> > >> > >> > >> I am no Git expert, so can I leave it to you guys to work out what to > >> do? The specification is: > >> > >> ·It should be clear how to revert the change; that is, to > >> re-introduce the deleted code. I guess that might be “git revert > >> ” > >> > >> ·If someone trips over more DPH code later, and wants to > >> remove that too, it should be clear how to add it to the list of > >> things to be revertred. > >> > >> ·We should have a Trac ticket “Resume work on DPH and > >> vectorisation” or something like that, which summarises the reversion > >> process. > >> > >> > >> > >> Just to be clear, this does not indicate any lack of interest in DPH > >> on my part. (Quite the reverse.) It’s just that while no one is > >> actually working on it, we should use our source code control system > >> to move it out of the way, as others on this thread have persuasively > >> argued. > >> > >> > >> > >> Manuel, yell if I got anything wrong. > >> > >> > >> > >> Thanks! > >> > >> > >> > >> Simon > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> *From:*ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of > >> *Carter Schonwald > >> *Sent:* 21 January 2015 03:32 > >> *To:* RodLogic > >> *Cc:* Manuel M T Chakravarty; ghc-devs@haskell.org > >> *Subject:* Re: vectorisation code? > >> > >> > >> > >> moving it to its own submodule is just a complicated version of > >> cutting a branch that has the code Right before deleting it from master. > >> > >> afaik, the amount of love needed is roughly "one or more full time > >> grad students really owning it", though i could be wrong. > >> > >> > >> > >> > >> > >> On Tue, Jan 20, 2015 at 5:39 AM, RodLogic >> <mailto:d...@rodlogic.net>> wrote: > >> > >>(disclaimer: I know nothing about the vectorization code) > >> > >> > >> > >>Now, is the vectorization code really dead code or it is code that > >>needs love to come back to life? By removing it from the code > >>base, you are probably sealing it's fate as dead code as we are > >>limiting new or existing contributors to act on it (even if it's a > >>commit hash away). If it is code that needs love to come back to > >>life, grep noise or conditional compilation is a small price to > >>pay here, imho. > >> > >> > >> > >>As a compromise, is it possible to move vectorization code into > >>
Re: vectorisation code?
Thanks for the offer, Geoff. Under these circumstances, I would also very much prefer for Geoff getting the code in order and leaving it in GHC. Manuel > Geoffrey Mainland : > > I'm sorry I'm a bit late to the game here, but there is also the option > of reconnecting DPH to the build. > > When I patched DPH for the new version of the vector library, I did not > perform this step---now I'm sorry I didn't. > > I am willing to get DPH in working order again---I believe the required > work will be minimal. However, that only makes sense if we 1) re-enable > DPH in the nightly builds (and also by default for validate?), and 2) > folks will not object too strenuously to having DPH stick around. > > My fear is that without making it part of the nightly builds, > accumulated bitrot will make it extremely difficult to ever re-integrate > DPH. I would hate to see that happen. > > Geoff > > On 01/21/2015 04:11 PM, Simon Peyton Jones wrote: >> >> I’ve had a chat to Manuel. He is content for us to remove DPH code >> altogether (not just CPP/comment it out), provided we are careful to >> signpost what has gone and how to get it back. >> >> >> >> I am no Git expert, so can I leave it to you guys to work out what to >> do? The specification is: >> >> ·It should be clear how to revert the change; that is, to >> re-introduce the deleted code. I guess that might be “git revert >> ” >> >> ·If someone trips over more DPH code later, and wants to >> remove that too, it should be clear how to add it to the list of >> things to be revertred. >> >> ·We should have a Trac ticket “Resume work on DPH and >> vectorisation” or something like that, which summarises the reversion >> process. >> >> >> >> Just to be clear, this does not indicate any lack of interest in DPH >> on my part. (Quite the reverse.) It’s just that while no one is >> actually working on it, we should use our source code control system >> to move it out of the way, as others on this thread have persuasively >> argued. >> >> >> >> Manuel, yell if I got anything wrong. >> >> >> >> Thanks! >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> >> >> *From:*ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of >> *Carter Schonwald >> *Sent:* 21 January 2015 03:32 >> *To:* RodLogic >> *Cc:* Manuel M T Chakravarty; ghc-devs@haskell.org >> *Subject:* Re: vectorisation code? >> >> >> >> moving it to its own submodule is just a complicated version of >> cutting a branch that has the code Right before deleting it from master. >> >> afaik, the amount of love needed is roughly "one or more full time >> grad students really owning it", though i could be wrong. >> >> >> >> >> >> On Tue, Jan 20, 2015 at 5:39 AM, RodLogic > <mailto:d...@rodlogic.net>> wrote: >> >>(disclaimer: I know nothing about the vectorization code) >> >> >> >>Now, is the vectorization code really dead code or it is code that >>needs love to come back to life? By removing it from the code >>base, you are probably sealing it's fate as dead code as we are >>limiting new or existing contributors to act on it (even if it's a >>commit hash away). If it is code that needs love to come back to >>life, grep noise or conditional compilation is a small price to >>pay here, imho. >> >> >> >>As a compromise, is it possible to move vectorization code into >>it's own submodule in git or is it too intertwined with core GHC? >>So that it can be worked on independent of GHC? >> >> >> >> >> >>On Tue, Jan 20, 2015 at 6:47 AM, Herbert Valerio Riedel >>mailto:hvrie...@gmail.com>> wrote: >> >>On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote: >>>> Here's an alternate suggestion: in SimplCore, keep the call >>to vectorise >>>> around, but commented out >> >>> Yuck. Carter and Brandon are right here - we have git, let >>it do the >>> job. I propose that we remove vectorization code, create a >>Trac ticket >>> about vectorization & DPH needing love and record the commit >>hash in >>> the ticket so that we can revert it easily in the future. >
Re: vectorisation code?
I'm sorry I'm a bit late to the game here, but there is also the option of reconnecting DPH to the build. When I patched DPH for the new version of the vector library, I did not perform this step---now I'm sorry I didn't. I am willing to get DPH in working order again---I believe the required work will be minimal. However, that only makes sense if we 1) re-enable DPH in the nightly builds (and also by default for validate?), and 2) folks will not object too strenuously to having DPH stick around. My fear is that without making it part of the nightly builds, accumulated bitrot will make it extremely difficult to ever re-integrate DPH. I would hate to see that happen. Geoff On 01/21/2015 04:11 PM, Simon Peyton Jones wrote: > > I’ve had a chat to Manuel. He is content for us to remove DPH code > altogether (not just CPP/comment it out), provided we are careful to > signpost what has gone and how to get it back. > > > > I am no Git expert, so can I leave it to you guys to work out what to > do? The specification is: > > ·It should be clear how to revert the change; that is, to > re-introduce the deleted code. I guess that might be “git revert > ” > > ·If someone trips over more DPH code later, and wants to > remove that too, it should be clear how to add it to the list of > things to be revertred. > > ·We should have a Trac ticket “Resume work on DPH and > vectorisation” or something like that, which summarises the reversion > process. > > > > Just to be clear, this does not indicate any lack of interest in DPH > on my part. (Quite the reverse.) It’s just that while no one is > actually working on it, we should use our source code control system > to move it out of the way, as others on this thread have persuasively > argued. > > > > Manuel, yell if I got anything wrong. > > > > Thanks! > > > > Simon > > > > > > > > > > > > *From:*ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of > *Carter Schonwald > *Sent:* 21 January 2015 03:32 > *To:* RodLogic > *Cc:* Manuel M T Chakravarty; ghc-devs@haskell.org > *Subject:* Re: vectorisation code? > > > > moving it to its own submodule is just a complicated version of > cutting a branch that has the code Right before deleting it from master. > > afaik, the amount of love needed is roughly "one or more full time > grad students really owning it", though i could be wrong. > > > > > > On Tue, Jan 20, 2015 at 5:39 AM, RodLogic <mailto:d...@rodlogic.net>> wrote: > > (disclaimer: I know nothing about the vectorization code) > > > > Now, is the vectorization code really dead code or it is code that > needs love to come back to life? By removing it from the code > base, you are probably sealing it's fate as dead code as we are > limiting new or existing contributors to act on it (even if it's a > commit hash away). If it is code that needs love to come back to > life, grep noise or conditional compilation is a small price to > pay here, imho. > > > > As a compromise, is it possible to move vectorization code into > it's own submodule in git or is it too intertwined with core GHC? > So that it can be worked on independent of GHC? > > > > > > On Tue, Jan 20, 2015 at 6:47 AM, Herbert Valerio Riedel > mailto:hvrie...@gmail.com>> wrote: > > On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote: > >> Here's an alternate suggestion: in SimplCore, keep the call > to vectorise > >> around, but commented out > > > Yuck. Carter and Brandon are right here - we have git, let > it do the > > job. I propose that we remove vectorization code, create a > Trac ticket > > about vectorization & DPH needing love and record the commit > hash in > > the ticket so that we can revert it easily in the future. > > I'm also against commenting out dead code in the presence of a > VCS. > > Btw, here's two links discussing the issues related to > commenting out if > anyone's interested in knowing more: > > - > > http://programmers.stackexchange.com/questions/190096/can-commented-out-code-be-valuable-documentation > > - > > http://programmers.stackexchange.com/questions/45378/is-commented-out-code-really-always-bad > > > Cheers, > hvr > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: vectorisation code?
I’ve had a chat to Manuel. He is content for us to remove DPH code altogether (not just CPP/comment it out), provided we are careful to signpost what has gone and how to get it back. I am no Git expert, so can I leave it to you guys to work out what to do? The specification is: ·It should be clear how to revert the change; that is, to re-introduce the deleted code. I guess that might be “git revert ” ·If someone trips over more DPH code later, and wants to remove that too, it should be clear how to add it to the list of things to be revertred. ·We should have a Trac ticket “Resume work on DPH and vectorisation” or something like that, which summarises the reversion process. Just to be clear, this does not indicate any lack of interest in DPH on my part. (Quite the reverse.) It’s just that while no one is actually working on it, we should use our source code control system to move it out of the way, as others on this thread have persuasively argued. Manuel, yell if I got anything wrong. Thanks! Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Carter Schonwald Sent: 21 January 2015 03:32 To: RodLogic Cc: Manuel M T Chakravarty; ghc-devs@haskell.org Subject: Re: vectorisation code? moving it to its own submodule is just a complicated version of cutting a branch that has the code Right before deleting it from master. afaik, the amount of love needed is roughly "one or more full time grad students really owning it", though i could be wrong. On Tue, Jan 20, 2015 at 5:39 AM, RodLogic mailto:d...@rodlogic.net>> wrote: (disclaimer: I know nothing about the vectorization code) Now, is the vectorization code really dead code or it is code that needs love to come back to life? By removing it from the code base, you are probably sealing it's fate as dead code as we are limiting new or existing contributors to act on it (even if it's a commit hash away). If it is code that needs love to come back to life, grep noise or conditional compilation is a small price to pay here, imho. As a compromise, is it possible to move vectorization code into it's own submodule in git or is it too intertwined with core GHC? So that it can be worked on independent of GHC? On Tue, Jan 20, 2015 at 6:47 AM, Herbert Valerio Riedel mailto:hvrie...@gmail.com>> wrote: On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote: >> Here's an alternate suggestion: in SimplCore, keep the call to vectorise >> around, but commented out > Yuck. Carter and Brandon are right here - we have git, let it do the > job. I propose that we remove vectorization code, create a Trac ticket > about vectorization & DPH needing love and record the commit hash in > the ticket so that we can revert it easily in the future. I'm also against commenting out dead code in the presence of a VCS. Btw, here's two links discussing the issues related to commenting out if anyone's interested in knowing more: - http://programmers.stackexchange.com/questions/190096/can-commented-out-code-be-valuable-documentation - http://programmers.stackexchange.com/questions/45378/is-commented-out-code-really-always-bad Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
moving it to its own submodule is just a complicated version of cutting a branch that has the code Right before deleting it from master. afaik, the amount of love needed is roughly "one or more full time grad students really owning it", though i could be wrong. On Tue, Jan 20, 2015 at 5:39 AM, RodLogic wrote: > (disclaimer: I know nothing about the vectorization code) > > Now, is the vectorization code really dead code or it is code that needs > love to come back to life? By removing it from the code base, you are > probably sealing it's fate as dead code as we are limiting new or existing > contributors to act on it (even if it's a commit hash away). If it is code > that needs love to come back to life, grep noise or conditional compilation > is a small price to pay here, imho. > > As a compromise, is it possible to move vectorization code into it's own > submodule in git or is it too intertwined with core GHC? So that it can be > worked on independent of GHC? > > > On Tue, Jan 20, 2015 at 6:47 AM, Herbert Valerio Riedel < > hvrie...@gmail.com> wrote: > >> On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote: >> >> Here's an alternate suggestion: in SimplCore, keep the call to >> vectorise >> >> around, but commented out >> >> > Yuck. Carter and Brandon are right here - we have git, let it do the >> > job. I propose that we remove vectorization code, create a Trac ticket >> > about vectorization & DPH needing love and record the commit hash in >> > the ticket so that we can revert it easily in the future. >> >> I'm also against commenting out dead code in the presence of a VCS. >> >> Btw, here's two links discussing the issues related to commenting out if >> anyone's interested in knowing more: >> >> - >> http://programmers.stackexchange.com/questions/190096/can-commented-out-code-be-valuable-documentation >> >> - >> http://programmers.stackexchange.com/questions/45378/is-commented-out-code-really-always-bad >> >> >> Cheers, >> hvr >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
(disclaimer: I know nothing about the vectorization code) Now, is the vectorization code really dead code or it is code that needs love to come back to life? By removing it from the code base, you are probably sealing it's fate as dead code as we are limiting new or existing contributors to act on it (even if it's a commit hash away). If it is code that needs love to come back to life, grep noise or conditional compilation is a small price to pay here, imho. As a compromise, is it possible to move vectorization code into it's own submodule in git or is it too intertwined with core GHC? So that it can be worked on independent of GHC? On Tue, Jan 20, 2015 at 6:47 AM, Herbert Valerio Riedel wrote: > On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote: > >> Here's an alternate suggestion: in SimplCore, keep the call to vectorise > >> around, but commented out > > > Yuck. Carter and Brandon are right here - we have git, let it do the > > job. I propose that we remove vectorization code, create a Trac ticket > > about vectorization & DPH needing love and record the commit hash in > > the ticket so that we can revert it easily in the future. > > I'm also against commenting out dead code in the presence of a VCS. > > Btw, here's two links discussing the issues related to commenting out if > anyone's interested in knowing more: > > - > http://programmers.stackexchange.com/questions/190096/can-commented-out-code-be-valuable-documentation > > - > http://programmers.stackexchange.com/questions/45378/is-commented-out-code-really-always-bad > > > Cheers, > hvr > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote: >> Here's an alternate suggestion: in SimplCore, keep the call to vectorise >> around, but commented out > Yuck. Carter and Brandon are right here - we have git, let it do the > job. I propose that we remove vectorization code, create a Trac ticket > about vectorization & DPH needing love and record the commit hash in > the ticket so that we can revert it easily in the future. I'm also against commenting out dead code in the presence of a VCS. Btw, here's two links discussing the issues related to commenting out if anyone's interested in knowing more: - http://programmers.stackexchange.com/questions/190096/can-commented-out-code-be-valuable-documentation - http://programmers.stackexchange.com/questions/45378/is-commented-out-code-really-always-bad Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
> Here's an alternate suggestion: in SimplCore, keep the call to vectorise > around, but commented out Yuck. Carter and Brandon are right here - we have git, let it do the job. I propose that we remove vectorization code, create a Trac ticket about vectorization & DPH needing love and record the commit hash in the ticket so that we can revert it easily in the future. Janek ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
On Mon, Jan 19, 2015 at 10:47 PM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > relatedly: wont the source be preserved in the git history if we remove > it? the CPP etc solution is > Indeed; most of the projects I'm involved with have a specific policy to *not* keep commented-out or otherwise disabled features in the active tree, because they can be pulled back later from history or branches as appropriate. You might want to either save it to a new branch or set a tag on HEAD before removing it, so you can more easily find it later. You've got a revision control system; let *it* do the work of keeping track of stuff like this. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
relatedly: wont the source be preserved in the git history if we remove it?
the CPP etc solution is no simpler than just keeping the code cached in the
git history right? Or will having it in the repo, but CPP'd/commented out
somehow preserve some invariant that cant be maintained by resuscitating it
later from the git history? the mater branch doesn't allow rebasing or
force pushes AFAIK anyways, so the history truly is immutable, right?
tl;dr our git repo is immutable, if we just deleted the dir, we still have
it in the git history right? Esp if its not being maintained / type checked
either way?
On Mon, Jan 19, 2015 at 7:12 PM, Richard Eisenberg
wrote:
> With all due respect to Manuel's request, could I opt for a different
> resolution? I frequently (several times during most minutes of GHC
> programming) grep the GHC source code for this or that. If the
> vectorisation code is CPP'd away but still present in the compiler/
> directory, these greps will find hits in the code. Furthermore, without the
> specific knowledge that there is a `#if 0` at the top of the file, the code
> will look quite active. Of course, I could modify my grep macro to skip the
> vectorise directory, but the next dev down the road might not know to do
> this.
>
> Here's an alternate suggestion: in SimplCore, keep the call to vectorise
> around, but commented out (not just with CPP, for better syntax
> highlighting). Include a Note explaining what `vectorise` does and why it's
> not there at the moment. However, move the actual vectorisation code
> somewhere else in the repo, outside of the source directories (`utils`? a
> new `attic` directory?).
>
> Manuel, is this acceptable to you? Other devs, thoughts? Perhaps we should
> also make a Trac ticket asking for some love to be given to this feature.
>
> Thanks,
> Richard
>
> On Jan 19, 2015, at 9:21 AM, Simon Peyton Jones
> wrote:
>
> > Austin, (or anyone else)
> >
> > Manuel says:
> >
> > | > Would it be ok if we left it in the repo, but CPP'd it out so that
> > | we
> > | > didn't compile everything? (The DPH library is in the same state at
> > | > the moment.)
> > | >
> > | > It might suffer bit-rot, but it’d still be there for resurrection.
> > |
> > | Sure, that’s ok.
> >
> > Could you action this? Just avoid compiling anything in 'vectorise/',
> using (I suppose) cpp to create a stub where necessary.
> >
> > Leave enough comments to explain!
> >
> > Simon
> >
> > |
> > | I hope everything is fine in Cambridge!
> > | Manuel
> > |
> > | > | -----Original Message-
> > | > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf
> Of
> > | > | Manuel M T Chakravarty
> > | > | Sent: 16 January 2015 02:58
> > | > | To: Richard Eisenberg
> > | > | Cc: ghc-devs@haskell.org Devs
> > | > | Subject: Re: vectorisation code?
> > | > |
> > | > | [Sorry, sent from the wrong account at first.]
> > | > |
> > | > | We currently don’t have the resources to work on DPH. I would
> > | > | obviously prefer to leave the code in, in the hope that we will be
> > | > | able to return to it.
> > | > |
> > | > | Manuel
> > | > |
> > | > | > Richard Eisenberg :
> > | > | >
> > | > | > Hi devs,
> > | > | >
> > | > | > There's a sizable number of modules in the `vectorise`
> > | > | subdirectory of GHC. I'm sure these do all sorts of wonderful
> > | > | things. But what, exactly? And, does anyone make use of these
> > | wonderful things?
> > | > | >
> > | > | > A quick poking through the code shows a tiny link between the
> > | > | vectorise code and the rest of GHC -- the function `vectorise`
> > | > | exported from the module `Vectorise`, which is named in exactly
> > | one
> > | > | place from SimplCore. From what I can tell, the function will be
> > | > | called only when `-fvectorise` is specified, and then it seems to
> > | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE
> > | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is
> > | > | given only a cursory explanation. It seems these work with DPH...
> > | > | which has been disabled, no? Searching online finds several hits,
> > | > | but nothing more recent than 2012.
> > | > | >
> > | > | > I hope this question doesn't offend -- it seems that
> > | &
Re: vectorisation code?
Given the vectorisation code is in its own subdirectory already, it’s quite
easy to spot in a grep, I would say.
Manuel
> Richard Eisenberg :
>
> With all due respect to Manuel's request, could I opt for a different
> resolution? I frequently (several times during most minutes of GHC
> programming) grep the GHC source code for this or that. If the vectorisation
> code is CPP'd away but still present in the compiler/ directory, these greps
> will find hits in the code. Furthermore, without the specific knowledge that
> there is a `#if 0` at the top of the file, the code will look quite active.
> Of course, I could modify my grep macro to skip the vectorise directory, but
> the next dev down the road might not know to do this.
>
> Here's an alternate suggestion: in SimplCore, keep the call to vectorise
> around, but commented out (not just with CPP, for better syntax
> highlighting). Include a Note explaining what `vectorise` does and why it's
> not there at the moment. However, move the actual vectorisation code
> somewhere else in the repo, outside of the source directories (`utils`? a new
> `attic` directory?).
>
> Manuel, is this acceptable to you? Other devs, thoughts? Perhaps we should
> also make a Trac ticket asking for some love to be given to this feature.
>
> Thanks,
> Richard
>
> On Jan 19, 2015, at 9:21 AM, Simon Peyton Jones wrote:
>
>> Austin, (or anyone else)
>>
>> Manuel says:
>>
>> | > Would it be ok if we left it in the repo, but CPP'd it out so that
>> | we
>> | > didn't compile everything? (The DPH library is in the same state at
>> | > the moment.)
>> | >
>> | > It might suffer bit-rot, but it’d still be there for resurrection.
>> |
>> | Sure, that’s ok.
>>
>> Could you action this? Just avoid compiling anything in 'vectorise/', using
>> (I suppose) cpp to create a stub where necessary.
>>
>> Leave enough comments to explain!
>>
>> Simon
>>
>> |
>> | I hope everything is fine in Cambridge!
>> | Manuel
>> |
>> | > | -----Original Message-
>> | > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
>> | > | Manuel M T Chakravarty
>> | > | Sent: 16 January 2015 02:58
>> | > | To: Richard Eisenberg
>> | > | Cc: ghc-devs@haskell.org Devs
>> | > | Subject: Re: vectorisation code?
>> | > |
>> | > | [Sorry, sent from the wrong account at first.]
>> | > |
>> | > | We currently don’t have the resources to work on DPH. I would
>> | > | obviously prefer to leave the code in, in the hope that we will be
>> | > | able to return to it.
>> | > |
>> | > | Manuel
>> | > |
>> | > | > Richard Eisenberg :
>> | > | >
>> | > | > Hi devs,
>> | > | >
>> | > | > There's a sizable number of modules in the `vectorise`
>> | > | subdirectory of GHC. I'm sure these do all sorts of wonderful
>> | > | things. But what, exactly? And, does anyone make use of these
>> | wonderful things?
>> | > | >
>> | > | > A quick poking through the code shows a tiny link between the
>> | > | vectorise code and the rest of GHC -- the function `vectorise`
>> | > | exported from the module `Vectorise`, which is named in exactly
>> | one
>> | > | place from SimplCore. From what I can tell, the function will be
>> | > | called only when `-fvectorise` is specified, and then it seems to
>> | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE
>> | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is
>> | > | given only a cursory explanation. It seems these work with DPH...
>> | > | which has been disabled, no? Searching online finds several hits,
>> | > | but nothing more recent than 2012.
>> | > | >
>> | > | > I hope this question doesn't offend -- it seems that
>> | > | vectorisation probably has amazing performance gains. Yet, the
>> | > | feature also seems unloved. In the meantime, compiling (and
>> | > | recompiling, and
>> | > | recompiling...) the modules takes time, as does going through
>> | them
>> | > | to propagate changes from elsewhere. If this feature is truly
>> | > | orphaned, unloved, and unused at the moment, is it reasonable to
>> | > | consider putting it on furlough?
>> | > | &g
Re: vectorisation code?
Richard Eisenberg wrote: > Here's an alternate suggestion: in SimplCore, keep the call to vectorise around, but commented out (not just with CPP, for better syntax highlighting). Include a Note explaining what `vectorise` does and why it's not there at the moment. However, move the actual vectorisation code somewhere else in the repo, outside of the source directories (`utils`? a new `attic` directory?). I don't know too much about git, but I would think we'd want to remove it from master and add a commit putting it back in to a dph branch. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
With all due respect to Manuel's request, could I opt for a different
resolution? I frequently (several times during most minutes of GHC programming)
grep the GHC source code for this or that. If the vectorisation code is CPP'd
away but still present in the compiler/ directory, these greps will find hits
in the code. Furthermore, without the specific knowledge that there is a `#if
0` at the top of the file, the code will look quite active. Of course, I could
modify my grep macro to skip the vectorise directory, but the next dev down the
road might not know to do this.
Here's an alternate suggestion: in SimplCore, keep the call to vectorise
around, but commented out (not just with CPP, for better syntax highlighting).
Include a Note explaining what `vectorise` does and why it's not there at the
moment. However, move the actual vectorisation code somewhere else in the repo,
outside of the source directories (`utils`? a new `attic` directory?).
Manuel, is this acceptable to you? Other devs, thoughts? Perhaps we should also
make a Trac ticket asking for some love to be given to this feature.
Thanks,
Richard
On Jan 19, 2015, at 9:21 AM, Simon Peyton Jones wrote:
> Austin, (or anyone else)
>
> Manuel says:
>
> | > Would it be ok if we left it in the repo, but CPP'd it out so that
> | we
> | > didn't compile everything? (The DPH library is in the same state at
> | > the moment.)
> | >
> | > It might suffer bit-rot, but it’d still be there for resurrection.
> |
> | Sure, that’s ok.
>
> Could you action this? Just avoid compiling anything in 'vectorise/', using
> (I suppose) cpp to create a stub where necessary.
>
> Leave enough comments to explain!
>
> Simon
>
> |
> | I hope everything is fine in Cambridge!
> | Manuel
> |
> | > | -Original Message-
> | > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> | > | Manuel M T Chakravarty
> | > | Sent: 16 January 2015 02:58
> | > | To: Richard Eisenberg
> | > | Cc: ghc-devs@haskell.org Devs
> | > | Subject: Re: vectorisation code?
> | > |
> | > | [Sorry, sent from the wrong account at first.]
> | > |
> | > | We currently don’t have the resources to work on DPH. I would
> | > | obviously prefer to leave the code in, in the hope that we will be
> | > | able to return to it.
> | > |
> | > | Manuel
> | > |
> | > | > Richard Eisenberg :
> | > | >
> | > | > Hi devs,
> | > | >
> | > | > There's a sizable number of modules in the `vectorise`
> | > | subdirectory of GHC. I'm sure these do all sorts of wonderful
> | > | things. But what, exactly? And, does anyone make use of these
> | wonderful things?
> | > | >
> | > | > A quick poking through the code shows a tiny link between the
> | > | vectorise code and the rest of GHC -- the function `vectorise`
> | > | exported from the module `Vectorise`, which is named in exactly
> | one
> | > | place from SimplCore. From what I can tell, the function will be
> | > | called only when `-fvectorise` is specified, and then it seems to
> | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE
> | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is
> | > | given only a cursory explanation. It seems these work with DPH...
> | > | which has been disabled, no? Searching online finds several hits,
> | > | but nothing more recent than 2012.
> | > | >
> | > | > I hope this question doesn't offend -- it seems that
> | > | vectorisation probably has amazing performance gains. Yet, the
> | > | feature also seems unloved. In the meantime, compiling (and
> | > | recompiling, and
> | > | recompiling...) the modules takes time, as does going through
> | them
> | > | to propagate changes from elsewhere. If this feature is truly
> | > | orphaned, unloved, and unused at the moment, is it reasonable to
> | > | consider putting it on furlough?
> | > | >
> | > | > Thanks,
> | > | > Richard
> | > | > ___
> | > | > ghc-devs mailing list
> | > | > ghc-devs@haskell.org
> | > | > http://www.haskell.org/mailman/listinfo/ghc-devs
> | > |
> | > | ___
> | > | ghc-devs mailing list
> | > | ghc-devs@haskell.org
> | > | http://www.haskell.org/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: vectorisation code?
Austin, (or anyone else)
Manuel says:
| > Would it be ok if we left it in the repo, but CPP'd it out so that
| we
| > didn't compile everything? (The DPH library is in the same state at
| > the moment.)
| >
| > It might suffer bit-rot, but it’d still be there for resurrection.
|
| Sure, that’s ok.
Could you action this? Just avoid compiling anything in 'vectorise/', using (I
suppose) cpp to create a stub where necessary.
Leave enough comments to explain!
Simon
|
| I hope everything is fine in Cambridge!
| Manuel
|
| > | -Original Message-
| > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
| > | Manuel M T Chakravarty
| > | Sent: 16 January 2015 02:58
| > | To: Richard Eisenberg
| > | Cc: ghc-devs@haskell.org Devs
| > | Subject: Re: vectorisation code?
| > |
| > | [Sorry, sent from the wrong account at first.]
| > |
| > | We currently don’t have the resources to work on DPH. I would
| > | obviously prefer to leave the code in, in the hope that we will be
| > | able to return to it.
| > |
| > | Manuel
| > |
| > | > Richard Eisenberg :
| > | >
| > | > Hi devs,
| > | >
| > | > There's a sizable number of modules in the `vectorise`
| > | subdirectory of GHC. I'm sure these do all sorts of wonderful
| > | things. But what, exactly? And, does anyone make use of these
| wonderful things?
| > | >
| > | > A quick poking through the code shows a tiny link between the
| > | vectorise code and the rest of GHC -- the function `vectorise`
| > | exported from the module `Vectorise`, which is named in exactly
| one
| > | place from SimplCore. From what I can tell, the function will be
| > | called only when `-fvectorise` is specified, and then it seems to
| > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE
| > | #-}` doesn't appear in the manual at all, and `-fvectorise` is
| > | given only a cursory explanation. It seems these work with DPH...
| > | which has been disabled, no? Searching online finds several hits,
| > | but nothing more recent than 2012.
| > | >
| > | > I hope this question doesn't offend -- it seems that
| > | vectorisation probably has amazing performance gains. Yet, the
| > | feature also seems unloved. In the meantime, compiling (and
| > | recompiling, and
| > | recompiling...) the modules takes time, as does going through
| them
| > | to propagate changes from elsewhere. If this feature is truly
| > | orphaned, unloved, and unused at the moment, is it reasonable to
| > | consider putting it on furlough?
| > | >
| > | > Thanks,
| > | > Richard
| > | > ___
| > | > ghc-devs mailing list
| > | > ghc-devs@haskell.org
| > | > http://www.haskell.org/mailman/listinfo/ghc-devs
| > |
| > | ___
| > | ghc-devs mailing list
| > | ghc-devs@haskell.org
| > | http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
On Jan 16, 2015, at 4:12 AM, Simon Peyton Jones wrote: > For 7.10, DPH is definitely not supported, I'm afraid. Does this mean that the vectorisation code is also defunct? As in, is there a way to usefully access the feature without DPH? Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
Out of curiosity I removed vectorisation code and did a devel2 build. Build time on my laptop went down from 25 minutes to 24 minutes - a modest 4% improvement. Of course there is more to be gained by avoiding recompilations later during development. > I would obviously prefer to leave the code in, in the hope that we will be > able to return to it. Is this just hope or are there any actual plans to attempt to return to DPH? (I assume this has to do with funding.) Janek Dnia piątek, 16 stycznia 2015, Simon Peyton Jones napisał: > | What's the plan for DPH and 7.10? Is it bitrotting or abandoned, and > | does this mean there weren't enough users of it to notice and help > | maintain it? > > For 7.10, DPH is definitely not supported, I'm afraid. > > For a longer term vision I defer to Manuel! > > Simon > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: vectorisation code?
| What's the plan for DPH and 7.10? Is it bitrotting or abandoned, and | does this mean there weren't enough users of it to notice and help | maintain it? For 7.10, DPH is definitely not supported, I'm afraid. For a longer term vision I defer to Manuel! Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
On Fri, Jan 16, 2015 at 3:58 AM, Manuel M T Chakravarty wrote: > [Sorry, sent from the wrong account at first.] > > We currently don't have the resources to work on DPH. I would > obviously prefer to leave the code in, in the hope that we will be > able to return to it. What's the plan for DPH and 7.10? Is it bitrotting or abandoned, and does this mean there weren't enough users of it to notice and help maintain it? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
[Sorry, sent from the wrong account at first.]
We currently don’t have the resources to work on DPH. I would obviously prefer
to leave the code in, in the hope that we will be able to return to it.
Manuel
> Richard Eisenberg :
>
> Hi devs,
>
> There's a sizable number of modules in the `vectorise` subdirectory of GHC.
> I'm sure these do all sorts of wonderful things. But what, exactly? And, does
> anyone make use of these wonderful things?
>
> A quick poking through the code shows a tiny link between the vectorise code
> and the rest of GHC -- the function `vectorise` exported from the module
> `Vectorise`, which is named in exactly one place from SimplCore. From what I
> can tell, the function will be called only when `-fvectorise` is specified,
> and then it seems to interact with a {-# VECTORISE #-} pragma. However, `{-#
> VECTORISE #-}` doesn't appear in the manual at all, and `-fvectorise` is
> given only a cursory explanation. It seems these work with DPH... which has
> been disabled, no? Searching online finds several hits, but nothing more
> recent than 2012.
>
> I hope this question doesn't offend -- it seems that vectorisation probably
> has amazing performance gains. Yet, the feature also seems unloved. In the
> meantime, compiling (and recompiling, and recompiling...) the modules takes
> time, as does going through them to propagate changes from elsewhere. If this
> feature is truly orphaned, unloved, and unused at the moment, is it
> reasonable to consider putting it on furlough?
>
> Thanks,
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: vectorisation code?
I share Richard's opinion.
Janek
Dnia wtorek, 13 stycznia 2015, Richard Eisenberg napisał:
> Hi devs,
>
> There's a sizable number of modules in the `vectorise` subdirectory of GHC.
> I'm sure these do all sorts of wonderful things. But what, exactly? And,
> does anyone make use of these wonderful things?
>
> A quick poking through the code shows a tiny link between the vectorise
> code and the rest of GHC -- the function `vectorise` exported from the
> module `Vectorise`, which is named in exactly one place from SimplCore.
> From what I can tell, the function will be called only when `-fvectorise`
> is specified, and then it seems to interact with a {-# VECTORISE #-}
> pragma. However, `{-# VECTORISE #-}` doesn't appear in the manual at all,
> and `-fvectorise` is given only a cursory explanation. It seems these work
> with DPH... which has been disabled, no? Searching online finds several
> hits, but nothing more recent than 2012.
>
> I hope this question doesn't offend -- it seems that vectorisation probably
> has amazing performance gains. Yet, the feature also seems unloved. In the
> meantime, compiling (and recompiling, and recompiling...) the modules takes
> time, as does going through them to propagate changes from elsewhere. If
> this feature is truly orphaned, unloved, and unused at the moment, is it
> reasonable to consider putting it on furlough?
>
> Thanks,
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
