Re: [ANNOUNCE] Shaking up GHC

[Joe Hillenbrand]

>
> cabal install alex happy ansi-terminal mtl shake QuickCheck
>>
>
>
It likely won't be that simple due to versioning issues.  It's entirely
> possible that GHC will work only with certain versions of some of these
> libraries (and not necessarily the latest ones), so the build may fail at
> certain times and under certain conditions for some users.


This is exactly why I added build.stack.sh to shaking-up-ghc, to mitigate
these kinds of issues.
https://github.com/snowleopard/shaking-up-ghc/blob/master/build.stack.sh

Personally, I think the shake build system should default to stack because
it is the best way to get consistent builds.

On Tue, Jan 26, 2016 at 2:33 AM, Simon Marlow  wrote:

>
>
> On 23 January 2016 at 21:17, Andrey Mokhov 
> wrote:
>
>> Herbert,
>>
>> > I think it's already quite convenient. After all, you're expected to
>> > have a minimum GHC bootstrapping environment anyway. So having the
>> > tools installed (as already do now, e.g. you need alex, happy, and
>> > ghc to be able to work on GHC).
>>
>> I agree. Roughly, we are talking about going from:
>>
>> cabal install alex happy
>>
>> to:
>>
>> cabal install alex happy ansi-terminal mtl shake QuickCheck
>>
>
> It likely won't be that simple due to versioning issues.  It's entirely
> possible that GHC will work only with certain versions of some of these
> libraries (and not necessarily the latest ones), so the build may fail at
> certain times and under certain conditions for some users.  The configure
> script will already have to check for compatible versions, like it does for
> alex/happy.  That's the reason we bundle things, it reduces the possibility
> for failure.
>
> It's a complicated tradeoff, but if the GHC build system became tightly
> coupled to Shake in the way that it is with Cabal, then bundling would
> probably be the right thing to do.
>
> Cheers,
> Simon
>
>
>> This doesn't look too onerous (although one could also consider
>> somehow packaging these dependencies together). And hopefully
>> upcoming cabal features will make this more robust.
>>
>> Tuncer,
>>
>> > My suggestion, and what I'd expect, is to make Shake part of
>> > GHC's included lib, just like process or xhtml.
>>
>> This sounds like a very big decision which is beyond the Shaking
>> up GHC project. (I wouldn't want to shake up GHC too much!)
>>
>> Cheers,
>> Andrey
>>
>> > -Original Message-
>> > From: Herbert Valerio Riedel [mailto:hvrie...@gmail.com]
>> > Sent: 23 January 2016 17:14
>> > To: Andrey Mokhov
>> > Cc: dluposchain...@googlemail.com; GHC developers
>> > Subject: Re: [ANNOUNCE] Shaking up GHC
>> >
>> > On 2016-01-23 at 14:05:56 +0100, Andrey Mokhov wrote:
>> > >> Are there any plans as to how to include it in the GHC tree? Does it
>> > >> ship with all the libraries required to build the build system, will
>> > we
>> > >> have a mini-build system to bootstrap it? If I recall correctly, we
>> > rely
>> > >> on Cabal sandboxes on Linux/OSX and global Cabal library
>> > >> installations on Windows in order to run it.
>> > >
>> > > The simplest way is to add the 'shake-build' folder to the GHC tree
>> > and
>> > > ask first adopters of the new build system to globally install the
>> > > dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh'
>> > > and 'build.bat' scripts should work.
>> > >
>> > > I am open to suggestions on how to make this more convenient and
>> > > robust. I've never used anything more advanced than a global cabal
>> > > installation, so I'd appreciate input from more experienced users.
>> >
>> > I think it's already quite convenient. After all, you're expected to
>> > have a minimum GHC bootstrapping environment anyway. So having the
>> > tools
>> > installed (as already do now, e.g. you need alex, happy, and ghc to be
>> > able to work on GHC).
>> >
>> > And the new cabal nix-store feature to show-case as tech-preview
>> > together with GHC 8.0 makes this even more robust by avoiding pkg-db
>> > breakages due to reinstalls, which would be the main reason not to
>> > rely on "global installed dependency".
>> >
>> > The shake-build.sh script simply needs to invoke `cabal new-build` to
>> > generate the ghc shake build-tool executable.
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

[Joe Hillenbrand]

> As a wild idea -- did anyone look at /Gitlab/ instead?

My personal experience with Gitlab at a previous job is that it is
extremely unstable. I'd say even more unstable than trac and
phabricator. It's especially bad when dealing with long files.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Weekly News - 2015/04/14

[Joe Hillenbrand]

Found the thread:
https://mail.haskell.org/pipermail/ghc-devs/2014-October/006599.html

On Tue, Apr 14, 2015 at 12:07 PM, Joe Hillenbrand joehil...@gmail.com wrote:
 == Call for help: DocBook to AsciiDoc ==

 So, we're asking the public: Is anyone willing to step up and help
 here? For example, it may be possible to get a long ways with just
 `pandoc`, but we need someone to finish it - and in return, we'll help
 along the way!


 Do you have anymore information on this? Tickets? Current status? This
 is the first I've heard about the proposed conversion, and I follow
 ghc-devs@ pretty closely.

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

Re: GHC support for the new record package

[Joe Hillenbrand]

On Jan 22, 2015 8:12 PM, Johan Tibell johan.tib...@gmail.com wrote:



 On Wed, Jan 21, 2015 at 5:48 PM, Simon Marlow marlo...@gmail.com wrote:

 On 21/01/2015 16:01, Johan Tibell wrote:

 My thoughts mostly mirror those of Adam and Edward.

 1) I want something that is backwards compatible.


 Backwards compatible in what sense?  Extension flags provide backwards
compatibility, because you just don't turn on the extension until you want
to use it.  That's how all the other extensions work; most of them change
syntax in some way or other that breaks existing code.


 In this case in the sense of avoiding splitting code into a new-Haskell
vs old-Haskell. This means that existing records should work well (and
ideally also get the improved name resolution when used in call sites that
have the pragma enabled) in the new record system.


Sorry to chime in since I am not an expert or ghc contributor, but I can't
see how the new record system would break any existing valid Haskell code
even if it was added wholesale without a language extension (and without
special {|...|} syntax). I can see how expected behavior and error messages
would change, but not any existing records or accessors.

Would anyone mind explaining what would break?

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