2013/6/13 Vo Minh Thu

2013/6/13 Joachim Breitner

...

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):"

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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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 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@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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

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 [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@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 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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

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