RE: [ANNOUNCE] Shaking up GHC

[Simon Peyton Jones]

Very good.

As I understand it, it can work side-by-side with the existing build system, 
correct?  That means we don't need to make an either/or choice, which is very 
helpful.

Every day I do
sh validate --fast --no-clean
How can I do that using Shake to build?  Maybe
sh validate --shake --fast --no-clean
or something?  Just modifying the validate script to make it convenient to use 
shake for the build part would be great.

You say: The make-based build system uses mk/build.mk to specify user build 
settings. We use src/Settings/User.hs for the same purpose. Feel free to 
experiment following the Haddock comments.

But User.hs is a source file, which we shouldn't normally modify lest we 
accidentally commit it.  Could we have a non-source file to modify (rather like 
build.mk being based on build.mk.sample)

Simon

|  -Original Message-
|  From: Andrey Mokhov [mailto:andrey.mok...@newcastle.ac.uk]
|  Sent: 22 January 2016 14:27
|  To: ghc-devs@haskell.org
|  Cc: Simon Peyton Jones ; Neil Mitchell
|  ; Simon Marlow 
|  Subject: [ANNOUNCE] Shaking up GHC
|  
|  Dear GHC developers,
|  
|  I am happy to announce that the Shaking up GHC project has finally
|  reached the first milestone. The goal of the project is to design a
|  new GHC build system based on Shake that will eventually replace the
|  current make-based one. See the project page for more details:
|  https://github.com/snowleopard/shaking-up-ghc.
|  
|  There is still a long way until we can match the capabilities of the
|  current build system. At the moment we only build vanilla way.
|  Validation, documentation, build flavours and cross-compilation are
|  not yet implemented. Known limitations are listed here:
|  https://github.com/snowleopard/shaking-up-ghc#current-limitations.
|  
|  The purpose of this announcement is to attract alpha testers and
|  collect early feedback across multiple platforms and build
|  configurations. We already have several success reports on Linux, OS
|  X, Solaris and Windows. However, things will inevitably break and we
|  hope to catch and fix as many of these cases as possible with your
|  help. The instructions on how to try the new build system can be found
|  here: https://github.com/snowleopard/shaking-up-ghc#your-first-build.
|  
|  We plan to be ready to become a part of the GHC tree around 1 March
|  2016, and catch up with the make build system around 1 June 2016. The
|  dates are tentative and depend on how much time it takes us to resolve
|  the remaining issues: https://github.com/snowleopard/shaking-up-
|  ghc/milestones.
|  
|  I would like thank everyone who contributed to this project so far:
|  Simon Peyton Jones, Neil Mitchell and Simon Marlow came up with the
|  idea and guided me throughout the project; Moritz Angermann, Ben
|  Gamari, Karel Gardas, David Luposchainsky, and Neil Mitchell
|  contributed to the codebase. Thank you all!
|  
|  Kind regards,
|  Andrey

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

Re: a reliable way of dropping levity args?

[Richard Eisenberg]

As discussed on IRC, your approach below looks right to me: dropWhile 
(isLevityTy . idType) args. But you then said this wasn't working for you. What 
does (map idType args) say?

Richard

On Jan 24, 2016, at 8:58 PM, Ömer Sinan Ağacan  wrote:

> Hi all,
> 
> I'm looking for a reliable way of dropping levity args from TyCon 
> applications.
> When I know that a particular TyCon gets some number of levity args, I can 
> just
> drop the args manually (for example, I can drop the first half of arguments of
> a tuple TyCon application) but the code looks fragile (what happens if I use a
> different TyCon in the future) and confusing to the reader because it looks
> like this:
> 
>drop (length args `div` 2) args
> 
> Ideally it'd look like this:
> 
>dropWhile isLevityArg args
> 
> Now, there's a function called isLevityTy, but I don't understand what it's
> supposed to do. This doesn't do anyting to 'Boxed and 'Unboxed arguments:
> 
>dropWhile (isLevityArg . idType) args
> 
> Any ideas on this?
> 
> Thanks..

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

Re: Type class for sanity

[Richard Eisenberg]

+1

This would be very easy to implement, too.

But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? 
ValueType? I don't love any of these, but I love Sane less.

On Jan 24, 2016, at 4:24 PM, David Feuer  wrote:

> Since type families can be stuck, it's sometimes useful to restrict
> things to sane types. At present, the most convenient way I can see to
> do this in general is with Typeable:
> 
> type family Foo x where
>  Foo 'True = Int
> 
> class Typeable (Foo x) => Bar x where
>  blah :: proxy x -> Foo x
> 
> This will prevent anyone from producing the bogus instance
> 
> instance Bar 'False where
>  blah _ = undefined
> 
> Unfortunately, the Typeable constraint carries runtime overhead. One
> possible way around this, I think, is with a class that does just
> sanity checking and nothing more:
> 
> class Sane (a :: k)
> instance Sane Int
> instance Sane Char
> instance Sane 'False
> instance Sane 'True
> instance Sane '[]
> instance Sane '(:)
> instance Sane (->)
> instance Sane 'Just
> instance Sane 'Nothing
> instance (Sane f, Sane x) => Sane (f x)
> 
> To really do its job properly, Sane would need to have instances for
> all sane types and no more. An example of an insane instance of Sane
> would be
> 
> instance Sane (a :: MyKind)
> 
> which would include stuck types of kind MyKind.
> 
> Would it be useful to add such an automatic-only class to GHC?
> 
> David
> ___
> Libraries mailing list
> librar...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: Type class for sanity

[David Feuer]

I don't care about the name at all. Unstuck? Would we want to distinguish
between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful?
On Jan 25, 2016 7:34 AM, "Richard Eisenberg"  wrote:

> +1
>
> This would be very easy to implement, too.
>
> But I suggest a different name. Ground? Terminating? NormalForm?
> Irreducible? ValueType? I don't love any of these, but I love Sane less.
>
> On Jan 24, 2016, at 4:24 PM, David Feuer  wrote:
>
> > Since type families can be stuck, it's sometimes useful to restrict
> > things to sane types. At present, the most convenient way I can see to
> > do this in general is with Typeable:
> >
> > type family Foo x where
> >  Foo 'True = Int
> >
> > class Typeable (Foo x) => Bar x where
> >  blah :: proxy x -> Foo x
> >
> > This will prevent anyone from producing the bogus instance
> >
> > instance Bar 'False where
> >  blah _ = undefined
> >
> > Unfortunately, the Typeable constraint carries runtime overhead. One
> > possible way around this, I think, is with a class that does just
> > sanity checking and nothing more:
> >
> > class Sane (a :: k)
> > instance Sane Int
> > instance Sane Char
> > instance Sane 'False
> > instance Sane 'True
> > instance Sane '[]
> > instance Sane '(:)
> > instance Sane (->)
> > instance Sane 'Just
> > instance Sane 'Nothing
> > instance (Sane f, Sane x) => Sane (f x)
> >
> > To really do its job properly, Sane would need to have instances for
> > all sane types and no more. An example of an insane instance of Sane
> > would be
> >
> > instance Sane (a :: MyKind)
> >
> > which would include stuck types of kind MyKind.
> >
> > Would it be useful to add such an automatic-only class to GHC?
> >
> > David
> > ___
> > Libraries mailing list
> > librar...@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: [ANNOUNCE] Shaking up GHC

[Ben Gamari]

Simon Peyton Jones  writes:

> Very good.
>
> As I understand it, it can work side-by-side with the existing build
> system, correct? That means we don't need to make an either/or choice,
> which is very helpful.
>
> Every day I do sh validate --fast --no-clean How can I do that using
>   Shake to build? Maybe sh validate --shake --fast --no-clean or
>   something? Just modifying the validate script to make it convenient
>   to use shake for the build part would be great.
>
> You say: The make-based build system uses mk/build.mk to specify user
> build settings. We use src/Settings/User.hs for the same purpose. Feel
> free to experiment following the Haddock comments.
>
> But User.hs is a source file, which we shouldn't normally modify lest
> we accidentally commit it. Could we have a non-source file to modify
> (rather like build.mk being based on build.mk.sample)
>
One way around this would be to add User.hs to .gitignore. That way git
will ignore changes to this files when you `git commit -a`. You can
still, however, commit changes to it if you ask git explicitly.

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: Type class for sanity

[Richard Eisenberg]

Might be nice to have whnf too, while we're at it. Perhaps whnf is enough for 
someone and going all the way to nf would be less efficient / impossible.

Richard

On Jan 25, 2016, at 8:44 AM, David Feuer  wrote:

> I don't care about the name at all. Unstuck? Would we want to distinguish 
> between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful?
> 
> On Jan 25, 2016 7:34 AM, "Richard Eisenberg"  wrote:
> +1
> 
> This would be very easy to implement, too.
> 
> But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? 
> ValueType? I don't love any of these, but I love Sane less.
> 
> On Jan 24, 2016, at 4:24 PM, David Feuer  wrote:
> 
> > Since type families can be stuck, it's sometimes useful to restrict
> > things to sane types. At present, the most convenient way I can see to
> > do this in general is with Typeable:
> >
> > type family Foo x where
> >  Foo 'True = Int
> >
> > class Typeable (Foo x) => Bar x where
> >  blah :: proxy x -> Foo x
> >
> > This will prevent anyone from producing the bogus instance
> >
> > instance Bar 'False where
> >  blah _ = undefined
> >
> > Unfortunately, the Typeable constraint carries runtime overhead. One
> > possible way around this, I think, is with a class that does just
> > sanity checking and nothing more:
> >
> > class Sane (a :: k)
> > instance Sane Int
> > instance Sane Char
> > instance Sane 'False
> > instance Sane 'True
> > instance Sane '[]
> > instance Sane '(:)
> > instance Sane (->)
> > instance Sane 'Just
> > instance Sane 'Nothing
> > instance (Sane f, Sane x) => Sane (f x)
> >
> > To really do its job properly, Sane would need to have instances for
> > all sane types and no more. An example of an insane instance of Sane
> > would be
> >
> > instance Sane (a :: MyKind)
> >
> > which would include stuck types of kind MyKind.
> >
> > Would it be useful to add such an automatic-only class to GHC?
> >
> > David
> > ___
> > Libraries mailing list
> > librar...@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> 

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

RE: Type class for sanity

[Simon Peyton Jones]

I’m a bit dubious about whether it’s worth the effort of making this an 
extension that requires GHC support. Does the gain justify the (maybe-small but 
eternal) pain

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard 
Eisenberg
Sent: 25 January 2016 14:06
To: David Feuer 
Cc: Haskell Libraries ; ghc-devs 
Subject: Re: Type class for sanity

Might be nice to have whnf too, while we're at it. Perhaps whnf is enough for 
someone and going all the way to nf would be less efficient / impossible.

Richard

On Jan 25, 2016, at 8:44 AM, David Feuer 
mailto:david.fe...@gmail.com>> wrote:



I don't care about the name at all. Unstuck? Would we want to distinguish 
between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful?
On Jan 25, 2016 7:34 AM, "Richard Eisenberg" 
mailto:e...@cis.upenn.edu>> wrote:
+1

This would be very easy to implement, too.

But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? 
ValueType? I don't love any of these, but I love Sane less.

On Jan 24, 2016, at 4:24 PM, David Feuer 
mailto:david.fe...@gmail.com>> wrote:

> Since type families can be stuck, it's sometimes useful to restrict
> things to sane types. At present, the most convenient way I can see to
> do this in general is with Typeable:
>
> type family Foo x where
>  Foo 'True = Int
>
> class Typeable (Foo x) => Bar x where
>  blah :: proxy x -> Foo x
>
> This will prevent anyone from producing the bogus instance
>
> instance Bar 'False where
>  blah _ = undefined
>
> Unfortunately, the Typeable constraint carries runtime overhead. One
> possible way around this, I think, is with a class that does just
> sanity checking and nothing more:
>
> class Sane (a :: k)
> instance Sane Int
> instance Sane Char
> instance Sane 'False
> instance Sane 'True
> instance Sane '[]
> instance Sane '(:)
> instance Sane (->)
> instance Sane 'Just
> instance Sane 'Nothing
> instance (Sane f, Sane x) => Sane (f x)
>
> To really do its job properly, Sane would need to have instances for
> all sane types and no more. An example of an insane instance of Sane
> would be
>
> instance Sane (a :: MyKind)
>
> which would include stuck types of kind MyKind.
>
> Would it be useful to add such an automatic-only class to GHC?
>
> David
> ___
> Libraries mailing list
> librar...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: Type class for sanity

[Richard Eisenberg]

Yes, if we can arrange that Ground a implies that Equals a [a] reduces to 
False, with

type family Equals a b where
  Equals a a = True
  Equals a b = False

But getting that to work is admittedly a feature beyond what's proposed.

On Jan 25, 2016, at 9:21 AM, Simon Peyton Jones  wrote:

