Re: vectorisation code?

2016-09-12 Thread Ben Gamari 
Geoffrey Mainland  writes:

> Hi Ben,
>
> Progress is stalled on a rewrite of DPH's use of TH since TH is no
> longer available in stage1. There is no reason this can't be worked
> around, just that it's more work than I initially expected.
>
> I agree that it would be good to get this taken care of soon, but that
> is generically true of almost all things :) I was planning on getting
> this done for 8.2. If there is a reason for more urgency, let's discuss.
>
Hi Geoff,

Hsa there been any news here? It would be great if we could have this
taken care of by mid-October or so; the time right before a new release
is always quite busy so the more things we can handle earlier the
better.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: vectorisation code?

2016-08-19 Thread Ben Gamari 
Ben Gamari  writes:

> Geoffrey Mainland  writes:
>
>> Hi Ben,
>>
Hi Geoff,

>> Progress is stalled on a rewrite of DPH's use of TH since TH is no
>> longer available in stage1. There is no reason this can't be worked
>> around, just that it's more work than I initially expected.
>>
> Alright, thanks for the update Geoff!
>
Any news on this front? 8.2 isn't imminent but it's certainly on the horizon
so it would be good to get this taken care of in the next month or so.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: vectorisation code?

2016-01-26 Thread Ben Gamari 
Geoffrey Mainland  writes:

> I didn't mean to suggest that DPH should be part of every build, just 
> that it should be part of *some* regular build.
>
> If we're willing to do that, then I'm certainly willing to get DPH back 
> up and running.
>
We discussed this in today's meeting. The consensus seems to be that
this is worth doing; let's make it happen.

As I mentioned yesterday, I would be happy to provide the infrastructure
necessary to produce full testsuite results on a nightly basis. I
already do nightly builds and setting up some sort of monitoring is
something that I've been meaning to do for some time now.

Geoff, could you brush the cob-webs off of the vectoriser and post a
patch to Phabricator?

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: vectorisation code?

2016-01-25 Thread Ben Gamari 
Simon Peyton Jones  writes:

> Making it part of *every* validate is a big ask because it takes so
> long to build.
>
> But we already have "sh validate --slow", which runs a lot more tests
> than --fast. So maybe it could be part of --slow?
>
> And I do think that we should have a nightly build (although perhaps
> not the continuous-integration build-every-commit stuff) that runs the
> full testsuite. I don't think that happens right now. But it should.
>
Indeed that sounds reasonable. I have a cronjob which performs a nightly
build and testsuite run anyways. As a start I can make these logs
publicly available and ensure that I get notified when the build breaks.

In the longer term I hope we can get some integration with Phabricator,
although if I'm not mistaken this isn't yet possible.

Cheers,

- Ben



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: vectorisation code?

2016-01-22 Thread Ben Gamari 
Manuel M T Chakravarty  writes:

> The way I see it, the main cost of keeping DPH around is to handle
> breakages such as that with vector. I can’t promise to address those
> in a timely manner, which is why I agreed to disable/remove DPH.
>
> However, as Geoff stepped forward, this issue is solved. As for the
> overhead in compile time etc, I don’t think, it is that much of a
> deal. During development, most compiles runs are incremental anyway.
>
Judging by the VCS history it seems that nothing happened in response to
this thread. Geoff, do you see yourself having time to pick this up in
the near future?

If not, perhaps we should pick up this matter again and seriously
consider parking this code in a branch until someone is able to pick it
up again.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: vectorisation code?

2016-01-22 Thread Geoffrey Mainland 
On 1/22/16 8:05 AM, Ben Gamari wrote:
> Manuel M T Chakravarty  writes: > >> The way I see it, 
> the main cost of keeping DPH around is to handle
>> breakages such as that with vector. I can’t promise to address those
>> in a timely manner, which is why I agreed to disable/remove DPH. >>
>> However, as Geoff stepped forward, this issue is solved. As for the
>> overhead in compile time etc, I don’t think, it is that much of a >>
deal. During development, most compiles runs are incremental anyway. >>
> Judging by the VCS history it seems that nothing happened in response
to > this thread. Geoff, do you see yourself having time to pick this up
in > the near future? > > If not, perhaps we should pick up this matter
again and seriously > consider parking this code in a branch until
someone is able to pick it > up again. > > Cheers, > > - Ben

