Niklas Hambüchen | 13 Jun 03:59 2013

Testing invasive proposals with Hackager

In many discussions we make guesses about how much code proposals like
Functor => Monad would break.

You can use https://github.com/dterei/Hackager to build all of Hackage
(preferably in a VM).

Of course many packages have external dependencies, so I'd like to share
the following list of packages to save you some time.

(These are the names of packages suited for a Ubuntu 13.04 VM, and with
these installed, 2800 packages are successfully built and 1700 failing,
so it's quite good coverage. If you find more packages that improve on
this, please add them.)

acl-dev
attr-dev
binutils-dev
cfitsio-dev
expect-dev
freeglut3-dev
libadns1-dev
libalure-dev
libasound-dev
libaspell-dev
libatlas-dev
libaugeas-dev
libavcodec-dev
libavfilter-dev
libavformat-dev
libavutil-dev
(Continue reading)

Conrad Parker | 13 Jun 04:06 2013

Re: Testing invasive proposals with Hackager

On 13 June 2013 09:59, Niklas Hambüchen <mail <at> nh2.me> wrote:
> In many discussions we make guesses about how much code proposals like
> Functor => Monad would break.
>
> You can use https://github.com/dterei/Hackager to build all of Hackage
> (preferably in a VM).
>
> Of course many packages have external dependencies, so I'd like to share
> the following list of packages to save you some time.
>
>
> (These are the names of packages suited for a Ubuntu 13.04 VM, and with
> these installed, 2800 packages are successfully built and 1700 failing,
> so it's quite good coverage. If you find more packages that improve on
> this, please add them.)

awesome! How do we add packages to the list; do you have a github repo for it?

Conrad.
Niklas Hambüchen | 13 Jun 12:53 2013

Re: Testing invasive proposals with Hackager

On 13/06/13 10:06, Conrad Parker wrote:
> How do we add packages to the list; do you have a github repo for it?

I've put it on haskell-pkg-janitors:

https://github.com/haskell-pkg-janitors/hackage-build-deps/blob/master/ubuntu-13.04.txt
Joachim Breitner | 13 Jun 10:17 2013
Picon

Re: Testing invasive proposals with Hackager

Hi,

Am Donnerstag, den 13.06.2013, 09:59 +0800 schrieb Niklas Hambüchen:
> In many discussions we make guesses about how much code proposals like
> Functor => Monad would break.
> 
> You can use https://github.com/dterei/Hackager to build all of Hackage
> (preferably in a VM).
> 
> Of course many packages have external dependencies, so I'd like to share
> the following list of packages to save you some time.

Great tool. Does someone have the resources to run it regularly (i.e.
daily), dump the results and the diff-to-previous run somewhere and link
the status (currently building/not building) on the hackage package?
More CI-like data and testing is always good!

How much overlap is there between this tool and stackage?

Greetings,
Joachim

--

-- 
Joachim “nomeata” Breitner
  mail <at> joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nomeata <at> joachim-breitner.de  • GPG-Key: 0x4743206C
  Debian Developer: nomeata <at> debian.org
_______________________________________________
(Continue reading)

Vo Minh Thu | 13 Jun 10:23 2013
Picon

Re: Testing invasive proposals with Hackager




2013/6/13 Joachim Breitner <mail <at> joachim-breitner.de>
Hi,

Am Donnerstag, den 13.06.2013, 09:59 +0800 schrieb Niklas Hambüchen:
> In many discussions we make guesses about how much code proposals like
> Functor => Monad would break.
>
> You can use https://github.com/dterei/Hackager to build all of Hackage
> (preferably in a VM).
>
> Of course many packages have external dependencies, so I'd like to share
> the following list of packages to save you some time.

Great tool. Does someone have the resources to run it regularly (i.e.
daily), dump the results and the diff-to-previous run somewhere and link
the status (currently building/not building) on the hackage package?
More CI-like data and testing is always good!

I will give it a try in a few days, see if it is possible for me to do it daily.

Thu
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Vo Minh Thu | 13 Jun 12:36 2013
Picon

Re: Testing invasive proposals with Hackager




2013/6/13 Vo Minh Thu <noteed <at> gmail.com>



2013/6/13 Joachim Breitner <mail <at> joachim-breitner.de>
Hi,

Am Donnerstag, den 13.06.2013, 09:59 +0800 schrieb Niklas Hambüchen:
> In many discussions we make guesses about how much code proposals like
> Functor => Monad would break.
>
> You can use https://github.com/dterei/Hackager to build all of Hackage
> (preferably in a VM).
>
> Of course many packages have external dependencies, so I'd like to share
> the following list of packages to save you some time.

Great tool. Does someone have the resources to run it regularly (i.e.
daily), dump the results and the diff-to-previous run somewhere and link
the status (currently building/not building) on the hackage package?
More CI-like data and testing is always good!

I will give it a try in a few days, see if it is possible for me to do it daily.

Thu

I just read this note on Hackager's README:

"For example, here is a run with GHC, no special options and using 4 threads (note that this generally takes a long time, i.e. a few days):"
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Niklas Hambüchen | 13 Jun 12:54 2013

Re: Testing invasive proposals with Hackager

On 13/06/13 18:36, Vo Minh Thu wrote:
> "For example, here is a run with GHC, no special options and using 4
> threads (note that this generally takes a long time, i.e. a few days):"

My builds finished in < 10 hours on an i7.
Maksymilian Owsianny | 13 Jun 18:30 2013
Picon

Re: Testing invasive proposals with Hackager

I was thinking about something similar some time ago, but not just
testing but also fixing things automatically. Taking for example
Semigroup => Monoid this would break in places where you have instance
for Monoid but don't have instance for Semigroup. But if you have
instance for Monoid making instance for Semigroup is straightforward:

instance Semigroup <TypeYouAreFixing> where
    (<>) = <copy code from mappend for that type>

I'm still kind of new to Haskell, so I'm not sure how hard such,
TemplateHaskell-like automagic migration tool, would be to make, but
I feel like such a tool would be of incredible importance for the
community. Because otherwise, without such thing, there are usually
two ways a language can evolve:
    1. Caring for backwards compatibility, and accumulating mistakes
       like that over time, and becoming more and more like crap.
    2. Making fixes that break everyones code, and because of that
       being ignored by the industry.

I like Haskell because it usually takes the second route, but as
community grows it will be less and less the case. With such a tool
you could have best of both worlds.

Though I assume that somebody already thought of that and come to the
conclusion that in general case you cannot make such tool because
Gödel is a bastard that breaks everyones toys, or something along this
lines.



On Thu, Jun 13, 2013 at 12:54 PM, Niklas Hambüchen <mail <at> nh2.me> wrote:
On 13/06/13 18:36, Vo Minh Thu wrote:
> "For example, here is a run with GHC, no special options and using 4
> threads (note that this generally takes a long time, i.e. a few days):"

My builds finished in < 10 hours on an i7.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
AlanKim Zimmerman | 13 Jun 20:45 2013
Picon

Re: Testing invasive proposals with Hackager

Roman Cheplyaka has written a tool called HasFix for updating source based on new versions of libraries.

The presentation on it is here http://ro-che.info/docs/ and the code is at https://github.com/feuerbach/hasfix

Perhaps it could be pressed into use for automatic update of historical code?

Alan



On Thu, Jun 13, 2013 at 6:30 PM, Maksymilian Owsianny <maksymilian.owsianny <at> gmail.com> wrote:
I was thinking about something similar some time ago, but not just
testing but also fixing things automatically. Taking for example
Semigroup => Monoid this would break in places where you have instance
for Monoid but don't have instance for Semigroup. But if you have
instance for Monoid making instance for Semigroup is straightforward:

instance Semigroup <TypeYouAreFixing> where
    (<>) = <copy code from mappend for that type>

I'm still kind of new to Haskell, so I'm not sure how hard such,
TemplateHaskell-like automagic migration tool, would be to make, but
I feel like such a tool would be of incredible importance for the
community. Because otherwise, without such thing, there are usually
two ways a language can evolve:
    1. Caring for backwards compatibility, and accumulating mistakes
       like that over time, and becoming more and more like crap.
    2. Making fixes that break everyones code, and because of that
       being ignored by the industry.

I like Haskell because it usually takes the second route, but as
community grows it will be less and less the case. With such a tool
you could have best of both worlds.

Though I assume that somebody already thought of that and come to the
conclusion that in general case you cannot make such tool because
Gödel is a bastard that breaks everyones toys, or something along this
lines.



On Thu, Jun 13, 2013 at 12:54 PM, Niklas Hambüchen <mail <at> nh2.me> wrote:
On 13/06/13 18:36, Vo Minh Thu wrote:
> "For example, here is a run with GHC, no special options and using 4
> threads (note that this generally takes a long time, i.e. a few days):"

My builds finished in < 10 hours on an i7.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Maksymilian Owsianny | 14 Jun 00:13 2013
Picon

Re: Testing invasive proposals with Hackager

Hmm... I'll have to look into it, but it looks promising. Now if we
could make hackage run such fixes automatically whilst sending pull
requests to authors... then maybe we could even fix The Great Num
Fiasco of 98.


On Thu, Jun 13, 2013 at 8:45 PM, AlanKim Zimmerman <alan.zimm <at> gmail.com> wrote:
Roman Cheplyaka has written a tool called HasFix for updating source based on new versions of libraries.

The presentation on it is here http://ro-che.info/docs/ and the code is at https://github.com/feuerbach/hasfix

Perhaps it could be pressed into use for automatic update of historical code?

Alan



On Thu, Jun 13, 2013 at 6:30 PM, Maksymilian Owsianny <maksymilian.owsianny <at> gmail.com> wrote:
I was thinking about something similar some time ago, but not just
testing but also fixing things automatically. Taking for example
Semigroup => Monoid this would break in places where you have instance
for Monoid but don't have instance for Semigroup. But if you have
instance for Monoid making instance for Semigroup is straightforward:

instance Semigroup <TypeYouAreFixing> where
    (<>) = <copy code from mappend for that type>

I'm still kind of new to Haskell, so I'm not sure how hard such,
TemplateHaskell-like automagic migration tool, would be to make, but
I feel like such a tool would be of incredible importance for the
community. Because otherwise, without such thing, there are usually
two ways a language can evolve:
    1. Caring for backwards compatibility, and accumulating mistakes
       like that over time, and becoming more and more like crap.
    2. Making fixes that break everyones code, and because of that
       being ignored by the industry.

I like Haskell because it usually takes the second route, but as
community grows it will be less and less the case. With such a tool
you could have best of both worlds.

Though I assume that somebody already thought of that and come to the
conclusion that in general case you cannot make such tool because
Gödel is a bastard that breaks everyones toys, or something along this
lines.



On Thu, Jun 13, 2013 at 12:54 PM, Niklas Hambüchen <mail <at> nh2.me> wrote:
On 13/06/13 18:36, Vo Minh Thu wrote:
> "For example, here is a run with GHC, no special options and using 4
> threads (note that this generally takes a long time, i.e. a few days):"

My builds finished in < 10 hours on an i7.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Mateusz Kowalczyk | 14 Jun 00:52 2013
Picon

Re: Testing invasive proposals with Hackager


On 13/06/13 23:13, Maksymilian Owsianny wrote:
> Hmm... I'll have to look into it, but it looks promising. Now if
> we could make hackage run such fixes automatically whilst sending
> pull requests to authors... then maybe we could even fix The Great
> Num Fiasco of 98.
> 
> 
I don't know about automatic pull requests (perhaps e-mail to the
maintainer with a patch is a far better and easier to implement idea)
but something to let maintainers know that their package no longer
builds on GHC HEAD (per request of the maintainer) or with a new
proposal in place would be a very useful tool to have.

--

-- 
Mateusz K.
Roman Cheplyaka | 14 Jun 08:14 2013

Re: Testing invasive proposals with Hackager

To make it clear, it's not yet written, although I'll start spending
more time on it soon.

So far I've been working on the haskell-suite set of libraries that are
necessary to implement HasFix.
(https://github.com/haskell-suite)

Roman

* AlanKim Zimmerman <alan.zimm <at> gmail.com> [2013-06-13 20:45:43+0200]
> Roman Cheplyaka has written a tool called HasFix for updating source based
> on new versions of libraries.
> 
> The presentation on it is here http://ro-che.info/docs/ and the code is at
> https://github.com/feuerbach/hasfix
> 
> Perhaps it could be pressed into use for automatic update of historical
> code?
> 
> Alan
> 
> 
> 
> On Thu, Jun 13, 2013 at 6:30 PM, Maksymilian Owsianny <
> maksymilian.owsianny <at> gmail.com> wrote:
> 
> > I was thinking about something similar some time ago, but not just
> > testing but also fixing things automatically. Taking for example
> > Semigroup => Monoid this would break in places where you have instance
> > for Monoid but don't have instance for Semigroup. But if you have
> > instance for Monoid making instance for Semigroup is straightforward:
> >
> > instance Semigroup <TypeYouAreFixing> where
> >     (<>) = <copy code from mappend for that type>
> >
> > I'm still kind of new to Haskell, so I'm not sure how hard such,
> > TemplateHaskell-like automagic migration tool, would be to make, but
> > I feel like such a tool would be of incredible importance for the
> > community. Because otherwise, without such thing, there are usually
> > two ways a language can evolve:
> >     1. Caring for backwards compatibility, and accumulating mistakes
> >        like that over time, and becoming more and more like crap.
> >     2. Making fixes that break everyones code, and because of that
> >        being ignored by the industry.
> >
> > I like Haskell because it usually takes the second route, but as
> > community grows it will be less and less the case. With such a tool
> > you could have best of both worlds.
> >
> > Though I assume that somebody already thought of that and come to the
> > conclusion that in general case you cannot make such tool because
> > Gödel is a bastard that breaks everyones toys, or something along this
> > lines.
> >
> >
> >
> > On Thu, Jun 13, 2013 at 12:54 PM, Niklas Hambüchen <mail <at> nh2.me> wrote:
> >
> >> On 13/06/13 18:36, Vo Minh Thu wrote:
> >> > "For example, here is a run with GHC, no special options and using 4
> >> > threads (note that this generally takes a long time, i.e. a few days):"
> >>
> >> My builds finished in < 10 hours on an i7.
> >>
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe <at> haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe <at> haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >

> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane