From gershomb at gmail.com  Tue Jan  2 01:24:45 2018
From: gershomb at gmail.com (Gershom B)
Date: Mon, 1 Jan 2018 20:24:45 -0500
Subject: PSA: `cabal update` command needs manual unsticking
Message-ID: <CAM8RHpHEvfqPvaKKxMmyXT+6AT8sXw4Q-xta1HdTci3X8QL+xw@mail.gmail.com>

Dear Haskellers,

A recent update to hackage, which fixed up the 01-index.tar.gz file,
revealed a bug in existing versions of cabal-install, when index files
are cleaned up. This bug means that the `cabal update` command, which
updates the hackage index file, will fail silently and leave the old
file in place. It is easy to get things working again, but it requires
manual intervention. Here is the most straightforward way to get
things working again:

On gnu/linux or mac: rm ~/.cabal/packages/hackage.haskell.org/01-index.*
On windows: remove the same files, but from
%appdata%\cabal\packages\hackage.haskell.org

rerun `cabal update` to fetch a new 01-index.

Apologies all for the inconvenience and any confusion this may have
caused. There is a PR to fix this behavior in the works, but since the
problem is on the client side, the fix will only improve the
situations for new versions of `cabal`.

Happy New Years to all, and cheers to a very functional 2018,
Gershom

p.s.: since the problem comes in unpacking the 01-index.tar.gz into
the 01-index.tar, you can also just untar that file in place manually,
or force cabal into doing the same by running `touch
~/.cabal/packages/hackage.haskell.org/01-index.tar`

From svenpanne at gmail.com  Tue Jan  2 09:47:33 2018
From: svenpanne at gmail.com (Sven Panne)
Date: Tue, 2 Jan 2018 10:47:33 +0100
Subject: PSA: `cabal update` command needs manual unsticking
In-Reply-To: <CAM8RHpHEvfqPvaKKxMmyXT+6AT8sXw4Q-xta1HdTci3X8QL+xw@mail.gmail.com>
References: <CAM8RHpHEvfqPvaKKxMmyXT+6AT8sXw4Q-xta1HdTci3X8QL+xw@mail.gmail.com>
Message-ID: <CANBN=mthEV3t_J-7OYs07YByzrT2wgUuDOWGhoBDeUdEP+CJsg@mail.gmail.com>

2018-01-02 2:24 GMT+01:00 Gershom B <gershomb at gmail.com>:

> A recent update to hackage, which fixed up the 01-index.tar.gz file,
> revealed a bug in existing versions of cabal-install, when index files
> are cleaned up. This bug means that the `cabal update` command, which
> updates the hackage index file, will fail silently and leave the old
> file in place. It is easy to get things working again, but it requires
> manual intervention. [...]


Quick question: Are stack users affected, too, or only cabal users? I'm
just asking because as a stack user you have
~/.stack/indices/Hackage/01-index.* files lying around, too...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180102/dc3d9404/attachment.html>

From michael at snoyman.com  Tue Jan  2 09:52:37 2018
From: michael at snoyman.com (Michael Snoyman)
Date: Tue, 2 Jan 2018 11:52:37 +0200
Subject: PSA: `cabal update` command needs manual unsticking
In-Reply-To: <CANBN=mthEV3t_J-7OYs07YByzrT2wgUuDOWGhoBDeUdEP+CJsg@mail.gmail.com>
References: <CAM8RHpHEvfqPvaKKxMmyXT+6AT8sXw4Q-xta1HdTci3X8QL+xw@mail.gmail.com>
 <CANBN=mthEV3t_J-7OYs07YByzrT2wgUuDOWGhoBDeUdEP+CJsg@mail.gmail.com>
Message-ID: <CAKT9ecPA-Z6JazSzKfey0Tic8AgD3+6-2+sMek-Y1+Wp+Q_RAw@mail.gmail.com>

On Tue, Jan 2, 2018 at 11:47 AM, Sven Panne <svenpanne at gmail.com> wrote:

> 2018-01-02 2:24 GMT+01:00 Gershom B <gershomb at gmail.com>:
>
>> A recent update to hackage, which fixed up the 01-index.tar.gz file,
>> revealed a bug in existing versions of cabal-install, when index files
>> are cleaned up. This bug means that the `cabal update` command, which
>> updates the hackage index file, will fail silently and leave the old
>> file in place. It is easy to get things working again, but it requires
>> manual intervention. [...]
>
>
> Quick question: Are stack users affected, too, or only cabal users? I'm
> just asking because as a stack user you have ~/.stack/indices/Hackage/01-index.*
> files lying around, too...
>
>
Hey Sven,

Gershom sent me an email about this earlier, and I looked into it. As far
as I can tell, Stack is _not_ affected by this, since—although it uses the
same hackage-security library as cabal-install—it follows a different
codepath outside of hackage-security for downloading tarballs. I'm not 100%
certain Stack is immune, however, so if someone notices a problem, please
report it.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180102/a61f7c90/attachment.html>

From allbery.b at gmail.com  Thu Jan  4 22:23:55 2018
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 4 Jan 2018 17:23:55 -0500
Subject: [Haskell-cafe] PSA: `cabal update` command needs manual unsticking
In-Reply-To: <CAO8RVvcMbAgnkNWZ3HYT_0nUSbbzsA2nSwHRU1eCtKjyXVXZfw@mail.gmail.com>
References: <CAM8RHpHEvfqPvaKKxMmyXT+6AT8sXw4Q-xta1HdTci3X8QL+xw@mail.gmail.com>
 <CAO8RVvcMbAgnkNWZ3HYT_0nUSbbzsA2nSwHRU1eCtKjyXVXZfw@mail.gmail.com>
Message-ID: <CAKFCL4WJAbaRVbv3e6X61WBa=w_WE_vUiPuukcHHzc8JbiaVDA@mail.gmail.com>

Correct: cabal-install 1.x still uses the old index format (00-index). The
logic is different for 01-index, in order to support incremental update
(appending when possible, instead of always having to download the whole
thing again like with 00-index).

On Thu, Jan 4, 2018 at 1:38 PM, Nathan Collins <nathan.collins at gmail.com>
wrote:

> In case this confuses anyone else, I think this PSA only applies if
> you're using cabal-install version 2.*, but please correct me if I'm
> wrong.
>
> I had some ~/.cabal/packages/hackage.haskell.org/00-index.* files, but
> not any 01-index.* files, and running `cabal update` didn't change
> that. Then I noticed I was using cabal-install version 1.24.0.2. When
> I upgraded to cabal-install version 2.0.0.1 and did another `cabal
> update` the 01-index.* files appeared.
>
> Cheers,
>
> -nathan
>
> On Mon, Jan 1, 2018 at 5:24 PM, Gershom B <gershomb at gmail.com> wrote:
> > Dear Haskellers,
> >
> > A recent update to hackage, which fixed up the 01-index.tar.gz file,
> > revealed a bug in existing versions of cabal-install, when index files
> > are cleaned up. This bug means that the `cabal update` command, which
> > updates the hackage index file, will fail silently and leave the old
> > file in place. It is easy to get things working again, but it requires
> > manual intervention. Here is the most straightforward way to get
> > things working again:
> >
> > On gnu/linux or mac: rm ~/.cabal/packages/hackage.haskell.org/01-index.*
> > On windows: remove the same files, but from
> > %appdata%\cabal\packages\hackage.haskell.org
> >
> > rerun `cabal update` to fetch a new 01-index.
> >
> > Apologies all for the inconvenience and any confusion this may have
> > caused. There is a PR to fix this behavior in the works, but since the
> > problem is on the client side, the fix will only improve the
> > situations for new versions of `cabal`.
> >
> > Happy New Years to all, and cheers to a very functional 2018,
> > Gershom
> >
> > p.s.: since the problem comes in unpacking the 01-index.tar.gz into
> > the 01-index.tar, you can also just untar that file in place manually,
> > or force cabal into doing the same by running `touch
> > ~/.cabal/packages/hackage.haskell.org/01-index.tar`
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.




-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180104/1d60691b/attachment.html>