Yes, I am willing to do the work to get DPH back into the build in the
near future. However, that only makes sense if we are willing to build
DPH regularly. Also, I can't be solely responsible for all breakage
resulting from DPH; DPH has regularly exposed bugs in the past, which is
one reason to get it back into the regular build, but I can't promise to
fix all problems that might be exposed by DPH in the future :)

If I put a patch on Phab that updates DPH, are we willing to make DPH
part of the regular validation script again?

Cheers,
Geoff

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: vectorisation code?

2016-01-22 Thread Geoffrey Mainland 
On 1/22/16 11:36 AM, Herbert Valerio Riedel wrote:
> On 2016-01-22 at 17:23:18 +0100, Geoffrey Mainland wrote:
>> I didn't mean to suggest that DPH should be part of every build, just
>> that it should be part of *some* regular build.
>>
>> If we're willing to do that, then I'm certainly willing to get DPH
>> back up and running.
> What's the situation with the `vector`/`primitive` packages if DPH is to
> be resuscitated? Does the official `vector` package need to be made
> DPH-aware?
>

The vector and primitive packages will not need to be changed in any
significant way, and perhaps not at all. It's possible we might need a
few patches to vector to, e.g., expose a data constructor somewhere, so
I can't promise that we will need zero changes.

Geoff
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: vectorisation code?

2016-01-22 Thread Geoffrey Mainland 
On Fri, Jan 22, 2016 at 03:23:56PM +0100, Thomas Miedema wrote:
> On Fri, Jan 22, 2016 at 3:17 PM, Geoffrey Mainland  
> wrote:
>> On 1/22/16 8:05 AM, Ben Gamari wrote:
>>> Manuel M T Chakravarty  writes:
 The way I see it, the main cost of keeping DPH around is to handle
 breakages such as that with vector. I can't promise to address those
 in a timely manner, which is why I agreed to disable/remove DPH.
 However, as Geoff stepped forward, this issue is solved. As for the
 overhead in compile time etc, I don't think, it is that much of a
 deal. During development, most compiles runs are incremental anyway.
>>>
>>> Judging by the VCS history it seems that nothing happened in response to
>>> this thread. Geoff, do you see yourself having time to pick this up in
>>> the near future? If not, perhaps we should pick up this matter again and 
>>> seriously
>>> consider parking this code in a branch until someone is able to pick it
>>> up again.
>>> Cheers,
>>> - Ben
>>
>> Yes, I am willing to do the work to get DPH back into the build in the
>> near future. However, that only makes sense if we are willing to build
>> DPH regularly. Also, I can't be solely responsible for all breakage
>> resulting from DPH; DPH has regularly exposed bugs in the past, which is
>> one reason to get it back into the regular build, but I can't promise to
>> fix all problems that might be exposed by DPH in the future :)
>> 
>> If I put a patch on Phab that updates DPH, are we willing to make DPH
>> part of the regular validation script again?
>> 
>> Cheers,
>> Geoff
>
> We could make all of hackage be part of the ghc build, and it would turn
> up bugs. But we don't do that either. Why is dph special?

Manuel and Simon can say more, but DPH has in the past been very good at
exposing, for example, regressions in the inliner. It exercises GHC in a
way that few other packages do.

DPH is intimately tied to GHC, so it's not something that can be
maintained separately as a package. If we aren't willing to make DPH
part of the regular build, then it will just bitrot again quickly, and
there's little point in doing the work to get it running again.

I'm of the opinion that DPH still has value and that it would be a shame
to lose it forever, which is effectively what will happen if we relegate
the vectorizer to a branch. I am willing to get DPH working again, but
only if there is general agreement that DPH is worth having---and that
we are willing to once again make it part of the regular build.

Geoff
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: vectorisation code?

2016-01-22 Thread Herbert Valerio Riedel 
On 2016-01-22 at 17:23:18 +0100, Geoffrey Mainland wrote:
> I didn't mean to suggest that DPH should be part of every build, just
> that it should be part of *some* regular build.
>
> If we're willing to do that, then I'm certainly willing to get DPH
> back up and running.

What's the situation with the `vector`/`primitive` packages if DPH is to
be resuscitated? Does the official `vector` package need to be made
DPH-aware?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: vectorisation code?

