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-bounces@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

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

(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...

- http://programmers.stackexchange.com/questions/45378/is-commented-out-code-r...

Cheers, hvr _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

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 <some horrible hash>” · 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-bounces@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:dev@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:hvriedel@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... - http://programmers.stackexchange.com/questions/45378/is-commented-out-code-r... Cheers, hvr _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

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 <some horrible hash>”

· 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-bounces@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:dev@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:hvriedel@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...

- http://programmers.stackexchange.com/questions/45378/is-commented-out-code-r...

Cheers, hvr

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

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 <some horrible hash>”

· 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-bounces@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:dev@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:hvriedel@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-co

...

de-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

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:chak@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 | >> <some horrible hash>” | >> | >> · 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-bounces@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:dev@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:hvriedel@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-o | >> ut-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

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

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

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

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@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

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?

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

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

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

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

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/