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 <mainl...@apeiron.net>: > > 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-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 <d...@rodlogic.net >> <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 >> <hvrie...@gmail.com <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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs