Re: Template Haskell determinism

2016-06-29 Thread Michael Sloan 
Also, revisiting this issue, I don't think it is worth solving, just
worth documenting.

Why?  Because TH already lets you do lots of incorrect things.  TH
already allows you to shoot yourself in the foot all over the place,
and that's ok.  I'd much rather it be a dangerous power tool than a
weak safe tool.

When writing TH, you are writing something that's part of the
compiler, and the code can often resemble the sort of involved in the
middle bits of a compiler.  For the cases where stable Ord on Name
matters even for local names, you're definitely writing something
that's a fairly fancy, nearly compiler-like transformation.  Concerns
like the stability of Names should be handled by the TH user.

-Michael

On Wed, Jun 29, 2016 at 10:41 AM, Michael Sloan  wrote:
> No, NameU and NameL both lack package key / package id.
>
> -Michael
>
> On Wed, Jun 29, 2016 at 7:34 AM, Edward Z. Yang  wrote:
>> No, nameBase is not the right thing to use here; you also need the
>> unit ID (in GHC 8.0 parlance; package key in GHC 7.10; package id
>> in GHC 7.8 and before).  If you have that information, then
>> GHC establishes an invariant that if two names compare stably equal,
>> then the uniques associated with them are the same.
>>
>> Edward
>>
>> Excerpts from Michael Sloan's message of 2016-06-10 17:16:44 -0400:
>>> Hey, sorry for not getting back to this sooner!
>>>
>>> Perhaps I should have added the following to my list of goals in contention:
>>>
>>> (3) (==) shouldn't yield True for Names that have different unique ids.
>>>
>>> We can only have stable comparisons if goal (3) isn't met, and two
>>> different unique Names would be considered to be equivalent based on the
>>> nameBase.  This is because Ord is a total order, not a partial order.  As
>>> described in my prior email, PartialOrd could be added, but it'd be
>>> inconvenient to use with existing Ord based containers.
>>>
>>> -Michael
>>>
>>> On Sun, Jun 5, 2016 at 10:15 AM, Edward Z. Yang  wrote:
>>>
>>> > I must admit, I am a bit confused by this discussion.
>>> >
>>> > It is true that every Name is associated with a Unique.  But you don't
>>> > need the Unique to equality/ordering tests; the names also contain
>>> > enough (stable) information for stable comparisons of that sort.  So
>>> > why don't we expose that instead of the Unique?
>>> >
>>> > Edward
>>> >
>>> > Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700:
>>> > > On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones <
>>> > simo...@microsoft.com>
>>> > > wrote:
>>> > >
>>> > > > If names get different ordering keys when reified from different
>>> > modules
>>> > > > (seems like they'd have to, particularly given ghc's "-j"), then we
>>> > end up
>>> > > > with an unpleasant circumstance where these do not compare as equal
>>> > > >
>>> > > >
>>> > > >
>>> > > > The I believe that global, top level names (NameG) are not subject to
>>> > this
>>> > > > ordering stuff, so I don’t think this problem can occur.
>>> > > >
>>> > >
>>> > > True, top level names are NameG.  The reified Info for a top level Dec
>>> > may
>>> > > include NameU, though.  For example, the type variables in 'Maybe' are
>>> > > NameU:
>>> > >
>>> > > $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe
>>> > >  lift (show nf))
>>> > >
>>> > > The resulting expression is something like "NameU 822083586"
>>> > >
>>> > > > This is a breaking change and it doesn't fix the problem that
>>> > NameFlavour
>>> > > > is
>>> > > >
>>> > > > not abstract and leaks the Uniques. It would break at least:
>>> > > >
>>> > > >
>>> > > >
>>> > > > But why is NameU exposed to clients?   GHC needs to know, but clients
>>> > > > don’t.  What use are these packages making of it?
>>> > > >
>>> > >
>>> > > It's being leaked in the public inteface via Ord.  The Eq instance is
>>> > fine,
>>> > > because these are Uniques, so the results should be consistent.
>>> > >
>>> > > There are two goals in contention here:
>>> > >
>>> > > 1) Having some ordering on Names so that they can be used in Map or Set
>>> > > 2) Having law-abiding Eq / Ord instances.  We'd need a 'PartialOrd' to
>>> > > really handle these well.  In that case, the ordering would be based on
>>> > > everything but the NameU int, but 'Eq' would still follow it
>>> > >
>>> > > A few ideas for different approaches to resolving this:
>>> > >
>>> > > 1) Document it.  Less appealing than fixing it in the API, but still
>>> > would
>>> > > be good.
>>> > >
>>> > > 2) Remove the 'Ord' instance, and force the user to pick 
>>> > > 'NamePartialOrd'
>>> > > newtype (partial ord on the non-unique info), or 'UnstableNameOrd'
>>> > newtype
>>> > > (current behavior).  A trickyness of this approach is that you'd need
>>> > > containers that can handle (PartialOrd k, Eq k) keys.  In lots of cases
>>> > > people are using the 'Ord' instance with 'Name's that are not 'NameU', 
>>> > > so
>>> > > this would break a

Re: Template Haskell determinism

2016-06-29 Thread Michael Sloan 
No, NameU and NameL both lack package key / package id.

-Michael

On Wed, Jun 29, 2016 at 7:34 AM, Edward Z. Yang  wrote:
> No, nameBase is not the right thing to use here; you also need the
> unit ID (in GHC 8.0 parlance; package key in GHC 7.10; package id
> in GHC 7.8 and before).  If you have that information, then
> GHC establishes an invariant that if two names compare stably equal,
> then the uniques associated with them are the same.
>
> Edward
>
> Excerpts from Michael Sloan's message of 2016-06-10 17:16:44 -0400:
>> Hey, sorry for not getting back to this sooner!
>>
>> Perhaps I should have added the following to my list of goals in contention:
>>
>> (3) (==) shouldn't yield True for Names that have different unique ids.
>>
>> We can only have stable comparisons if goal (3) isn't met, and two
>> different unique Names would be considered to be equivalent based on the
>> nameBase.  This is because Ord is a total order, not a partial order.  As
>> described in my prior email, PartialOrd could be added, but it'd be
>> inconvenient to use with existing Ord based containers.
>>
>> -Michael
>>
>> On Sun, Jun 5, 2016 at 10:15 AM, Edward Z. Yang  wrote:
>>
>> > I must admit, I am a bit confused by this discussion.
>> >
>> > It is true that every Name is associated with a Unique.  But you don't
>> > need the Unique to equality/ordering tests; the names also contain
>> > enough (stable) information for stable comparisons of that sort.  So
>> > why don't we expose that instead of the Unique?
>> >
>> > Edward
>> >
>> > Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700:
>> > > On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones <
>> > simo...@microsoft.com>
>> > > wrote:
>> > >
>> > > > If names get different ordering keys when reified from different
>> > modules
>> > > > (seems like they'd have to, particularly given ghc's "-j"), then we
>> > end up
>> > > > with an unpleasant circumstance where these do not compare as equal
>> > > >
>> > > >
>> > > >
>> > > > The I believe that global, top level names (NameG) are not subject to
>> > this
>> > > > ordering stuff, so I don’t think this problem can occur.
>> > > >
>> > >
>> > > True, top level names are NameG.  The reified Info for a top level Dec
>> > may
>> > > include NameU, though.  For example, the type variables in 'Maybe' are
>> > > NameU:
>> > >
>> > > $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe
>> > >  lift (show nf))
>> > >
>> > > The resulting expression is something like "NameU 822083586"
>> > >
>> > > > This is a breaking change and it doesn't fix the problem that
>> > NameFlavour
>> > > > is
>> > > >
>> > > > not abstract and leaks the Uniques. It would break at least:
>> > > >
>> > > >
>> > > >
>> > > > But why is NameU exposed to clients?   GHC needs to know, but clients
>> > > > don’t.  What use are these packages making of it?
>> > > >
>> > >
>> > > It's being leaked in the public inteface via Ord.  The Eq instance is
>> > fine,
>> > > because these are Uniques, so the results should be consistent.
>> > >
>> > > There are two goals in contention here:
>> > >
>> > > 1) Having some ordering on Names so that they can be used in Map or Set
>> > > 2) Having law-abiding Eq / Ord instances.  We'd need a 'PartialOrd' to
>> > > really handle these well.  In that case, the ordering would be based on
>> > > everything but the NameU int, but 'Eq' would still follow it
>> > >
>> > > A few ideas for different approaches to resolving this:
>> > >
>> > > 1) Document it.  Less appealing than fixing it in the API, but still
>> > would
>> > > be good.
>> > >
>> > > 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd'
>> > > newtype (partial ord on the non-unique info), or 'UnstableNameOrd'
>> > newtype
>> > > (current behavior).  A trickyness of this approach is that you'd need
>> > > containers that can handle (PartialOrd k, Eq k) keys.  In lots of cases
>> > > people are using the 'Ord' instance with 'Name's that are not 'NameU', so
>> > > this would break a lot of code that was already deterministic.
>> > >
>> > > 3) Some approaches like this ordering key, but I'm not sure how it will
>> > > help when comparing NameUs from different modules?
>> > >
>> > > > S
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
>> > *Michael
>> > > > Sloan
>> > > > *Sent:* 02 June 2016 02:07
>> > > > *To:* Bartosz Nitka 
>> > > > *Cc:* ghc-devs Devs 
>> > > > *Subject:* Re: Template Haskell determinism
>> > > >
>> > > >
>> > > >
>> > > > +1 to solving this.  Not sure about the approach, but assuming the
>> > > > following concerns are addressed, I'm (+1) on it too:
>> > > >
>> > > >
>> > > >
>> > > > This solution is clever!  However, I think there is some difficulty to
>> > > > determining this ordering key.  Namely, what happens when I construct
>> > the
>> > > >

Re: Template Haskell determinism

2016-06-29 Thread Edward Z. Yang 
No, nameBase is not the right thing to use here; you also need the
unit ID (in GHC 8.0 parlance; package key in GHC 7.10; package id
in GHC 7.8 and before).  If you have that information, then
GHC establishes an invariant that if two names compare stably equal,
then the uniques associated with them are the same.

Edward

Excerpts from Michael Sloan's message of 2016-06-10 17:16:44 -0400:
> Hey, sorry for not getting back to this sooner!
> 
> Perhaps I should have added the following to my list of goals in contention:
> 
> (3) (==) shouldn't yield True for Names that have different unique ids.
> 
> We can only have stable comparisons if goal (3) isn't met, and two
> different unique Names would be considered to be equivalent based on the
> nameBase.  This is because Ord is a total order, not a partial order.  As
> described in my prior email, PartialOrd could be added, but it'd be
> inconvenient to use with existing Ord based containers.
> 
> -Michael
> 
> On Sun, Jun 5, 2016 at 10:15 AM, Edward Z. Yang  wrote:
> 
> > I must admit, I am a bit confused by this discussion.
> >
> > It is true that every Name is associated with a Unique.  But you don't
> > need the Unique to equality/ordering tests; the names also contain
> > enough (stable) information for stable comparisons of that sort.  So
> > why don't we expose that instead of the Unique?
> >
> > Edward
> >
> > Excerpts from Michael Sloan's message of 2016-06-04 18:44:03 -0700:
> > > On Thu, Jun 2, 2016 at 4:12 AM, Simon Peyton Jones <
> > simo...@microsoft.com>
> > > wrote:
> > >
> > > > If names get different ordering keys when reified from different
> > modules
> > > > (seems like they'd have to, particularly given ghc's "-j"), then we
> > end up
> > > > with an unpleasant circumstance where these do not compare as equal
> > > >
> > > >
> > > >
> > > > The I believe that global, top level names (NameG) are not subject to
> > this
> > > > ordering stuff, so I don’t think this problem can occur.
> > > >
> > >
> > > True, top level names are NameG.  The reified Info for a top level Dec
> > may
> > > include NameU, though.  For example, the type variables in 'Maybe' are
> > > NameU:
> > >
> > > $(do TyConI (DataD _ _ [KindedTV (Name _ nf) _] _ _ _) <- reify ''Maybe
> > >  lift (show nf))
> > >
> > > The resulting expression is something like "NameU 822083586"
> > >
> > > > This is a breaking change and it doesn't fix the problem that
> > NameFlavour
> > > > is
> > > >
> > > > not abstract and leaks the Uniques. It would break at least:
> > > >
> > > >
> > > >
> > > > But why is NameU exposed to clients?   GHC needs to know, but clients
> > > > don’t.  What use are these packages making of it?
> > > >
> > >
> > > It's being leaked in the public inteface via Ord.  The Eq instance is
> > fine,
> > > because these are Uniques, so the results should be consistent.
> > >
> > > There are two goals in contention here:
> > >
> > > 1) Having some ordering on Names so that they can be used in Map or Set
> > > 2) Having law-abiding Eq / Ord instances.  We'd need a 'PartialOrd' to
> > > really handle these well.  In that case, the ordering would be based on
> > > everything but the NameU int, but 'Eq' would still follow it
> > >
> > > A few ideas for different approaches to resolving this:
> > >
> > > 1) Document it.  Less appealing than fixing it in the API, but still
> > would
> > > be good.
> > >
> > > 2) Remove the 'Ord' instance, and force the user to pick 'NamePartialOrd'
> > > newtype (partial ord on the non-unique info), or 'UnstableNameOrd'
> > newtype
> > > (current behavior).  A trickyness of this approach is that you'd need
> > > containers that can handle (PartialOrd k, Eq k) keys.  In lots of cases
> > > people are using the 'Ord' instance with 'Name's that are not 'NameU', so
> > > this would break a lot of code that was already deterministic.
> > >
> > > 3) Some approaches like this ordering key, but I'm not sure how it will
> > > help when comparing NameUs from different modules?
> > >
> > > > S
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
> > *Michael
> > > > Sloan
> > > > *Sent:* 02 June 2016 02:07
> > > > *To:* Bartosz Nitka 
> > > > *Cc:* ghc-devs Devs 
> > > > *Subject:* Re: Template Haskell determinism
> > > >
> > > >
> > > >
> > > > +1 to solving this.  Not sure about the approach, but assuming the
> > > > following concerns are addressed, I'm (+1) on it too:
> > > >
> > > >
> > > >
> > > > This solution is clever!  However, I think there is some difficulty to
> > > > determining this ordering key.  Namely, what happens when I construct
> > the
> > > > (Set Name) using results from multiple reifies?
> > > >
> > > >
> > > >
> > > > One solution is to have the ordering key be a consecutive supply that's
> > > > initialized on a per-module basis.  There is still an issue there,
> > though,
> > > > which is that you

Re: Msys2 64: progress

2016-06-29 Thread David Macek 
On 29. 6. 2016 13:16, David Macek wrote:
> On 29. 6. 2016 0:27, loneti...@gmail.com wrote:
>> In any case, downgrading back to 7.48.0 worked for me.
>>
>> I don’t know how to do that with pacman
> 
> curl -Os http://repo.msys2.org/msys/x86_64/libcurl-7.48.0-1-x86_64.pkg.tar.xz
> curl -Os http://repo.msys2.org/msys/x86_64/curl-7.48.0-1-x86_64.pkg.tar.xz
> pacman -U libcurl-7.48.0-1-x86_64.pkg.tar.xz curl-7.48.0-1-x86_64.pkg.tar.xz
> rm libcurl-7.48.0-1-x86_64.pkg.tar.xz curl-7.48.0-1-x86_64.pkg.tar.xz

Oops. If curl doesn't work, substitute with wget as per Tamar's advice, but 
`pacman -U` is still the right way to install stand-alone package files.

-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Msys2 64: progress

2016-06-29 Thread David Macek 
On 29. 6. 2016 0:27, loneti...@gmail.com wrote:
> In any case, downgrading back to 7.48.0 worked for me.
> 
> I don’t know how to do that with pacman

curl -Os http://repo.msys2.org/msys/x86_64/libcurl-7.48.0-1-x86_64.pkg.tar.xz
curl -Os http://repo.msys2.org/msys/x86_64/curl-7.48.0-1-x86_64.pkg.tar.xz
pacman -U libcurl-7.48.0-1-x86_64.pkg.tar.xz curl-7.48.0-1-x86_64.pkg.tar.xz
rm libcurl-7.48.0-1-x86_64.pkg.tar.xz curl-7.48.0-1-x86_64.pkg.tar.xz

