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?

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.stolarek at 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 <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
>
>
> _______________________________________________
> 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/20150122/56f7b3c0/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

Simon Peyton Jones
In reply to this post by Manuel M T Chakravarty
The issue that Richard Eisenberg raised is not

  DPH doesn't compile (which Geoff might fix)

but rather

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

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

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

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

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

Simon


|  -----Original Message-----
|  From: Manuel M T Chakravarty [mailto:chak at cse.unsw.edu.au]
|  Sent: 22 January 2015 04:08
|  To: Mainland Geoffrey
|  Cc: Simon Peyton Jones; ghc-devs at 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 <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-o
|  >> ut-code-be-valuable-documentation
|  >>
|  >>         -
|  >>
|  >> http://programmers.stackexchange.com/questions/45378/is-commented-
|  out
|  >> -code-really-always-bad
|  >>
|  >>
|  >>        Cheers,
|  >>          hvr
|  >>
|  >>
|  >
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org
|  > http://www.haskell.org/mailman/listinfo/ghc-devs


Reply | Threaded
Open this post in threaded view
|

vectorisation code?

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:chak at cse.unsw.edu.au]
> |  Sent: 22 January 2015 04:08
> |  To: Mainland Geoffrey
> |  Cc: Simon Peyton Jones; ghc-devs at 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 <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-o
> |  >> ut-code-be-valuable-documentation
> |  >>
> |  >>         -
> |  >>
> |  >> http://programmers.stackexchange.com/questions/45378/is-commented-
> |  out
> |  >> -code-really-always-bad
> |  >>
> |  >>
> |  >>        Cheers,
> |  >>          hvr
> |  >>
> |  >>
> |  >
> |  >
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org
> |  > http://www.haskell.org/mailman/listinfo/ghc-devs
>


Reply | Threaded
Open this post in threaded view
|

vectorisation code?

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

Reply | Threaded
Open this post in threaded view
|

vectorisation code?

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


Reply | Threaded
Open this post in threaded view
|

vectorisation code?

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


Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

Ben Gamari-3
Manuel M T Chakravarty <[hidden email]> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

Geoffrey Mainland
On 1/22/16 8:05 AM, Ben Gamari wrote:
> Manuel M T Chakravarty <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

Thomas Miedema
We could make all of hackage be part of the ghc build, and it would turn up bugs. But we don't do that either. Why is dph special?

On Fri, Jan 22, 2016 at 3:17 PM, Geoffrey Mainland <[hidden email]> wrote:
On 1/22/16 8:05 AM, Ben Gamari wrote:
> Manuel M T Chakravarty <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

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 <[hidden email]> wrote:
>> On 1/22/16 8:05 AM, Ben Gamari wrote:
>>> Manuel M T Chakravarty <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

Ben Gamari-2
In reply to this post by Geoffrey Mainland
Geoffrey Mainland <[hidden email]> writes:

> That's part of "minimal maintenance mode." Yes, keeping DPH will impose
> some burden. I am not pretending that keeping DPH imposes no cost, but
> instead asking what cost we are willing to pay to keep DPH
> working---maybe the answer is "none."
>
I would imagine that cost is greater than "none". Unfortunately, it is
is very difficult to judge as it depends upon something none of us can
know: what the future holds in store for DPH.

Naturally, this is subject to the whims of funding and students'
interests, but it would be good to know where the DPH project currently
stands and what future plans for it, if any, exist. Is there potential
for someone to come along in, say, the next three years, pick up the
existing implementation, and begin turning it into something that might
become useful to a larger audience?

I stress the phrase "existing implementation" since we need to weigh
the fact that, as has been mentioned in past discussions [1], the
current implementation embodies some design decisions which will likely
need to be changed, perhaps requiring a rewrite. If a rewrite is very
likely it becomes harder for us to ask developers to invest the effort
to keep this code building.

I also stress the phrase "begin turning", acknowledging that this is a
research project, that students and funding come and go, and the problem
that the project attacks is a challenging one.

I appreciate the fact that DPH may serve as a good smoke-test for GHC
and it would be a shame to see this work rot into oblivion; as a Haskell
user I am intrigued by the potential held by DPH. Nevertheless, it would
be nice to have an estimate of the probability that the effort we put in
maintaining DPH might some day be rewarded.

Cheers,

- Ben


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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: vectorisation code?

Simon Peyton Jones
In reply to this post by Geoffrey Mainland
Making it part of *every* validate is a big ask because it takes so long to build.

But we already have "sh validate --slow", which runs a lot more tests than --fast.  So maybe it could be part of --slow?

And I do think that we should have a nightly build (although perhaps not the continuous-integration build-every-commit stuff) that runs the full testsuite.  I don't think that happens right now.  But it should.