From carter.schonwald at gmail.com  Fri Jan  5 14:33:50 2018
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 05 Jan 2018 14:33:50 +0000
Subject: [Haskell-cafe] PSA: `cabal update` command needs manual unsticking
In-Reply-To: <CAKFCL4WJAbaRVbv3e6X61WBa=w_WE_vUiPuukcHHzc8JbiaVDA@mail.gmail.com>
References: <CAM8RHpHEvfqPvaKKxMmyXT+6AT8sXw4Q-xta1HdTci3X8QL+xw@mail.gmail.com>
 <CAO8RVvcMbAgnkNWZ3HYT_0nUSbbzsA2nSwHRU1eCtKjyXVXZfw@mail.gmail.com>
 <CAKFCL4WJAbaRVbv3e6X61WBa=w_WE_vUiPuukcHHzc8JbiaVDA@mail.gmail.com>
Message-ID: <CAHYVw0yV8Vw6KT1LD57Zfv5dNDX47T6oqygJd_O-WsdY=dqpPA@mail.gmail.com>

My cabal v2 seemed to be using 00 indices.  Much to my confusion.  Maybe I
should reinstall it and check my config ;)

On Thu, Jan 4, 2018 at 5:25 PM Brandon Allbery <allbery.b at gmail.com> wrote:

> Correct: cabal-install 1.x still uses the old index format (00-index). The
> logic is different for 01-index, in order to support incremental update
> (appending when possible, instead of always having to download the whole
> thing again like with 00-index).
>
> On Thu, Jan 4, 2018 at 1:38 PM, Nathan Collins <nathan.collins at gmail.com>
> wrote:
>
>> In case this confuses anyone else, I think this PSA only applies if
>> you're using cabal-install version 2.*, but please correct me if I'm
>> wrong.
>>
>> I had some ~/.cabal/packages/hackage.haskell.org/00-index.* files, but
>> not any 01-index.* files, and running `cabal update` didn't change
>> that. Then I noticed I was using cabal-install version 1.24.0.2. When
>> I upgraded to cabal-install version 2.0.0.1 and did another `cabal
>> update` the 01-index.* files appeared.
>>
>> Cheers,
>>
>> -nathan
>>
>> On Mon, Jan 1, 2018 at 5:24 PM, Gershom B <gershomb at gmail.com> wrote:
>> > Dear Haskellers,
>> >
>> > A recent update to hackage, which fixed up the 01-index.tar.gz file,
>> > revealed a bug in existing versions of cabal-install, when index files
>> > are cleaned up. This bug means that the `cabal update` command, which
>> > updates the hackage index file, will fail silently and leave the old
>> > file in place. It is easy to get things working again, but it requires
>> > manual intervention. Here is the most straightforward way to get
>> > things working again:
>> >
>> > On gnu/linux or mac: rm ~/.cabal/packages/
>> hackage.haskell.org/01-index.*
>> > On windows: remove the same files, but from
>> > %appdata%\cabal\packages\hackage.haskell.org
>> >
>> > rerun `cabal update` to fetch a new 01-index.
>> >
>> > Apologies all for the inconvenience and any confusion this may have
>> > caused. There is a PR to fix this behavior in the works, but since the
>> > problem is on the client side, the fix will only improve the
>> > situations for new versions of `cabal`.
>> >
>> > Happy New Years to all, and cheers to a very functional 2018,
>> > Gershom
>> >
>> > p.s.: since the problem comes in unpacking the 01-index.tar.gz into
>> > the 01-index.tar, you can also just untar that file in place manually,
>> > or force cabal into doing the same by running `touch
>> > ~/.cabal/packages/hackage.haskell.org/01-index.tar`
>> <http://hackage.haskell.org/01-index.tar>
>> > _______________________________________________
>> > Haskell-Cafe mailing list
>> > To (un)subscribe, modify options or view archives go to:
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> > Only members subscribed via the mailman list are allowed to post.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
>
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180105/aad33646/attachment.html>

From donn at avvanta.com  Fri Jan  5 17:54:47 2018
From: donn at avvanta.com (Donn Cave)
Date: Fri,  5 Jan 2018 09:54:47 -0800 (PST)
Subject: PSA: `cabal update` command needs manual unsticking
In-Reply-To: <CAO8RVvcMbAgnkNWZ3HYT_0nUSbbzsA2nSwHRU1eCtKjyXVXZfw@mail.gmail.com>
References: <CAM8RHpHEvfqPvaKKxMmyXT+6AT8sXw4Q-xta1HdTci3X8QL+xw@mail.gmail.com>
 <CAO8RVvcMbAgnkNWZ3HYT_0nUSbbzsA2nSwHRU1eCtKjyXVXZfw@mail.gmail.com>