-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Msys2 64: progress

2016-06-29 Thread Simon Peyton Jones via ghc-devs 
Aha!  That sounds very plausible.   I’ll try.   Maybe it’s a path-ordering 
thing.

It would be very cool if ‘configure’ checked that ‘find’ was the find it was 
expecting, not Windows find.  Dunno how to do that, but that check would have 
saved us a lot of time.

(For most other utils, weget, curl etc, there is no Windows program with the 
same name.  But for ‘find’, there is.)

Simon

From: loneti...@gmail.com [mailto:loneti...@gmail.com]
Sent: 29 June 2016 11:35
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org
Subject: RE: Msys2 64: progress


Hi Simon,

I think you’re right,
That pattern in the error is the one we pass to find

find "${base_dir}" -name "*.tar.xz" -exec tar xfJ {} \;

on line 334 of configure.ac which is supposed to unpack the files.
That the download script doesn’t output nothing makes sense now since the 
hashes of the files match.

I *think* what’s going on here is that for some reason you don’t have findutils 
installed and it’s instead using
The windows “find” utility, which generates that error.

C:\Users\Tamar>find *.tar.xz
File not found - *.tar.xz

Try re-installing findutils, pacman -S findutils, and if find –version doesn’t 
return the findutils one check your PATH settings.

Cheers,
Tamar

From: Simon Peyton Jones
Sent: Wednesday, June 29, 2016 10:18
To: loneti...@gmail.com
Cc: ghc-devs@haskell.org
Subject: RE: Msys2 64: progress

It’s bizarre that pacman won’t let us downgrade curl!

I don’t know how to do that with pacman, so instead maybe try:

pacman -S wget
wget -qO - 
http://repo.msys2.org/msys/x86_64/libcurl-7.48.0-1-x86_64.pkg.tar.xz
 | tar xJ -C /usr --strip-components=1
wget -qO - 
http://repo.msys2.org/msys/x86_64/curl-7.48.0-1-x86_64.pkg.tar.xz
 | tar xJ -C /usr --strip-components=1

I tried this.  All three commands succeeded, the latter two with no output at 
all.  But once more “./configure” fails with the same message “File not found - 
*.tar.xz”.It is a bizarre message isn’t it?