2015-01-27 Thread Manuel M T Chakravarty 
The way I see it, the main cost of keeping DPH around is to handle breakages 
such as that with vector. I can’t promise to address those in a timely manner, 
which is why I agreed to disable/remove DPH.

However, as Geoff stepped forward, this issue is solved. As for the overhead in 
compile time etc, I don’t think, it is that much of a deal. During development, 
most compiles runs are incremental anyway.

Concerning handling of the DPH libraries, since Austin was looking at putting 
some love into the —slow test suite. Maybe we could re-active the DPH tests, 
and hence, DPH library builds for ”slow” testing. The DPH libraries have shaken 
out many GHC bugs in the past. Adding them to ”slow” would ensure they don’t 
bit rot, improve the test suite, but keep it out of the main path for dev 
builds.

Manuel

 Geoffrey Mainland mainl...@apeiron.net:
 
 On 01/22/2015 10:50 AM, Herbert Valerio Riedel wrote:
 On 2015-01-22 at 14:59:51 +0100, Geoffrey Mainland wrote:
 The current situation is that DPH is not being built or maintained at
 all. Given this state of affairs, it is hard to justify keeping it
 around---DPH is just bitrotting.
 
 I am proposing that we reconnect it to the build and keep it building,
 putting it in minimal maintenance mode. 
 Ok, but how do we avoid issues like
 
 http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/5645/
 
 in the future then? DPH became painful back then, because we didn't know
 what to do with 'vector' (which as a package at the time also suffered
 from neglect of maintainership)
 
 
 Cheers,
  hvr
 
 
 That's part of minimal maintenance mode. Yes, keeping DPH will impose
 some burden. I am not pretending that keeping DPH imposes no cost, but
 instead asking what cost we are willing to pay to keep DPH
 working---maybe the answer is none.
 
 As for the particular issue you mentioned, I patched DPH to fix
 compatibility with the new vector. Those changes have been in the tree
 for some time, but DPH was never reconnected to the build, so it has
 bitrotted again.
 
 Note that vector *also* no longer builds with the other libraries in the
 tree, so if we excise DPH, we should excise vector.
 
 I am willing to put some effort into fixing these sorts of problems when
 they come up. That may still impose too much burden on the other developers.
 
 Geoff
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: vectorisation code?

2015-01-22 Thread Geoffrey Mainland 
The current situation is that DPH is not being built or maintained at
all. Given this state of affairs, it is hard to justify keeping it
around---DPH is just bitrotting.

I am proposing that we reconnect it to the build and keep it building,
putting it in minimal maintenance mode. This will at least allow someone
to pick it up again in the future without having to first re-integrate
it into the then-current GHC. I recognize this imposes a larger ongoing
burden than either just leaving it in the tree or purging it completely.
Whether or not that burden is justified, I'm not sure.

If we purge DPH, I am afraid it is likely we will have lost DPH forever.
That would indeed be a loss.

Geoff

On 1/22/15 6:36 AM, Simon Peyton Jones wrote:
 The issue that Richard Eisenberg raised is not

   DPH doesn't compile (which Geoff might fix)

 but rather

   no one is working on DPH, but having it all in the tree
   imposes a small cost on a large number of people
   (build/validate cycle time, grep hits, etc)

 So re-adding the DPH library would worsen the perceived problem, rather than 
 make it better.

 |   My fear is that without making it part of the nightly builds,
 |   accumulated bitrot will make it extremely difficult to ever
 |   re-integrate DPH. I would hate to see that happen.

 This was the reason we originally put the DPH libraries in the build.  Before 
 we did so, changes to GHC often broke DPH, sometimes for superficial reasons, 
 but sometimes because the DPH libraries really push the envelope of what GHC 
 can do.

 But when literally no one is working on DPH, it's harder to justify imposing 
 (small) costs on everyone without giving immediate benefits to anyone.  
 That's the point that is being made here.  I don’t have strong feelings 
 myself.

 Simon 


 |  -Original Message-
 |  From: Manuel M T Chakravarty [mailto:c...@cse.unsw.edu.au]
 |  Sent: 22 January 2015 04:08
 |  To: Mainland Geoffrey
 |  Cc: Simon Peyton Jones; ghc-devs@haskell.org
 |  Subject: Re: vectorisation code?
 |  
 |  Thanks for the offer, Geoff.
 |  
 |  Under these circumstances, I would also very much prefer for Geoff
 |  getting the code in order and leaving it in GHC.
 |  
 |  Manuel
 |  
 |   Geoffrey Mainland 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

