vectorisation code?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Richard Eisenberg-2
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

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Jan Stolarek
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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs




Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Manuel M T Chakravarty
In reply to this post by Richard Eisenberg-2
[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 <eir at cis.upenn.edu>:
>
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Tuncer Ayaz
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?

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Simon Peyton Jones
|  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

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Jan Stolarek
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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Richard Eisenberg-2
In reply to this post by Simon Peyton Jones

On Jan 16, 2015, at 4:12 AM, Simon Peyton Jones <simonpj at microsoft.com> 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

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Simon Peyton Jones
In reply to this post by Manuel M T Chakravarty
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 at haskell.org] On Behalf Of
|  > | Manuel M T Chakravarty
|  > |  Sent: 16 January 2015 02:58
|  > |  To: Richard Eisenberg
|  > |  Cc: ghc-devs at 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 <eir at cis.upenn.edu>:
|  > |  >
|  > |  > 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 at haskell.org
|  > |  > http://www.haskell.org/mailman/listinfo/ghc-devs
|  > |
|  > |  _______________________________________________
|  > |  ghc-devs mailing list
|  > |  ghc-devs at haskell.org
|  > |  http://www.haskell.org/mailman/listinfo/ghc-devs


Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Richard Eisenberg-2
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 <simonpj at microsoft.com> 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 at haskell.org] On Behalf Of
> |  > | Manuel M T Chakravarty
> |  > |  Sent: 16 January 2015 02:58
> |  > |  To: Richard Eisenberg
> |  > |  Cc: ghc-devs at 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 <eir at cis.upenn.edu>:
> |  > |  >
> |  > |  > 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 at haskell.org
> |  > |  > http://www.haskell.org/mailman/listinfo/ghc-devs
> |  > |
> |  > |  _______________________________________________
> |  > |  ghc-devs mailing list
> |  > |  ghc-devs at haskell.org
> |  > |  http://www.haskell.org/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>


Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Manuel M T Chakravarty
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 <eir at cis.upenn.edu>:
>
> 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 <simonpj at microsoft.com> 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 at haskell.org] On Behalf Of
>> |  > | Manuel M T Chakravarty
>> |  > |  Sent: 16 January 2015 02:58
>> |  > |  To: Richard Eisenberg
>> |  > |  Cc: ghc-devs at 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 <eir at cis.upenn.edu>:
>> |  > |  >
>> |  > |  > 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 at haskell.org
>> |  > |  > http://www.haskell.org/mailman/listinfo/ghc-devs
>> |  > |
>> |  > |  _______________________________________________
>> |  > |  ghc-devs mailing list
>> |  > |  ghc-devs at haskell.org
>> |  > |  http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Carter Schonwald
In reply to this post by Richard Eisenberg-2
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 <eir at cis.upenn.edu>
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 <simonpj at microsoft.com>
> 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 at haskell.org] On Behalf
> Of
> > |  > | Manuel M T Chakravarty
> > |  > |  Sent: 16 January 2015 02:58
> > |  > |  To: Richard Eisenberg
> > |  > |  Cc: ghc-devs at 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 <eir at cis.upenn.edu>:
> > |  > |  >
> > |  > |  > 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 at haskell.org
> > |  > |  > http://www.haskell.org/mailman/listinfo/ghc-devs
> > |  > |
> > |  > |  _______________________________________________
> > |  > |  ghc-devs mailing list
> > |  > |  ghc-devs at haskell.org
> > |  > |  http://www.haskell.org/mailman/listinfo/ghc-devs
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150119/7f67104d/attachment.html>

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Brandon Allbery
On Mon, Jan 19, 2015 at 10:47 PM, Carter Schonwald <
carter.schonwald at 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
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150119/e3cc3b1e/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Jan Stolarek
In reply to this post by Richard Eisenberg-2
> 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


Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Herbert Valerio Riedel-3
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

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

RodLogic
(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>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150120/d0e73761/attachment.html>

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Carter Schonwald
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> 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> 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
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150120/54ee402e/attachment.html>

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Simon Peyton Jones
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<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150121/ab7319bd/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

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



Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Manuel M T Chakravarty
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


Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Jan Stolarek
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 <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-co
> >>de-really-always-bad
> >>
> >>
> >>        Cheers,
> >>          hvr
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



123