A lot of files are there:
/c/code/HEAD$ ls ghc-tarballs/mingw-w64/
x86_64
/c/code/HEAD$ ls ghc-tarballs/mingw-w64/x86_64/
mingw-w64-x86_64-binutils-2.25.1-1-any.pkg.tar.xz
mingw-w64-x86_64-crt-git-5.0.0.4531.49c7046-1-any.pkg.tar.xz
mingw-w64-x86_64-gcc-5.2.0-3-any.pkg.tar.xz
mingw-w64-x86_64-gcc-libs-5.2.0-3-any.pkg.tar.xz
mingw-w64-x86_64-gmp-6.0.0-3-any.pkg.tar.xz
mingw-w64-x86_64-headers-git-5.0.0.4531.49c7046-1-any.pkg.tar.xz
mingw-w64-x86_64-isl-0.14.1-2-any.pkg.tar.xz
mingw-w64-x86_64-libiconv-1.14-5-any.pkg.tar.xz
mingw-w64-x86_64-libwinpthread-git-5.0.0.4538.78dca70-1-any.pkg.tar.xz
mingw-w64-x86_64-mpc-1.0.3-2-any.pkg.tar.xz
mingw-w64-x86_64-mpfr-3.1.3.p0-2-any.pkg.tar.xz
mingw-w64-x86_64-winpthreads-git-5.0.0.4538.78dca70-1-any.pkg.tar.xz
mingw-w64-x86_64-zlib-1.2.8-8-any.pkg.tar.xz
/c/code/HEAD$ ls ghc-tarballs/perl/
ghc-perl-1.tar.gz

All I need is for ‘configure’ to get on and un-tar them!   Maybe the problem 
isn’t with curl at all?

Simon

From: loneti...@gmail.com 
[mailto:loneti...@gmail.com]
Sent: 28 June 2016 23:27
To: Simon Peyton Jones >
Cc: ghc-devs@haskell.org
Subject: RE: Msys2 64: progress

Hi Simon,

I’m not sure what’s going on there.

I updated my curl to 7.49.1 and I am experiencing the same silent death 
(--version doesn’t even work for me then which is weird).

In any case, downgrading back to 7.48.0 worked for me.

I don’t know how to do that with pacman, so instead maybe try:

pacman -S wget
wget -qO - 
http://repo.msys2.org/msys/x86_64/libcurl-7.48.0-1-x86_64.pkg.tar.xz
 | tar xJ -C /usr --strip-components=1
wget -qO -

RE: Msys2 64: progress

2016-06-29 Thread lonetiger 

Hi Simon,

I think you’re right, 
That pattern in the error is the one we pass to find

find "${base_dir}" -name "*.tar.xz" -exec tar xfJ {} \;

on line 334 of configure.ac which is supposed to unpack the files. 
That the download script doesn’t output nothing makes sense now since the 
hashes of the files match.

I *think* what’s going on here is that for some reason you don’t have findutils 
installed and it’s instead using
The windows “find” utility, which generates that error. 

C:\Users\Tamar>find *.tar.xz
File not found - *.tar.xz

Try re-installing findutils, pacman -S findutils, and if find –version doesn’t 
return the findutils one check your PATH settings.

Cheers,
Tamar

From: Simon Peyton Jones___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Msys2 64: progress

2016-06-29 Thread Simon Peyton Jones via ghc-devs 
It’s bizarre that pacman won’t let us downgrade curl!

I don’t know how to do that with pacman, so instead maybe try:

pacman -S wget
wget -qO - http://repo.msys2.org/msys/x86_64/libcurl-7.48.0-1-x86_64.pkg.tar.xz 
| tar xJ -C /usr --strip-components=1
wget -qO - http://repo.msys2.org/msys/x86_64/curl-7.48.0-1-x86_64.pkg.tar.xz | 
tar xJ -C /usr --strip-components=1

I tried this.  All three commands succeeded, the latter two with no output at 
all.  But once more “./configure” fails with the same message “File not found - 
*.tar.xz”.It is a bizarre message isn’t it?