RE: vectorisation code?

2015-01-22 Thread Simon Peyton Jones 
The issue that Richard Eisenberg raised is not

  DPH doesn't compile (which Geoff might fix)

but rather

  no one is working on DPH, but having it all in the tree
  imposes a small cost on a large number of people
  (build/validate cycle time, grep hits, etc)

So re-adding the DPH library would worsen the perceived problem, rather than 
make it better.

|   My fear is that without making it part of the nightly builds,
|   accumulated bitrot will make it extremely difficult to ever
|   re-integrate DPH. I would hate to see that happen.

This was the reason we originally put the DPH libraries in the build.  Before 
we did so, changes to GHC often broke DPH, sometimes for superficial reasons, 
but sometimes because the DPH libraries really push the envelope of what GHC 
can do.

But when literally no one is working on DPH, it's harder to justify imposing 
(small) costs on everyone without giving immediate benefits to anyone.  That's 
the point that is being made here.  I don’t have strong feelings myself.

Simon 


|  -Original Message-
|  From: Manuel M T Chakravarty [mailto:c...@cse.unsw.edu.au]
|  Sent: 22 January 2015 04:08
|  To: Mainland Geoffrey
|  Cc: Simon Peyton Jones; ghc-devs@haskell.org
|  Subject: Re: vectorisation code?
|  
|  Thanks for the offer, Geoff.
|  
|  Under these circumstances, I would also very much prefer for Geoff
|  getting the code in order and leaving it in GHC.
|  
|  Manuel
|  
|   Geoffrey Mainland 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

Re: vectorisation code?

2015-01-22 Thread 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 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-co
 de-really-always-bad
 
 
 Cheers,
   hvr

Re: vectorisation code?

2015-01-22 Thread Alan Kim Zimmerman 
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 jan.stola...@p.lodz.pl
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 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

Re: vectorisation code?

2015-01-22 Thread Geoffrey Mainland 
On 01/22/2015 10:50 AM, Herbert Valerio Riedel wrote:
 On 2015-01-22 at 14:59:51 +0100, Geoffrey Mainland wrote:
 The current situation is that DPH is not being built or maintained at
 all. Given this state of affairs, it is hard to justify keeping it
 around---DPH is just bitrotting.

 I am proposing that we reconnect it to the build and keep it building,
 putting it in minimal maintenance mode. 
 Ok, but how do we avoid issues like

  http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/5645/

 in the future then? DPH became painful back then, because we didn't know
 what to do with 'vector' (which as a package at the time also suffered
 from neglect of maintainership)


 Cheers,
   hvr


That's part of minimal maintenance mode. Yes, keeping DPH will impose
some burden. I am not pretending that keeping DPH imposes no cost, but
instead asking what cost we are willing to pay to keep DPH
working---maybe the answer is none.

As for the particular issue you mentioned, I patched DPH to fix
compatibility with the new vector. Those changes have been in the tree
for some time, but DPH was never reconnected to the build, so it has
bitrotted again.

Note that vector *also* no longer builds with the other libraries in the
tree, so if we excise DPH, we should excise vector.

I am willing to put some effort into fixing these sorts of problems when
they come up. That may still impose too much burden on the other developers.

Geoff

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

RE: vectorisation code?

2015-01-21 Thread 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-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.netmailto: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.commailto: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.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

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

Re: vectorisation code?

2015-01-21 Thread 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-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

Re: vectorisation code?

2015-01-21 Thread 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 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

Re: vectorisation code?

2015-01-20 Thread Jan Stolarek 
 Here's an alternate suggestion: in SimplCore, keep the call to vectorise
 around, but commented out
Yuck. Carter and Brandon are right here - we have git, let it do the job. I 
propose that we remove 
vectorization code, create a Trac ticket about vectorization  DPH needing love 
and record the 
commit hash in the ticket so that we can revert it easily in the future.

Janek

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

Re: vectorisation code?