Message-ID: <20180105175447.AA9D4276D62@mail.avvanta.com>

Quoth Nathan Collins <nathan.collins at gmail.com>,

> I had some ~/.cabal/packages/hackage.haskell.org/00-index.* files, but
> not any 01-index.* files, and running `cabal update` didn't change
> that.

I see this when using hackage.fpcomplete.com, rather than hackage.haskell.org.

(The latter is very slow for me, and sometimes fails -
  $ cabal update
  Downloading the latest package list from hackage.haskell.org
  dieVerbatim: user error (cabal: '/bin/curl' exited with an error:
  curl: (18) transfer closed with 29508193 bytes remaining to read
  )$ 
)

	Donn

From mail at joachim-breitner.de  Tue Jan 16 16:08:48 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 16 Jan 2018 11:08:48 -0500
Subject: Maybe String -> CoreExpr  in a GHC plugin
Message-ID: <1516118928.1031.9.camel@joachim-breitner.de>

Hi,

in a GHC plugin, I want to synthesize simple data structures, and
insert them into the code. What is the most idiomatic way of writing a
function, say,

  foo :: Maybe String -> CoreExpr

or

  foo :: Maybe String -> CoreM CoreExpr

so that the resulting CoreExpr describes the input. Abstractly
speaking, I could imagine creating the Core AST by hand (but I’d have
to figure out how to resolve the names of the constructors), or somehow
invoking the renamer, type-checker and desugarer from within CoreM.

Surely someone else has solved this problem before. How did you do it?

Thanks,
Joachim


-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  https://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180116/4007653d/attachment.sig>

From mail at joachim-breitner.de  Fri Jan 19 13:57:39 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 19 Jan 2018 08:57:39 -0500
Subject: Maybe String -> CoreExpr  in a GHC plugin
In-Reply-To: <1516118928.1031.9.camel@joachim-breitner.de>
References: <1516118928.1031.9.camel@joachim-breitner.de>
Message-ID: <1516370259.3059.1.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 16.01.2018, 11:08 -0500 schrieb Joachim Breitner:
> in a GHC plugin, I want to synthesize simple data structures, and
> insert them into the code. What is the most idiomatic way of writing a
> function, say,
> 
>   foo :: Maybe String -> CoreExpr
> 
> or
> 
>   foo :: Maybe String -> CoreM CoreExpr
> 
> so that the resulting CoreExpr describes the input. Abstractly
> speaking, I could imagine creating the Core AST by hand (but I’d have
> to figure out how to resolve the names of the constructors), or somehow
> invoking the renamer, type-checker and desugarer from within CoreM.

I ended up writing this:

dcExpr :: TH.Name -> CoreM CoreExpr
dcExpr thn = do
    Just name <- thNameToGhcName thn
    dc <- lookupDataCon name
    pure $ Var (dataConWrapId dc)

resultToExpr :: Result -> CoreM CoreExpr
resultToExpr (Success s) = App <$> dcExpr 'Success <*> mkStringExpr s
resultToExpr (Failure s) = App <$> dcExpr 'Failure <*> mkStringExpr s

which seems to work fine.

Cheers,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180119/79fe5480/attachment.sig>

From mail at joachim-breitner.de  Fri Jan 19 14:01:11 2018
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 19 Jan 2018 09:01:11 -0500
Subject: Why is EvTerm limited?
Message-ID: <1516370471.3059.4.camel@joachim-breitner.de>

Hi,

I had some funky idea where a type checker plugin would have to
synthesize code for a custom-solved instances on the fly. But it seems
that does not work because EvTerm is less expressive than Core
(especially, no lambdas):
https://downloads.haskell.org/~ghc/8.2.2/docs/html/libraries/ghc-8.2.2/TcEvidence.html#t:EvTerm

What would break if we had

 | EvExpr CoreExpr

as an additional constructor there?

Cheers,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  https://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180119/46050b6f/attachment.sig>

From simonpj at microsoft.com  Fri Jan 19 17:05:06 2018
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 19 Jan 2018 17:05:06 +0000
Subject: Why is EvTerm limited?
In-Reply-To: <1516370471.3059.4.camel@joachim-breitner.de>
References: <1516370471.3059.4.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB020514FD072022AE084812A8ADEF0@VI1PR83MB0205.EURPRD83.prod.outlook.com>

|  What would break if we had
|  
|   | EvExpr CoreExpr
|  
|  as an additional constructor there?

This has come up before.  I think that'd be a solid win. 

In fact, eliminate all the existing evidence constructors with "smart constructors" that produce an EvExpr.  That'd mean moving stuff from the desugarer into these smart constructors, but that's ok.

I /think/ I didn't do that initially only because there were very few forms and it mean that there was no CoreExpr stuff in the type checker. But as we add more forms that decision looks and less good.

You'd need to add zonkCoreExpr in place of zonkEvTerm.

evVarsOfTerm is called quite a bit; you might want to cache the result in the EvExpr constructor.

Make a ticket and execute?

Simon

|  -----Original Message-----
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  bounces at haskell.org] On Behalf Of Joachim Breitner
|  Sent: 19 January 2018 14:01
|  To: Glasgow-Haskell-Users users <glasgow-haskell-users at haskell.org>
|  Subject: Why is EvTerm limited?
|  
|  Hi,
|  
|  I had some funky idea where a type checker plugin would have to
|  synthesize code for a custom-solved instances on the fly. But it seems
|  that does not work because EvTerm is less expressive than Core
|  (especially, no lambdas):
|  https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa
|  ds.haskell.org%2F~ghc%2F8.2.2%2Fdocs%2Fhtml%2Flibraries%2Fghc-
|  8.2.2%2FTcEvidence.html%23t:EvTerm&data=02%7C01%7Csimonpj%40microsoft.
|  com%7C513ff7ae83914913225008d55f452dec%7C72f988bf86f141af91ab2d7cd011d
|  b47%7C1%7C0%7C636519673089385423&sdata=kFkUugVn02Nfu4QXJ6dkVwtx8KWFrTM
|  fWcVEiwf6KyI%3D&reserved=0
|  
|  What would break if we had
|  
|   | EvExpr CoreExpr
|  
|  as an additional constructor there?
|  
|  Cheers,
|  Joachim
|  
|  --
|  Joachim “nomeata” Breitner
|    mail at joachim-breitner.de
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C513ff7ae839149
|  13225008d55f452dec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636519
|  673089385423&sdata=Vh4BvbeEVUBIntKcf3XEseOzwUTx2RHPuANTY328dpM%3D&rese
|  rved=0

From ben at well-typed.com  Sun Jan 21 20:14:46 2018
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 21 Jan 2018 15:14:46 -0500
Subject: [ANNOUNCE] GHC 8.4.1-alpha2 available
References: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>
Message-ID: <87shazx94g.fsf@smart-cactus.org>


The GHC development team is pleased to announce the second alpha release
of the 8.4.1 release. The usual release artifacts are available from

    https://downloads.haskell.org/~ghc/8.4.1-alpha2

Note that this alpha, like alpha1, is unfortunately afflicted by #14678.
We will try to get an alpha3 out as soon as this issue has been resolved.
However, as this alpha has a number of fixes since alpha1, we have
decided it would be best not to delay it any further.

Also, due to user demand we now offer a binary distribution for 64-bit
Fedora 27; this distribution links against ncurses6. This is in contrast
to the Debian 8 distribution, which links against ncurses5. Users of
newer distributions (Fedora 27, Debian sid) should use this distribution.

Note that this release drops compatibility with GCC 4.6 and earlier.
While we generally try to place as few constraints on system toolchain
as possible, this release depends upon the __atomic__ builtins provided
by GCC 4.7 and later (see #14244).


=== Notes on release scheduling ===

The 8.4.1 release marks the first release where GHC will be adhering to
its new, higher-cadence release schedule [1]. Under this new scheme,
major releases will be made in 6-month intervals with interstitial minor
releases as necessary.

In order to minimize the likelihood of schedule slippage and to ensure
adequate testing, each major release will be preceeded by a number of
regular alpha releases. We will begin issuing these releases roughly
three months before the final date of the major release and will issue
roughly one every two weeks during this period. This high release
cadence will allow us to quickly get fixes in to users hands and allow
better feedback on the status of the release.

GHC 8.4 is slated to be released in mid-February but, due to technical
constraints, we are starting the alpha-release cycle a bit later than
planned under the above schedule. For this reason, it would be greatly
appreciated if users could put this alpha through its paces to make up
for lost time.

As always, do let us know if you encounter any trouble in the course of
testing. Thanks for your help!

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180121/62e8a2fa/attachment.sig>

From george.colpitts at gmail.com  Mon Jan 22 21:19:27 2018
From: george.colpitts at gmail.com (George Colpitts)
Date: Mon, 22 Jan 2018 21:19:27 +0000
Subject: [ANNOUNCE] GHC 8.4.1-alpha2 available
In-Reply-To: <87shazx94g.fsf@smart-cactus.org>
References: <87bmitcejz.fsf@ben-laptop.smart-cactus.org>
 <87shazx94g.fsf@smart-cactus.org>
Message-ID: <CAB-d4A4NEvogVF0vr+DLD3AHkJABBsWwmmQNAZACGa6uMbfc8w@mail.gmail.com>

installed fine on my mac
primitive can now be compiled
unordered-containers does not compile, even with allow-new. This has been
reported by Neil Mitchell
haskell-src-exts does not compile, not clear where to report this

On Sun, Jan 21, 2018 at 4:15 PM Ben Gamari <ben at well-typed.com> wrote:

>
> The GHC development team is pleased to announce the second alpha release
> of the 8.4.1 release. The usual release artifacts are available from
>
>     https://downloads.haskell.org/~ghc/8.4.1-alpha2
>
> Note that this alpha, like alpha1, is unfortunately afflicted by #14678.
> We will try to get an alpha3 out as soon as this issue has been resolved.
> However, as this alpha has a number of fixes since alpha1, we have
> decided it would be best not to delay it any further.
>
> Also, due to user demand we now offer a binary distribution for 64-bit
> Fedora 27; this distribution links against ncurses6. This is in contrast
> to the Debian 8 distribution, which links against ncurses5. Users of
> newer distributions (Fedora 27, Debian sid) should use this distribution.
>
> Note that this release drops compatibility with GCC 4.6 and earlier.
> While we generally try to place as few constraints on system toolchain
> as possible, this release depends upon the __atomic__ builtins provided
> by GCC 4.7 and later (see #14244).
>
>
> === Notes on release scheduling ===
>
> The 8.4.1 release marks the first release where GHC will be adhering to
> its new, higher-cadence release schedule [1]. Under this new scheme,
> major releases will be made in 6-month intervals with interstitial minor
> releases as necessary.
>
> In order to minimize the likelihood of schedule slippage and to ensure
> adequate testing, each major release will be preceeded by a number of
> regular alpha releases. We will begin issuing these releases roughly
> three months before the final date of the major release and will issue
> roughly one every two weeks during this period. This high release
> cadence will allow us to quickly get fixes in to users hands and allow
> better feedback on the status of the release.
>
> GHC 8.4 is slated to be released in mid-February but, due to technical
> constraints, we are starting the alpha-release cycle a bit later than
> planned under the above schedule. For this reason, it would be greatly
> appreciated if users could put this alpha through its paces to make up
> for lost time.
>
> As always, do let us know if you encounter any trouble in the course of
> testing. Thanks for your help!
>
> Cheers,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180122/5d55f488/attachment.html>

From jhala at cs.ucsd.edu  Fri Jan 26 00:24:50 2018
From: jhala at cs.ucsd.edu (Ranjit Jhala)
Date: Thu, 25 Jan 2018 16:24:50 -0800
Subject: (Failing to) look up names generated by Template Haskell
Message-ID: <CADrJYTG6yu5HqLccTLqQARZm_hyXempqakiS9MePidG7xtEeYQ@mail.gmail.com>

Hi all,

I am stuck on the following problem.

Suppose you have two module

   Lib

   Client

where Client "imports" Lib. Now, while analyzing the Core of `Client` often
I need to resolve the name of a `TyThing` defined inside `Lib`. Normally,
this is easy enough: I simply use

   hscTcRcLookupName :: HscEnv
<https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/HscTypes.html#t:HscEnv>
-> Name
<https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/Name.html#t:Name>
-> IO
<https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/base-4.10.0.0/System-IO.html#t:IO>
(Maybe
<https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/base-4.10.0.0/Data-Maybe.html#t:Maybe>
TyThing
<https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/Type.html#t:TyThing>
)

defined inside HscMain.

**THE PROBLEM** However, I find that when the
relevant `Name` corresponds to something generated
by TemplateHaskell (inside `Lib`) then the above `hscTcRcLookupName` fails
to return any result!
Even more oddly, suppose the name was

   BlogPostId

If there are TWO `TyThing`s with that name, e.g.
a type synonym defined

   type BlogPostId = ...

and also a data constructor for a data family
instance, then `hscTcRcLookupName` only returns
the type synonym, but refuses to return the data constructor.

Does anyone know what may be going on?

Thanks!

- Ranjit Jhala.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180125/cddae427/attachment.html>

From jhala at cs.ucsd.edu  Fri Jan 26 01:46:45 2018
From: jhala at cs.ucsd.edu (Ranjit Jhala)
Date: Thu, 25 Jan 2018 17:46:45 -0800
Subject: (Failing to) look up names generated by Template Haskell
In-Reply-To: <CADrJYTG6yu5HqLccTLqQARZm_hyXempqakiS9MePidG7xtEeYQ@mail.gmail.com>
References: <CADrJYTG6yu5HqLccTLqQARZm_hyXempqakiS9MePidG7xtEeYQ@mail.gmail.com>
Message-ID: <CADrJYTFDtctCG9Kn7A0_TJq1pS3aUE2ZPb4ebupkDC9+pxW-Ng@mail.gmail.com>

On further inspection, the problem is not with TH but with family instances.

That is, suppose Library.hs is has the constructors defined in the simple
top-level style:

```
data EntityField typ where
  BlobXVal :: EntityField Int
  BlobYVal :: EntityField Int
```

Then when analyzing Client.hs, the lookup function `hscTcRcLookupName`
WORKS.

However, if instead, Library.hs defines the constructors within an instance:

```
instance PersistEntity Blob where
  data EntityField Blob typ where
    BlobXVal :: EntityField Blob Int
    BlobYVal :: EntityField Blob Int
```

then, when analyzing Client.hs, the `hscTcRcLookupName` function FAILS.

Clearly there is some difference in how `hscTcRcLookupName` works in these
two cases.

Does someone know what it is?

Thanks in advance!

- Ranjit.


On Thu, Jan 25, 2018 at 4:24 PM, Ranjit Jhala <jhala at cs.ucsd.edu> wrote:

> Hi all,
>
> I am stuck on the following problem.
>
> Suppose you have two module
>
>    Lib
>
>    Client
>
> where Client "imports" Lib. Now, while analyzing the Core of `Client`
> often I need to resolve the name of a `TyThing` defined inside `Lib`.
> Normally, this is easy enough: I simply use
>
>    hscTcRcLookupName :: HscEnv
> <https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/HscTypes.html#t:HscEnv>
> -> Name
> <https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/Name.html#t:Name>
> -> IO
> <https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/base-4.10.0.0/System-IO.html#t:IO>
> (Maybe
> <https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/base-4.10.0.0/Data-Maybe.html#t:Maybe>
> TyThing
> <https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/Type.html#t:TyThing>
> )
>
> defined inside HscMain.
>
> **THE PROBLEM** However, I find that when the
> relevant `Name` corresponds to something generated
> by TemplateHaskell (inside `Lib`) then the above `hscTcRcLookupName` fails
> to return any result!
> Even more oddly, suppose the name was
>
>    BlogPostId
>
> If there are TWO `TyThing`s with that name, e.g.
> a type synonym defined
>
>    type BlogPostId = ...
>
> and also a data constructor for a data family
> instance, then `hscTcRcLookupName` only returns
> the type synonym, but refuses to return the data constructor.
>
> Does anyone know what may be going on?
>
> Thanks!
>
> - Ranjit Jhala.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20180125/27b82b85/attachment.html>