> I’m a bit dubious about whether it’s worth the effort of making this an 
> extension that requires GHC support. Does the gain justify the (maybe-small 
> but eternal) pain
>  
> Simon
>  
> From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard 
> Eisenberg
> Sent: 25 January 2016 14:06
> To: David Feuer 
> Cc: Haskell Libraries ; ghc-devs 
> Subject: Re: Type class for sanity
>  
> Might be nice to have whnf too, while we're at it. Perhaps whnf is enough for 
> someone and going all the way to nf would be less efficient / impossible.
>  
> Richard
>  
> On Jan 25, 2016, at 8:44 AM, David Feuer  wrote:
> 
> 
> I don't care about the name at all. Unstuck? Would we want to distinguish 
> between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful?
> 
> On Jan 25, 2016 7:34 AM, "Richard Eisenberg"  wrote:
> +1
> 
> This would be very easy to implement, too.
> 
> But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? 
> ValueType? I don't love any of these, but I love Sane less.
> 
> On Jan 24, 2016, at 4:24 PM, David Feuer  wrote:
> 
> > Since type families can be stuck, it's sometimes useful to restrict
> > things to sane types. At present, the most convenient way I can see to
> > do this in general is with Typeable:
> >
> > type family Foo x where
> >  Foo 'True = Int
> >
> > class Typeable (Foo x) => Bar x where
> >  blah :: proxy x -> Foo x
> >
> > This will prevent anyone from producing the bogus instance
> >
> > instance Bar 'False where
> >  blah _ = undefined
> >
> > Unfortunately, the Typeable constraint carries runtime overhead. One
> > possible way around this, I think, is with a class that does just
> > sanity checking and nothing more:
> >
> > class Sane (a :: k)
> > instance Sane Int
> > instance Sane Char
> > instance Sane 'False
> > instance Sane 'True
> > instance Sane '[]
> > instance Sane '(:)
> > instance Sane (->)
> > instance Sane 'Just
> > instance Sane 'Nothing
> > instance (Sane f, Sane x) => Sane (f x)
> >
> > To really do its job properly, Sane would need to have instances for
> > all sane types and no more. An example of an insane instance of Sane
> > would be
> >
> > instance Sane (a :: MyKind)
> >
> > which would include stuck types of kind MyKind.
> >
> > Would it be useful to add such an automatic-only class to GHC?
> >
> > David
> > ___
> > Libraries mailing list
> > librar...@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> 

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

RE: vectorisation code?