2015-01-20 Thread Herbert Valerio Riedel 
On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote:
 Here's an alternate suggestion: in SimplCore, keep the call to vectorise
 around, but commented out

 Yuck. Carter and Brandon are right here - we have git, let it do the
 job. I propose that we remove vectorization code, create a Trac ticket
 about vectorization  DPH needing love and record the commit hash in
 the ticket so that we can revert it easily in the future.

I'm also against commenting out dead code in the presence of a VCS.

Btw, here's two links discussing the issues related to commenting out if
anyone's interested in knowing more:

 - 
http://programmers.stackexchange.com/questions/190096/can-commented-out-code-be-valuable-documentation

 - 
http://programmers.stackexchange.com/questions/45378/is-commented-out-code-really-always-bad


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

Re: vectorisation code?

2015-01-20 Thread 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 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

Re: vectorisation code?

2015-01-20 Thread 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 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 wrote:

 On 2015-01-20 at 09:37:25 +0100, Jan Stolarek wrote:
  Here's an alternate suggestion: in SimplCore, keep the call to
 vectorise
  around, but commented out

  Yuck. Carter and Brandon are right here - we have git, let it do the
  job. I propose that we remove vectorization code, create a Trac ticket
  about vectorization  DPH needing love and record the commit hash in
  the ticket so that we can revert it easily in the future.

 I'm also against commenting out dead code in the presence of a VCS.

 Btw, here's two links discussing the issues related to commenting out if
 anyone's interested in knowing more:

  -
 http://programmers.stackexchange.com/questions/190096/can-commented-out-code-be-valuable-documentation

  -
 http://programmers.stackexchange.com/questions/45378/is-commented-out-code-really-always-bad


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



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


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

Re: vectorisation code?

2015-01-19 Thread Carter Schonwald 
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 e...@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 simo...@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-boun...@haskell.org] On Behalf
 Of
  |   | Manuel M T Chakravarty
  |   |  Sent: 16 January 2015 02:58
  |   |  To: Richard Eisenberg
  |   |  Cc: ghc-devs@haskell.org Devs
  |   |  Subject: Re: vectorisation code?
  |   |
  |   |  [Sorry, sent from the wrong account at first.]
  |   |
  |   |  We currently don’t have the resources to work on DPH. I would
  |   | obviously prefer to leave the code in, in the hope that we will be
  |   | able to return to it.
  |   |
  |   |  Manuel
  |   |
  |   |   Richard Eisenberg e...@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@haskell.org
  |   |   http://www.haskell.org/mailman/listinfo/ghc-devs
  |   |
  |   |  ___
  |   |  ghc-devs mailing list
  |   |  ghc-devs@haskell.org
  |   |  http://www.haskell.org/mailman

Re: vectorisation code?

2015-01-19 Thread Richard Eisenberg 
With all due respect to Manuel's request, could I opt for a different 
resolution? I frequently (several times during most minutes of GHC programming) 
grep the GHC source code for this or that. If the vectorisation code is CPP'd 
away but still present in the compiler/ directory, these greps will find hits 
in the code. Furthermore, without the specific knowledge that there is a `#if 
0` at the top of the file, the code will look quite active. Of course, I could 
modify my grep macro to skip the vectorise directory, but the next dev down the 
road might not know to do this.

Here's an alternate suggestion: in SimplCore, keep the call to vectorise 
around, but commented out (not just with CPP, for better syntax highlighting). 
Include a Note explaining what `vectorise` does and why it's not there at the 
moment. However, move the actual vectorisation code somewhere else in the repo, 
outside of the source directories (`utils`? a new `attic` directory?).

Manuel, is this acceptable to you? Other devs, thoughts? Perhaps we should also 
make a Trac ticket asking for some love to be given to this feature.

Thanks,
Richard

On Jan 19, 2015, at 9:21 AM, Simon Peyton Jones simo...@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-boun...@haskell.org] On Behalf Of
 |   | Manuel M T Chakravarty
 |   |  Sent: 16 January 2015 02:58
 |   |  To: Richard Eisenberg
 |   |  Cc: ghc-devs@haskell.org Devs
 |   |  Subject: Re: vectorisation code?
 |   |
 |   |  [Sorry, sent from the wrong account at first.]
 |   |
 |   |  We currently don’t have the resources to work on DPH. I would
 |   | obviously prefer to leave the code in, in the hope that we will be
 |   | able to return to it.
 |   |
 |   |  Manuel
 |   |
 |   |   Richard Eisenberg e...@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@haskell.org
 |   |   http://www.haskell.org/mailman/listinfo/ghc-devs
 |   |
 |   |  ___
 |   |  ghc-devs mailing list
 |   |  ghc-devs@haskell.org
 |   |  http://www.haskell.org/mailman/listinfo/ghc-devs
 
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs
 

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