That might resolve the "painful to add DPH to validate" problem.

Simon

|  -----Original Message-----
|  From: Geoffrey Mainland [mailto:[hidden email]]
|  Sent: 22 January 2016 14:58
|  To: Thomas Miedema <[hidden email]>
|  Cc: Ben Gamari <[hidden email]>; Manuel M T Chakravarty
|  <[hidden email]>; Simon Peyton Jones <[hidden email]>;
|  [hidden email]
|  Subject: Re: vectorisation code?
|  
|  On Fri, Jan 22, 2016 at 03:23:56PM +0100, Thomas Miedema wrote:
|  > On Fri, Jan 22, 2016 at 3:17 PM, Geoffrey Mainland
|  <[hidden email]> wrote:
|  >> On 1/22/16 8:05 AM, Ben Gamari wrote:
|  >>> Manuel M T Chakravarty <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

Geoffrey Mainland
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.

Geoff

On 01/22/2016 11:13 AM, Simon Peyton Jones wrote:

> Making it part of *every* validate is a big ask because it takes so long to build.
>
> But we already have "sh validate --slow", which runs a lot more tests than --fast.  So maybe it could be part of --slow?
>
> And I do think that we should have a nightly build (although perhaps not the continuous-integration build-every-commit stuff) that runs the full testsuite.  I don't think that happens right now.  But it should.
>
> That might resolve the "painful to add DPH to validate" problem.
>
> Simon
>
> |  -----Original Message-----
> |  From: Geoffrey Mainland [mailto:[hidden email]]
> |  Sent: 22 January 2016 14:58
> |  To: Thomas Miedema <[hidden email]>
> |  Cc: Ben Gamari <[hidden email]>; Manuel M T Chakravarty
> |  <[hidden email]>; Simon Peyton Jones <[hidden email]>;
> |  [hidden email]
> |  Subject: Re: vectorisation code?
> |
> |  On Fri, Jan 22, 2016 at 03:23:56PM +0100, Thomas Miedema wrote:
> |  > On Fri, Jan 22, 2016 at 3:17 PM, Geoffrey Mainland
> |  <[hidden email]> wrote:
> |  >> On 1/22/16 8:05 AM, Ben Gamari wrote:
> |  >>> Manuel M T Chakravarty <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

Herbert Valerio Riedel-3
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: vectorisation code?

Ben Gamari-2
In reply to this post by Simon Peyton Jones
Simon Peyton Jones <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

Ben Gamari-3
In reply to this post by Geoffrey Mainland
Geoffrey Mainland <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

Geoffrey Mainland
On 01/26/2016 12:00 PM, Ben Gamari wrote:

> Geoffrey Mainland <[hidden email]> 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
>

Yes, I will take this on, but it may take a few months to happen.

Cheers,
Geoff
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

Ben Gamari-3
Geoffrey Mainland <[hidden email]> writes:

> On 01/26/2016 12:00 PM, Ben Gamari wrote:
>
>> We discussed this in today's meeting. The consensus seems to be that
>> this is worth doing; let's make it happen.
>>
>> As I mentioned yesterday, I would be happy to provide the infrastructure
>> necessary to produce full testsuite results on a nightly basis. I
>> already do nightly builds and setting up some sort of monitoring is
>> something that I've been meaning to do for some time now.
>>
>> Geoff, could you brush the cob-webs off of the vectoriser and post a
>> patch to Phabricator?
>>
>> Cheers,
>>
>> - Ben
>>
>
> Yes, I will take this on, but it may take a few months to happen.
>
Hi Geoff,

Has there been any motion on this front?

It would be great if we could get this taken care of soon.

Cheers,

- Ben


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (482 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: vectorisation code?

Geoffrey Mainland
On 05/11/2016 11:28 AM, Ben Gamari wrote:

> Geoffrey Mainland <[hidden email]> writes:
>
>> On 01/26/2016 12:00 PM, Ben Gamari wrote:
>>
>>> We discussed this in today's meeting. The consensus seems to be that
>>> this is worth doing; let's make it happen.
>>>
>>> As I mentioned yesterday, I would be happy to provide the infrastructure
>>> necessary to produce full testsuite results on a nightly basis. I
>>> already do nightly builds and setting up some sort of monitoring is
>>> something that I've been meaning to do for some time now.
>>>
>>> Geoff, could you brush the cob-webs off of the vectoriser and post a
>>> patch to Phabricator?
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>> Yes, I will take this on, but it may take a few months to happen.
>>
> Hi Geoff,
>
> Has there been any motion on this front?
>
> It would be great if we could get this taken care of soon.
>
> Cheers,
>
> - Ben
>

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.

Cheers,
Geoff
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
123