Re: Tentative high-level plans for 7.10.1

[Herbert Valerio Riedel]

On 2014-10-08 at 02:13:01 +0200, Carter Schonwald wrote:
> the checkout process for the 7.8 branch is a bit involved (and NB: you
> really want to use a different tree than one for working on head, the
> checkout process is different
> )
>
> $ git clone -b ghc-7.8 git://git.haskell.org/ghc.git ghc-7.8TREE
> $ cd ghc-7.8TREE/
> $ ./sync-all   get -b ghc-7.8
>
> (theres no need for a lot of this with HEAD)

Just to clarify/remind why this is needed:

The GHC 7.8 branch was not converted to a proper submodule-only scheme
like GHC HEAD was.  Unless we keep maintaining GHC 7.8 for longer than a
7.8.4 release, this irregularity will become less of a concern, as the
stable GHC 7.10 branch will be switchable to/from later branches such as
GHC 7.12/HEAD w/o requiring a separately cloned tree.

However, should GHC 7.8.x turn out to become a LTS-ishly maintained
branch, we may want to consider converting it to a similiar Git
structure as GHC HEAD currently is, to avoid having to keep two
different sets of instructions on the GHC Wiki for how to work on GHC
7.8 vs working on GHC HEAD/7.10 and later.

Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Source-markup language for GHC User's Guide

[Tuncer Ayaz]

On Tue, Oct 7, 2014 at 5:20 PM, Herbert Valerio Riedel wrote:
> Hello GHC Developers & GHC User's Guide writers,
>
> I assume it is common knowledge to everyone here, that the GHC
> User's Guide is written in Docbook XML markup.
>
> However, it's a bit tedious to write Docbook-XML by hand, and the
> XML markup is not as lightweight as modern state-of-the-art markup
> languages designed for being edited in a simple text-editor are.
>
> Therefore I'd like to hear your opinion on migrating away from the
> current Docbook XML markup to some other similarly expressive but
> yet more lightweight markup documentation system such as Asciidoc[1]
> or ReST/Sphinx[2].
>
> There's obviously some cost involved upfront for a (semi-automatic)
> conversion[3]. So one important question is obviously whether the
> long-term benefits outweight the cost/investment that we'd incur for
> the initial conversion.
>
> All suggestions/comments/worries welcome; please commence
> brainstorming :)

Given the choices (and existing Docbook files), I would select AsciiDoc.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GitHub pull requests

[Tuncer Ayaz]

On Tue, Oct 7, 2014 at 8:42 PM, Joachim Breitner wrote:
> doesn't look like that will happen soon:
>
>
> > Hey Joachim,
> >
> > Disabling that linking is not possible currently, and I'm not sure
> > if that feature will be available in the near future. Still, I'll
> > add your request to our feature request wishlist and pass the
> > feedback to the team.
> >
> > Thanks for the question/suggestion and let us know if there's
> > anything else.

That's unsurprising, given how that linking scheme is used everywhere,
but they responded quickly.

I've sent them suggestions on improving the review system, and they
have acknowledged working on that, but it's a behind closed doors
development process without any pre-announcement or commitment.

Another popular request is for projects like GHC or similar (that have
their own or different infrastructure for discussion and
contributions) to want to disable Pull-Requests (like Wiki or Issues).
They say it's often requested but have no immediate plans to add a
check box. It's unfortunate because you have to constantly close pull
requests with a link to the contributing guide.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Source-markup language for GHC User's Guide

[Jan Stolarek]

> Therefore I'd like to hear your opinion on migrating away from the
> current Docbook XML markup to some other similarly expressive but yet
> more lightweight markup documentation system such as Asciidoc[1] or
> ReST/Sphinx[2].
My opinion is that I don't really care. I only edit the User Guide once every 
couple of months or 
so. I don't have problems with Docbook but if others want something else I can 
adjust.

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

Re: RFC: Source-markup language for GHC User's Guide

[Johan Tibell]

Same here. My interaction with the user guide is infrequent enough that it
doesn't matter much to me.

On Wed, Oct 8, 2014 at 10:49 AM, Jan Stolarek 
wrote:

> > Therefore I'd like to hear your opinion on migrating away from the
> > current Docbook XML markup to some other similarly expressive but yet
> > more lightweight markup documentation system such as Asciidoc[1] or
> > ReST/Sphinx[2].
> My opinion is that I don't really care. I only edit the User Guide once
> every couple of months or
> so. I don't have problems with Docbook but if others want something else I
> can adjust.
>
> Janek
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Windows build broken (again)

[Simon Peyton Jones]

yes it seems fine now, thanks.

Simon

From: Krzysztof Gogolewski [mailto:krz.gogolew...@gmail.com]
Sent: 03 October 2014 19:05
To: Herbert Valerio Riedel
Cc: Simon Peyton Jones; ghc-devs@haskell.org
Subject: Re: Windows build broken (again)

Python 3 is a likely culprit (though I couldn't confirm it), so I reverted it. 
Does it work now?

On Fri, Oct 3, 2014 at 5:51 PM, Herbert Valerio Riedel 
mailto:hvrie...@gmail.com>> wrote:
On 2014-10-03 at 17:29:31 +0200, Simon Peyton Jones wrote:
> Perhaps, yes, it is Python 3. I don't know.  Could someone revert to
> make it work again, please?

Fyi, I can't reproduce this specific problem on Cygwin at least (I don't
have any working pure Msys2 environment yet (still working on it), as
this may exactly be the kind of failure I'd expect Msys2 to be prone to
while Cygwin to be unaffected by).

What I tried in order to reproduce:

  $ git rev-parse HEAD
  084d241b316bfa12e41fc34cae993ca276bf0730  # <-- this is the Py3/testsuite 
commit

  $ make TEST=tc012 WAY=normal
  ...
  => tc012(normal) 3039 of 4088 [0, 0, 0]
  cd ./typecheck/should_compile && 
'C:/cygwin64/home/ghc/ghc-hvr/inplace/bin/ghc-stage2.exe' -fforce-recomp 
-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts 
-fno-ghci-history -c tc012.hs   -fno-warn-incomplete-patterns 
>tc012.comp.stderr 2>&1

  OVERALL SUMMARY for test run started at Fri Oct  3 15:42:04 2014 GMT
   0:00:03 spent to go through
  4088 total tests, which gave rise to
 12360 test cases, of which
 12359 were skipped

 0 had missing libraries
 1 expected passes
 0 expected failures
  ...