Re: vectorisation code?

2015-01-19 Thread David Feuer 
Richard Eisenberg wrote:
 Here's an alternate suggestion: in SimplCore, keep the call to vectorise
around, but commented out (not just with CPP, for better syntax
highlighting). Include a Note explaining what `vectorise` does and why it's
not there at the moment. However, move the actual vectorisation code
somewhere else in the repo, outside of the source directories (`utils`? a
new `attic` directory?).

I don't know too much about git, but I would think we'd want to remove it
from master and add a commit putting it back in to a dph branch.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: vectorisation code?

2015-01-19 Thread 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 e...@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 simo...@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-boun...@haskell.org] On Behalf Of
 |   | Manuel M T Chakravarty
 |   |  Sent: 16 January 2015 02:58
 |   |  To: Richard Eisenberg
 |   |  Cc: ghc-devs@haskell.org Devs
 |   |  Subject: Re: vectorisation code?
 |   |
 |   |  [Sorry, sent from the wrong account at first.]
 |   |
 |   |  We currently don’t have the resources to work on DPH. I would
 |   | obviously prefer to leave the code in, in the hope that we will be
 |   | able to return to it.
 |   |
 |   |  Manuel
 |   |
 |   |   Richard Eisenberg e...@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@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

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

Re: vectorisation code?

2015-01-19 Thread Brandon Allbery 
On Mon, Jan 19, 2015 at 10:47 PM, Carter Schonwald 
carter.schonw...@gmail.com wrote:

 relatedly: wont the source be preserved in the git history if we remove
 it? the CPP etc solution is


Indeed; most of the projects I'm involved with have a specific policy to
*not* keep commented-out or otherwise disabled features in the active tree,
because they can be pulled back later from history or branches as
appropriate. You might want to either save it to a new branch or set a tag
on HEAD before removing it, so you can more easily find it later.

You've got a revision control system; let *it* do the work of keeping track
of stuff like this.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: vectorisation code?

2015-01-19 Thread Simon Peyton Jones 
Austin, (or anyone else)

Manuel says:

|   Would it be ok if we left it in the repo, but CPP'd it out so that
|  we
|   didn't compile everything?  (The DPH library is in the same state at
|   the moment.)
|  
|   It might suffer bit-rot, but it’d still be there for resurrection.
|  
|  Sure, that’s ok.

Could you action this?  Just avoid compiling anything in 'vectorise/', using (I 
suppose) cpp to create a stub where necessary.

Leave enough comments to explain!

Simon

|  
|  I hope everything is fine in Cambridge!
|  Manuel
|  
|   |  -Original Message-
|   |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
|   | Manuel M T Chakravarty
|   |  Sent: 16 January 2015 02:58
|   |  To: Richard Eisenberg
|   |  Cc: ghc-devs@haskell.org Devs
|   |  Subject: Re: vectorisation code?
|   |
|   |  [Sorry, sent from the wrong account at first.]
|   |
|   |  We currently don’t have the resources to work on DPH. I would
|   | obviously prefer to leave the code in, in the hope that we will be
|   | able to return to it.
|   |
|   |  Manuel
|   |
|   |   Richard Eisenberg e...@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@haskell.org
|   |   http://www.haskell.org/mailman/listinfo/ghc-devs
|   |
|   |  ___
|   |  ghc-devs mailing list
|   |  ghc-devs@haskell.org
|   |  http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: vectorisation code?

2015-01-16 Thread 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?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: vectorisation code?

2015-01-16 Thread 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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: vectorisation code?

2015-01-16 Thread 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@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs


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

Re: vectorisation code?

2015-01-16 Thread Richard Eisenberg 

On Jan 16, 2015, at 4:12 AM, Simon Peyton Jones simo...@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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: vectorisation code?

2015-01-15 Thread Manuel M T Chakravarty 
[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 e...@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@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

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

Re: vectorisation code?

2015-01-13 Thread 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@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