vectorisation code?

Manuel M T Chakravarty chak at cse.unsw.edu.au
Thu Jan 22 04:08:22 UTC 2015


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 <mainland at 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-bounces at haskell.org] *On Behalf Of
>> *Carter Schonwald
>> *Sent:* 21 January 2015 03:32
>> *To:* RodLogic
>> *Cc:* Manuel M T Chakravarty; ghc-devs at 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 <dev at rodlogic.net
>> <mailto:dev at 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
>>    <hvriedel at gmail.com <mailto:hvriedel at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



More information about the ghc-devs mailing list