[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: dynamic linking and GHC 8.0.1 User's Guide

[Ben Gamari]

George Colpitts  writes:

> I believe that static linking will produce a faster program, at least in
> some situations. If so it would be good to mention this in section 8.2 of
> the user's guide, *Faster: producing a program that runs quicker,  *
>
> I couldn't find documentation for the -dynamic-too option of GHC. If it
> isn't there it would be good to document. I looked in the index, and
> sections 6.11.5. *Options affecting code generation, *and  6.11.6. *Options
> affecting linking.*
>
Oh dear, indeed this flag appears to be entirely undocumented. I've
opened #11488 to ensure we don't lose from of this.

> Is there a pdf version of the GHC 8.0.1 User's Guide? It' much easier to
> search in the pdf version. 8.0.1 rc1 just has an html version but perhaps
> there is a pdf version available on the web somewhere. I assume the final
> version of 8.0.1 will have a pdf version.
>
I'll need to look at the documentation situation. While things largely "just
work" on our Linux platforms, LaTeX is quite a pain on OS X and Windows.
This makes producing the PDF user guide quite tricky. When I built rc1 I
spent a quite bit of time trying to work out some mysterious font issues
on OS X but in the end ran out of time and had to drop it.

One option (although unsavory) would be to simply plop the PDF from the
Linux build into the OS X and Windows tarballs. I would really prefer to
avoid this, however, as this presents yet another barrier to a
completely automated build, which is my eventual goal.

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: dynamic linking and GHC 8.0.1 User's Guide

[Ben Gamari]

George Colpitts  writes:

> I believe that static linking will produce a faster program, at least in
> some situations. If so it would be good to mention this in section 8.2 of
> the user's guide, *Faster: producing a program that runs quicker,  *
>
Indeed it would be a good idea to mention this. Would you like to write
up a patch?

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: Type class for sanity

[David Feuer]

You're correct. Please forget that name.
On Jan 25, 2016 12:33 PM, "wren romano"  wrote:

> On Mon, Jan 25, 2016 at 7:34 AM, Richard Eisenberg 
> wrote:
> > But I suggest a different name. Ground? Terminating? NormalForm?
> Irreducible? ValueType? I don't love any of these, but I love Sane less.
>
> I'm also strongly opposed to using "sane". That name is ableist and
> quite offputting to many Haskellers I know (myself included). To say
> nothing of the fact that the name doesn't provide any useful
> understanding of what precisely it's supposed to be categorizing.
>
> --
> Live well,
> ~wren
> ___
> Libraries mailing list
> librar...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: [ANNOUNCE] Shaking up GHC

[Andrey Mokhov]

Simon,

> As I understand it, it can work side-by-side with the existing build
> system, correct?  That means we don't need to make an either/or
> choice, which is very helpful.

That's correct. Note though that the two build systems put (some) build results 
in the same directories, e.g. inplace/bin/ghc-stage1, so there is some 
interaction between them. In future it would be possible to decouple them 
completely (if need be).

> How can I do that using Shake to build?  Maybe
>   sh validate --shake --fast --no-clean
> or something?  Just modifying the validate script to make it
> convenient to use shake for the build part would be great.

This may be possible precisely because binaries are where validate expects them 
to be. I tried to pull this off, but unsuccessfully so far (validate starts 
rebuilding everything from scratch with make). I think the reason is that we 
changed some naming conventions for directories (using stageN instead of dist, 
dist-boot, dist-install), so validate can't find some utils. I'll let you know 
if I find a workaround. Otherwise we'll just have to wait for the proper 
implementation of the "test" target in the new build system. Maybe it's not too 
difficult to implement.

Ben,

> > But User.hs is a source file, which we shouldn't normally modify lest 
> > we accidentally commit it. Could we have a non-source file to modify 
> > (rather like build.mk being based on build.mk.sample)
> >
> One way around this would be to add User.hs to .gitignore. That way git
> will ignore changes to this files when you `git commit -a`. You can still,
> however, commit changes to it if you ask git explicitly.

Yes, I was thinking about the same idea. 

Cheers,
Andrey

-Original Message-
From: Simon Peyton Jones [mailto:simo...@microsoft.com] 
Sent: 25 January 2016 12:14
To: Andrey Mokhov ; ghc-devs@haskell.org
Cc: Neil Mitchell ; Simon Marlow 
Subject: RE: [ANNOUNCE] Shaking up GHC

Very good.

As I understand it, it can work side-by-side with the existing build system, 
correct?  That means we don't need to make an either/or choice, which is very 
helpful.

Every day I do
sh validate --fast --no-clean
How can I do that using Shake to build?  Maybe
sh validate --shake --fast --no-clean
or something?  Just modifying the validate script to make it convenient to use 
shake for the build part would be great.

You say: The make-based build system uses mk/build.mk to specify user build 
settings. We use src/Settings/User.hs for the same purpose. Feel free to 
experiment following the Haddock comments.

But User.hs is a source file, which we shouldn't normally modify lest we 
accidentally commit it.  Could we have a non-source file to modify (rather like 
build.mk being based on build.mk.sample)

Simon

|  -Original Message-
|  From: Andrey Mokhov [mailto:andrey.mok...@newcastle.ac.uk]
|  Sent: 22 January 2016 14:27
|  To: ghc-devs@haskell.org
|  Cc: Simon Peyton Jones ; Neil Mitchell  
| ; Simon Marlow 
|  Subject: [ANNOUNCE] Shaking up GHC
|  
|  Dear GHC developers,
|  
|  I am happy to announce that the Shaking up GHC project has finally  
| reached the first milestone. The goal of the project is to design a  
| new GHC build system based on Shake that will eventually replace the  
| current make-based one. See the project page for more details:
|  https://github.com/snowleopard/shaking-up-ghc.
|  
|  There is still a long way until we can match the capabilities of the  
| current build system. At the moment we only build vanilla way.
|  Validation, documentation, build flavours and cross-compilation are  
| not yet implemented. Known limitations are listed here:
|  https://github.com/snowleopard/shaking-up-ghc#current-limitations.
|  
|  The purpose of this announcement is to attract alpha testers and  
| collect early feedback across multiple platforms and build  
| configurations. We already have several success reports on Linux, OS  
| X, Solaris and Windows. However, things will inevitably break and we  
| hope to catch and fix as many of these cases as possible with your  
| help. The instructions on how to try the new build system can be found
|  here: https://github.com/snowleopard/shaking-up-ghc#your-first-build.
|  
|  We plan to be ready to become a part of the GHC tree around 1 March  
| 2016, and catch up with the make build system around 1 June 2016. The  
| dates are tentative and depend on how much time it takes us to resolve  
| the remaining issues: https://github.com/snowleopard/shaking-up-
|  ghc/milestones.
|  
|  I would like thank everyone who contributed to this project so far:
|  Simon Peyton Jones, Neil Mitchell and Simon Marlow came up with the  
| idea and guided me throughout the project; Moritz Angermann, Ben  
| Gamari, Karel Gardas, David Luposchainsky, and Neil Mitchell  
| contributed to the codebase. Thank you all!
|  
|  Kind regards,
|  Andrey

___
ghc-devs mailing list
ghc-devs@