A lot of files are there:
/c/code/HEAD$ ls ghc-tarballs/mingw-w64/
x86_64
/c/code/HEAD$ ls ghc-tarballs/mingw-w64/x86_64/
mingw-w64-x86_64-binutils-2.25.1-1-any.pkg.tar.xz
mingw-w64-x86_64-crt-git-5.0.0.4531.49c7046-1-any.pkg.tar.xz
mingw-w64-x86_64-gcc-5.2.0-3-any.pkg.tar.xz
mingw-w64-x86_64-gcc-libs-5.2.0-3-any.pkg.tar.xz
mingw-w64-x86_64-gmp-6.0.0-3-any.pkg.tar.xz
mingw-w64-x86_64-headers-git-5.0.0.4531.49c7046-1-any.pkg.tar.xz
mingw-w64-x86_64-isl-0.14.1-2-any.pkg.tar.xz
mingw-w64-x86_64-libiconv-1.14-5-any.pkg.tar.xz
mingw-w64-x86_64-libwinpthread-git-5.0.0.4538.78dca70-1-any.pkg.tar.xz
mingw-w64-x86_64-mpc-1.0.3-2-any.pkg.tar.xz
mingw-w64-x86_64-mpfr-3.1.3.p0-2-any.pkg.tar.xz
mingw-w64-x86_64-winpthreads-git-5.0.0.4538.78dca70-1-any.pkg.tar.xz
mingw-w64-x86_64-zlib-1.2.8-8-any.pkg.tar.xz
/c/code/HEAD$ ls ghc-tarballs/perl/
ghc-perl-1.tar.gz

All I need is for ‘configure’ to get on and un-tar them!   Maybe the problem 
isn’t with curl at all?

Simon

From: loneti...@gmail.com [mailto:loneti...@gmail.com]
Sent: 28 June 2016 23:27
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org
Subject: RE: Msys2 64: progress

Hi Simon,

I’m not sure what’s going on there.

I updated my curl to 7.49.1 and I am experiencing the same silent death 
(--version doesn’t even work for me then which is weird).

In any case, downgrading back to 7.48.0 worked for me.

I don’t know how to do that with pacman, so instead maybe try:

pacman -S wget
wget -qO - http://repo.msys2.org/msys/x86_64/libcurl-7.48.0-1-x86_64.pkg.tar.xz 
| tar xJ -C /usr --strip-components=1
wget -qO - http://repo.msys2.org/msys/x86_64/curl-7.48.0-1-x86_64.pkg.tar.xz | 
tar xJ -C /usr --strip-components=1

If it doesn’t work, to upgrade again to 7.49.1 you can just do pacman -S curl 
libcurl

Kind Regards,
Tamar

From: Simon Peyton Jones
Sent: Tuesday, June 28, 2016 21:13
To: loneti...@gmail.com
Cc: ghc-devs@haskell.org
Subject: RE: Msys2 64: progress

Actually I had the command right; copy/paste somehow removed the underscore.
And curl –version does report
curl --version
curl 7.49.1 (x86_64-pc-msys)
so it should not be necessary anyway.

But ./configure still fails with
checking for path to top of build tree... C:/code/HEAD
configure: Checking for Windows toolchain tarballs...
configure: Extracting Windows toolchain from archives (may take a while)...
File not found - *.tar.xz

Meanwhile
mk/get-win32-tarballs.sh download x86_64
completes after 1 second, with no messages of any kind.

What next?!

Thanks

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of 
loneti...@gmail.com
Sent: 28 June 2016 22:19
To: Simon Peyton Jones via ghc-devs 
>; David Macek 
>; 
ta...@zhox.com
Cc: ghc-devs@haskell.org
Subject: RE: Msys2 64: progress

Hi Simon,

You’re missing an underscore in the command (there’s one between x86 and 64),

It’s pacman -R 
mingw-w64-x86_64-curl

This is only needed if curl --version reports anything other than 
x86_64-pc-msys.
After that you need to install the normal msys curl with pacman -S curl

You don’t have to run configure everytime to test either, you can just run

mk/get-win32-tarballs.sh download x86_64

from the root and it should just download the packages only if everything is 
setup correctly.

Also don’t forget to do a pacman -Sy to update the repositories. Couldn’t 
gather from your email if you did this already.

Kind Regards,
Tamar

From: Simon Peyton Jones via ghc-devs
Sent: Tuesday, June 28, 2016 21:02
To: David Macek; 
ta...@zhox.com
Cc: ghc-devs@haskell.org
Subject: Msys2 64: progress

Friends
I want to thank everyone who has responded – very helpful!
Thanks to your help I am making progress

·I re-installed msys64 from