And btw, with the latest GHC HEAD commit (and I suspect the recent
HEAP_ALLOCED-related commits to be responsible for that), I get a ton of
testsuite failures due to such errors:

  T8639_api.exe: Unknown PEi386 section name `staticclosures' (while 
processing: 
C:\cygwin64\home\ghc\ghc-hvr\libraries\ghc-prim\dist-install\build\HSghcpr_BE58KUgBe9ELCsPXiJ1Q2r.o)

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

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

RE: Tentative high-level plans for 7.10.1

[Simon Peyton Jones]

I think we need to work harder at getting volunteers to write tests
it would be great if we could get more people to document, i.e. write tutorials

Good ideas, thank you.  It would be great if you felt able to contribute to one 
or the other (or both) yourself.

Simon

From: George Colpitts [mailto:george.colpi...@gmail.com]
Sent: 08 October 2014 01:35
To: Simon Peyton Jones
Cc: Ben Gamari; Austin Seipp; ghc-devs@haskell.org; Simon Marlow
Subject: Re: Tentative high-level plans for 7.10.1

I agree a section show stoppers is a good idea, in parallel would it make sense 
to use the priority "highest" for tickets that we consider showstoppers?
Austin did a great of explaining the difficulties of backporting fixes, my 
reaction  is that we have to have higher quality releases so that ideally we 
have 0 backports. Having a showstoppers section will help that but I think we 
need to work harder at getting volunteers to write tests. For most people 
that's not exciting but it is a good way to get started on helping and would be 
an immense help in producing higher quality releases.
As Austin also pointed out things change rapidly, it's hard to keep up and it's 
getting harder for people to get to the point where they feel they are decent 
Haskell programmers. So in addition to testing it would be great if we could 
get more people to document, i.e. write tutorials etc.
It is difficult to balance being a research language and being a viable 
language for industrial use. FWIW, I personally feel that we side too much on 
being a research language.


On Tue, Oct 7, 2014 at 5:12 AM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Thanks for this debate.  (And thank you Austin for provoking it by articulating 
a medium term plan.)

Our intent has always been that that the latest version on each branch is 
solid.  There have been one or two occasions when we have knowingly abandoned a 
dodgy release branch entirely, but not many.

So I think the major trick we are missing is this:

   We don't know what the show-stopping bugs on a branch are

For example, here are three responses to Austin's message:

|  The only potential issue here is that not a single 7.8 release will be
|  able to bootstrap LLVM-only targets due to #9439. I'm not sure how

| 8960 looks rather serious and potentially makes all of 7.8 a no-go
| for some users.

|  We continue to use 7.2, at least partly because all newer versions of
|  ghc have had significant bugs that affect us

That's not good. Austin's message said about 7.8.4 "No particular pressure on 
any outstanding bugs to release immediately". There are several dozen tickets 
queued up on 7.8.4 (see here 
https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8.4), but 95% of them are 
"nice to have".

So clearly the message is not getting through.


My conclusion

 * I think we (collectively!) should make a serious attempt to fix show-stopping
   bugs on a major release branch.  (I agree that upgrading to the next major
   release often simply brings in a new wave of bugs because of GHC's
   rapid development culture.)

 * We can only possibly do this if
   a) we can distinguish "show-stopping" from "nice to have"
   b) we get some help (thank you John Lato for implicitly offering)

I would define a "show-stopping" bug as one that simply prevents you from using 
the release altogether, or imposes a very large cost at the user end.

For mechanism I suggest this.  On the 7.8.4 status page (or in general, on the 
release branch page you want to influence), create a section "Show stoppers" 
with a list of the show-stopping bugs, including some English-language text 
saying who cares so much and why.  (Yes I know that it might be there in the 
ticket, but the impact is much greater if there is an explicit list of two or 
three personal statements up front.)

Concerning 7.8.4 itself, I think we could review the decision to abandon it, in 
the light of new information.  We might, for example, fix show-stoppers, 
include fixes that are easy to apply, and not-include other fixes that are 
harder.

Opinions?  I'm not making a ruling here!

Simon

|  -Original Message-
|  From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org] On 
Behalf Of Ben
|  Gamari
|  Sent: 04 October 2014 04:52
|  To: Austin Seipp; ghc-devs@haskell.org
|  Cc: Simon Marlow
|  Subject: Re: Tentative high-level plans for 7.10.1
|
|  Austin Seipp mailto:aus...@well-typed.com>> writes:
|
|  snip.
|
|  >
|  > We do not believe we will ship a 7.8.4 at all, contrary to what you
|  > may have seen on Trac - we never decided definitively, but there is
|  > likely not enough time. Over the next few days, I will remove the
|  > defunct 7.8.4 milestone, and re-triage the assigned tickets.
|  >
|  The only potential issue here is that not a single 7.8 release will be
|  able to bootstrap LLVM-only targets due to #9439. I'm not sure how
|  much of an issue this wil

Re: [commit: ghc] master: Make Data.List.takeWhile fuse: fix #9132 (d14d3f9)

[Joachim Breitner]

Hi,

Am Mittwoch, den 08.10.2014, 06:53 + schrieb g...@git.haskell.org:
> commit d14d3f92d55a352db7faf62939127060716c4694
> Author: Joachim Breitner 
> Date:   Wed Oct 8 08:53:26 2014 +0200
> 
> Make Data.List.takeWhile fuse: fix #9132
> 
> Summary:
> Rewrites takeWhile to a build/foldr form; fuses repeated
> applications of takeWhile.
> 
> Reviewers: nomeata, austin
> 
> Reviewed By: nomeata
> 
> Subscribers: thomie, carter, ezyang, simonmar
> 
> Projects: #ghc
> 
> Differential Revision: https://phabricator.haskell.org/D322
> 
> GHC Trac Issues: #9132

nofib’s fft2’s allocs -23%, nice!
(otherwise no differences worth mentioning).

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Source-markup language for GHC User's Guide

[Herbert Valerio Riedel]

On 2014-10-08 at 10:49:33 +0200, Jan Stolarek wrote:
>> Therefore I'd like to hear your opinion on migrating away from the
>> current Docbook XML markup to some other similarly expressive but yet
>> more lightweight markup documentation system such as Asciidoc[1] or
>> ReST/Sphinx[2].

> My opinion is that I don't really care. I only edit the User Guide
> once every couple of months or so. I don't have problems with Docbook
> but if others want something else I can adjust.

I'd argue, that casual contributions may benefit significantly from
switching to a more human-friendly markup, as my theory is that it's
much easier to pick-up a syntax that's much closer to plain-text rather
than a fully-fledged Docbook XML. With a closer-to-plain-text syntax you
can more easily focus on the content you want to write rather than being
distracted by the incidental complexity of writing low-level XML markup.

Or put differently, I believe or rather hope this may lower the
barrier-to-entry for casual User's Guide contributions.


Fwiw, I stumbled over the slide-deck (obviously dogfooded in Asciidoc)

  
http://mojavelinux.github.io/decks/discover-zen-writing-asciidoc/cojugs201305/index.html

which tries to make the point that Asciidoc helps you focus more on
writing content rather than fighting with the markup, including a
comparision of the conciseness of a chosen example of Asciidoc vs. the
resulting Docbook XML it is converted into.


Cheers,
  hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Warning when deriving Foldable/Traversable using -Wall

[Alan & Kim Zimmerman]

I am not sure how to report bugs against the current development version of
GHC.

Should this go into Trac?

The current HEAD gives a spurious unused declaration when deriving
Typable/Traversable

Details

Compiling against current HEAD (0ed9a2779a2adf0347088134fdb9f60ae9f2735b)

Adding

  test('T9069w', extra_clean(['T9069.o', 'T9069.hi']), multimod_compile,
['T9069', '-Wall'])

to
  testsuite/tests/deriving/should_compile/all.T

results in

+[1 of 1] Compiling T9069( T9069.hs, T9069.o )
+
+T9069.hs:5:1: Warning:
+The import of ‘Data.Foldable’ is redundant
+  except perhaps to import instances from ‘Data.Foldable’
+To import instances alone, use: import Data.Foldable()
+
+T9069.hs:6:1: Warning:
+The import of ‘Data.Traversable’ is redundant
+  except perhaps to import instances from ‘Data.Traversable’
+To import instances alone, use: import Data.Traversable()
*** unexpected failure for T9069w(optasm)

The file being compiled is


{-# LANGUAGE DeriveTraversable #-}

module T9069 where

import Data.Foldable
import Data.Traversable

data Trivial a = Trivial a
   deriving (Functor,Foldable,Traversable)
-
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Warning when deriving Foldable/Traversable using -Wall

[Herbert Valerio Riedel]

On 2014-10-08 at 14:00:05 +0200, Alan & Kim Zimmerman wrote:

[...]

> Should this go into Trac?

Fwiw, there is a version "7.9" you can select when writing a Trac ticket
for the very purpose to file bugs against GHC HEAD.

[...]

> The file being compiled is
>
> 
> {-# LANGUAGE DeriveTraversable #-}
>
> module T9069 where
>
> import Data.Foldable
> import Data.Traversable
>
> data Trivial a = Trivial a
>deriving (Functor,Foldable,Traversable)
> -

There's two simple ways to workaround this;

either

 a) add a 'import Prelude' after the two imports

or

 b) remove the two imports



The a) option has the benefit that it will still work with GHC 7.8.3
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Warning when deriving Foldable/Traversable using -Wall

[Nicolas Trangez]

On Wed, 2014-10-08 at 14:00 +0200, Alan & Kim Zimmerman wrote:
> The current HEAD gives a spurious unused declaration when deriving
> Typable/Traversable

Why would this be spurious, given `Foldable` and `Traversable` are now
exported by `Prelude`, so those imports are in fact not necessary?

Nicolas

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

RE: Warning when deriving Foldable/Traversable using -Wall

[Simon Peyton Jones]

Yes, please add as a Trac ticket!  thank you

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim 
Zimmerman
Sent: 08 October 2014 13:00
To: ghc-devs@haskell.org
Subject: Warning when deriving Foldable/Traversable using -Wall

I am not sure how to report bugs against the current development version of GHC.
Should this go into Trac?

The current HEAD gives a spurious unused declaration when deriving 
Typable/Traversable
Details

Compiling against current HEAD (0ed9a2779a2adf0347088134fdb9f60ae9f2735b)

Adding

  test('T9069w', extra_clean(['T9069.o', 'T9069.hi']), multimod_compile, 
['T9069', '-Wall'])

to
  testsuite/tests/deriving/should_compile/all.T

results in

+[1 of 1] Compiling T9069( T9069.hs, T9069.o )
+
+T9069.hs:5:1: Warning:
+The import of ‘Data.Foldable’ is redundant
+  except perhaps to import instances from ‘Data.Foldable’
+To import instances alone, use: import Data.Foldable()
+
+T9069.hs:6:1: Warning:
+The import of ‘Data.Traversable’ is redundant
+  except perhaps to import instances from ‘Data.Traversable’
+To import instances alone, use: import Data.Traversable()
*** unexpected failure for T9069w(optasm)

The file being compiled is


{-# LANGUAGE DeriveTraversable #-}

module T9069 where

import Data.Foldable
import Data.Traversable

data Trivial a = Trivial a
   deriving (Functor,Foldable,Traversable)
-

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

Re: Warning when deriving Foldable/Traversable using -Wall

[Alan & Kim Zimmerman]

Ok, so stage2 is in fact behaving correctly, the stage1 code needs to have
CPP directives around it.

In other words this is not actually a bug.

Thanks
  Alan

On Wed, Oct 8, 2014 at 2:05 PM, Nicolas Trangez 
wrote:

> On Wed, 2014-10-08 at 14:00 +0200, Alan & Kim Zimmerman wrote:
> > The current HEAD gives a spurious unused declaration when deriving
> > Typable/Traversable
>
> Why would this be spurious, given `Foldable` and `Traversable` are now
> exported by `Prelude`, so those imports are in fact not necessary?
>
> Nicolas
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Tentative high-level plans for 7.10.1

[Edward Z. Yang]

Excerpts from Herbert Valerio Riedel's message of 2014-10-08 00:59:40 -0600:
> However, should GHC 7.8.x turn out to become a LTS-ishly maintained
> branch, we may want to consider converting it to a similiar Git
> structure as GHC HEAD currently is, to avoid having to keep two
> different sets of instructions on the GHC Wiki for how to work on GHC
> 7.8 vs working on GHC HEAD/7.10 and later.

Emphatically yes.  Lack of submodules on the 7.8 branch makes working with
it /very/ unpleasant.

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

Re: Tentative high-level plans for 7.10.1

[John Lato]

Speaking for myself, I don't think the question of doing a 7.8.4 release at
all needs to be entangled with the LTS issue.

On Wed, Oct 8, 2014 at 8:23 AM, Edward Z. Yang  wrote:

> Excerpts from Herbert Valerio Riedel's message of 2014-10-08 00:59:40
> -0600:
> > However, should GHC 7.8.x turn out to become a LTS-ishly maintained
> > branch, we may want to consider converting it to a similiar Git
> > structure as GHC HEAD currently is, to avoid having to keep two
> > different sets of instructions on the GHC Wiki for how to work on GHC
> > 7.8 vs working on GHC HEAD/7.10 and later.
>
> Emphatically yes.  Lack of submodules on the 7.8 branch makes working with
> it /very/ unpleasant.
>
> Edward
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Capturing commas in Api Annotations (D297)

[Alan & Kim Zimmerman]

I am currently working annotations into the parser, provided them as a
separate structure at the end of the parse, indexed to the original by
SrcSpan and AST element type.

The question I have is how to capture commas and semicolons in lists of
items.

There are at least three ways of doing this

1. Make sure each of the items is Located, and add the possible comma
location to the annotation structure for it.

This has the drawback that all instances of the AST item annotation have
the possible comma location in them, and it does not cope with multiple
separators where these are allowed.


2. Introduce a new hsSyn structure to explicitly capture comma-separated
lists.

This is the current approach I am taking, modelled on the OrdList
implementation, but with an extra constructor to capture the separator
location.

Thus

```
data HsCommaList a
  = Empty
  | Cons a (HsCommaList a)
  | ExtraComma SrcSpan (HsCommaList a)
   -- ^ We need a SrcSpan for the annotation
  | Snoc (HsCommaList a) a
  | Two (HsCommaList a) -- Invariant: non-empty
(HsCommaList a) -- Invariant: non-empty
```


3. Change the lists to be of type `[Either SrcSpan a]` to explicitly
capture the comma locations in the list.


4. A fourth way is to add a list of SrcSpan to the annotation for the
parent structure of the list, simply tracking the comma positions. This
will make working with the annotations complicated though.


I am currently proceeding with option 2, but would appreciate some comment
on whether this is the best approach to take.

Option 2 will allow the AST to capture the extra commas in record
constructors, as suggested by SPJ in the debate on that feature.


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

heres a 32bit OS X 7.8.3 build

[Carter Schonwald]

hey all,

I know all of you wish you could run 32bit ghc 7.8.3 on your snazzy mac OS
10.9, so here you are!

http://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.8.3-i386-apple-darwin.tar.bz2


$ shasum -a256 ghc-7.8.3-i386-apple-darwin.tar.bz2
1268ce020b46b0b459b8713916466cb92ce0c54992a76b265db203e9ef5fb5e5
 ghc-7.8.3-i386-apple-darwin.tar.bz2

is the relevant SHA 256 digest

NB: I believe I managed to build it with intree-gmp too! So it wont' need
GMP installed in the system (but I could be wrong, in which case brew
install gmp will suffice)

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

Re: RFC: Source-markup language for GHC User's Guide

[Carter Schonwald]

does asciidoc have a formal grammar/syntax or whatever? i'm trying to look
up one, but can't seem to find it.


On Wed, Oct 8, 2014 at 7:14 AM, Herbert Valerio Riedel 
wrote:

> On 2014-10-08 at 10:49:33 +0200, Jan Stolarek wrote:
> >> Therefore I'd like to hear your opinion on migrating away from the
> >> current Docbook XML markup to some other similarly expressive but yet
> >> more lightweight markup documentation system such as Asciidoc[1] or
> >> ReST/Sphinx[2].
>
> > My opinion is that I don't really care. I only edit the User Guide
> > once every couple of months or so. I don't have problems with Docbook
> > but if others want something else I can adjust.
>
> I'd argue, that casual contributions may benefit significantly from
> switching to a more human-friendly markup, as my theory is that it's
> much easier to pick-up a syntax that's much closer to plain-text rather
> than a fully-fledged Docbook XML. With a closer-to-plain-text syntax you
> can more easily focus on the content you want to write rather than being
> distracted by the incidental complexity of writing low-level XML markup.
>
> Or put differently, I believe or rather hope this may lower the
> barrier-to-entry for casual User's Guide contributions.
>
>
> Fwiw, I stumbled over the slide-deck (obviously dogfooded in Asciidoc)
>
>
> http://mojavelinux.github.io/decks/discover-zen-writing-asciidoc/cojugs201305/index.html
>
> which tries to make the point that Asciidoc helps you focus more on
> writing content rather than fighting with the markup, including a
> comparision of the conciseness of a chosen example of Asciidoc vs. the
> resulting Docbook XML it is converted into.
>
>
> Cheers,
>   hvr
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Building ghc on Windows with msys2

[Páli Gábor János]

2014-10-07 17:02 GMT+02:00 Páli Gábor János :
> 2014-10-07 15:04 GMT+02:00 cg :
>> I guess the current two build server are all Cygwin based, they are
>> failing at the same permission issue at early building stage, it prevents
>> checking out the real problem. It seems msys2 (or msys)  seldom has
>> such issue.
>
> For what it is worth, I have been witnessing those permission issues
> with msys2 on my Windows builders.  They worked (more or the less)
> fine until September 24, but suddenly, something has changed (not on
> my side) and all I got those errors since.

Looks like the commit with the Cabal submodule update causes this [1].
The revision before that commit still builds fine on my system, while
everything else after that commit dies early at build [2].  Is this
only me, has anybody else experienced the problem?  Perhaps I am doing
something wrong?  I do not remember to see any related "heads-up"
message on the list, like I should update any of the build-time
dependencies.

[1] 
http://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176f0ae
[2] http://haskell.inf.elte.hu/builders/windows-x86-head/56/10.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Building ghc on Windows with msys2

[lonetiger]

Hi Gintautas,


>  Indeed, the next thing I was going to ask was about expediting the decision 
> process. I would be happy to try and coordinate a push in Windows matters. 
> There is a caveat though: I don't have any skin in the GHC-on-Windows game, 
> so I will want to move on to other things afterwards.


I think I’m fairly behind on the current build process of GHC, but as I do use 
GHC mainly on Windows, at such a time as you would like to move on to other 
things, I would certainly throw my hat In the ring.


Cheers,

Tamar










From: Gintautas Miliauskas
Sent: ‎Thursday‎, ‎October‎ ‎2‎, ‎2014 ‎22‎:‎32
To: Simon Peyton Jones
Cc: Randy Polen, kyra, Marek Wawrzos, Tamar Christina, Roman Kuznetsov, Neil 
Mitchell, ghc-devs@haskell.org





Hi,




> All we need is someone to act as convenor/coordinator and we are good to go.  
> Would any of you be willing to play that role?




Indeed, the next thing I was going to ask was about expediting the decision 
process. I would be happy to try and coordinate a push in Windows matters. 
There is a caveat though: I don't have any skin in the GHC-on-Windows game, so 
I will want to move on to other things afterwards.









An advantage of having a working group is that you can decide things.  At the 
moment people often wait for GHC HQ to make a decision, and end up waiting a 
long time.  It would be better if a working group was responsible for the 
GHC-on-Windows build and then if (say) you want to mandate msys2, you can go 
ahead and mandate it.  Well, obviously consult ghc-devs for advice, but you are 
in the lead.  Does that make sense?




Sounds great. The question still remains about making changes to code: is there 
a particular person with commit rights that we could lean on for code reviews 
and committing changes to the main repository?

 




I think an early task is to replace what Neil Mitchell encountered: FIVE 
different wiki pages describing how to build GHC on Windows.  We want just one! 
 (Others can perhaps be marked “out of date/archive” rather than deleted, but 
it should be clear which is the main choice.)




Indeed, it's a bit of a mess. I intended to shape up the msys2 page to serve as 
the default, but wanted to see more testing done before before dropping the 
other pages.

 




I agree with using msys2 as the main choice.  (I’m using it myself.)  It may be 
that Gintautas’s page 
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 is 
already sufficient.  Although I’d like to see it tested by others.  For 
example, I found that it was CRUCIAL to set MSYSYSTEM=MINGW whereas Gintautas’s 
page says nothing about that. 




Are you sure that is a problem? The page specifically instructs to use the 
msys64_shell.bat script (through a shortcut) that is included in msys2, and 
that script takes care of setting MSYSTEM=MINGW64, among other important things.







Other small thoughts:

·We started including the ghc-tarball stuff because when we relied 
directly on the gcc that came with msys, we kept getting build failures because 
the gcc that some random person happened to be using did not work (e..g. they 
had a too-old or too-new version of msys).  By using a single, fixed gcc, we 
avoided all this pain.




Makes sense. Just curious: why is this less of a problem on GNU/Linux distros 
compared to msys2? Does msys2 see comparatively less testing, or is it 
generally more bleeding edge?







·I don’t know what a “rubenvb” build is, but I think you can go ahead 
and say “use X and Y in this way”.  The important thing is that it should be 
reproducible, and not dependent on the particular Cygwin or gcc or whatever the 
that user happens to have installed.

A "rubenvb" build is one of the available types of prebuilt binary packages of 
mingw for Windows. Let's figure out if there is something more mainstream and 
if we can migrate to that.



-- 
Gintautas Miliauskas___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs